From paitken@cisco.com Mon Sep 2 11:45:45 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DB021F9DBD; Mon, 2 Sep 2013 11:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ3nTpJwuHVa; Mon, 2 Sep 2013 11:45:39 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8799C21F9D33; Mon, 2 Sep 2013 11:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5409; q=dns/txt; s=iport; t=1378147536; x=1379357136; h=message-id:date:from:mime-version:to:cc:subject; bh=M9CLcAq3r8d3IrcQ6CY3GC6ltXYRCAee9a5sZhMp1gw=; b=PxJNX83mJjCfNB6X3+KXCIWxYGM8SI5df/5qsCG8/FRpu+AGYp6CcCO+ 8+6Vb1wtK4psmz3FFioyJ4e02ljE0tcjqsZ/KFyJ/msJ2VQ2bBIEGKDW7 PwDYIAZGpnFbMMfRUgM6Dm8bziNrMKs5sWz6WhSeIu6FBWCycXGwfOhhG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAFPbJFKQ/khM/2dsb2JhbABagweKCrdigSkWdIMWDQE8FhgDAgECAUsBDAEHAQGHfrkmgluNJIQkA5d1hiyLOoMh X-IronPort-AV: E=Sophos;i="4.89,1008,1367971200"; d="scan'208,217";a="17219480" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 02 Sep 2013 18:45:33 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r82IjUYo029444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Sep 2013 18:45:30 GMT Received: from [10.61.85.105] (ams3-vpn-dhcp5482.cisco.com [10.61.85.105]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r82IjTw0021398; Mon, 2 Sep 2013 19:45:29 +0100 (BST) Message-ID: <5224DCCC.9020607@cisco.com> Date: Mon, 02 Sep 2013 19:45:32 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: IETF IPFIX Working Group , "ie-doctors@ietf.org" Content-Type: multipart/alternative; boundary="------------060600040702020003040801" Cc: yaakov_s@rad.com Subject: [IPFIX] IPFIX: boolean, dot1qDEI and dot1qCustomerDEI X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 18:45:45 -0000 This is a multi-part message in MIME format. --------------060600040702020003040801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear IPFIX experts, While reviewing IANA's IPFIX registry, I noticed that although IEs #388 dot1qDEI and #389 dot1qCustomerDEI are defined as "boolean" their definitions do not correspond to that type. As a reminder, RFC5101bis says: 6.1.5. boolean The boolean data type is specified according to the TruthValue in [RFC2579]. It is encoded as a single-octet integer per Section 6.1.1,with the value 1 for true and value 2 for false. Every other value is undefined. (for consistency with MIB truthValue). So a boolean IE cannot capture a bit field such as the DEI required by #388 and #389. I checked the other boolean IEs, and they're fine. To correct this, I propose that #388 and #389 be changed from "boolean" to "unsigned8", in line with all the other flags fields: 388 dot1qDEI boolean unsigned8 flags current The first bit of this octet is the value of the 1-bit Drop Eligible Indicator (DEI) field of the VLAN tag as described in 802.1Q-2011 subclause 9.6. In case of a QinQ frame, it represents the outer tag's DEI field and in case of an IEEE 802.1ad frame it represents the DEI field of the S-TAG. Note: in earlier versions of 802.1Q the same bit field in the incoming packet is occupied by the Canonical Format Indicator (CFI) field, except for S-TAGs. The remainder of this octet is reserved for future use. 389 dot1qCustomerDEI boolean unsigned8 flags current In case of a QinQ frame, the first bit of this octet it represents the inner tag's Drop Eligible Indicator (DEI) field and in case of an IEEE 802.1ad frame it represents the DEI field of the C-TAG. The remainder of this octet is reserved for future use. Feedback? P. --------------060600040702020003040801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear IPFIX experts,

While reviewing IANA's IPFIX registry, I noticed that although IEs #388 dot1qDEI and #389 dot1qCustomerDEI are defined as "boolean" their definitions do not correspond to that type.

As a reminder, RFC5101bis says:
6.1.5.  boolean

   The boolean data type is specified according to the TruthValue in
   [RFC2579].  It is encoded as a single-octet integer per
   Section 6.1.1, with the value 1 for true and value 2 for false.
   Every other value is undefined.

(for consistency with MIB truthValue).

So a boolean IE cannot capture a bit field such as the DEI required by #388 and #389. I checked the other boolean IEs, and they're fine.

To correct this, I propose that #388 and #389 be changed from "boolean" to "unsigned8", in line with all the other flags fields:


388 dot1qDEI boolean
unsigned8
 flags current


The first bit of this octet is the value of the 1-bit Drop Eligible Indicator (DEI) field of the VLAN tag as described in 802.1Q-2011 subclause 9.6. In case of a QinQ frame, it represents the outer tag's DEI field and in case of an IEEE 802.1ad frame it represents the DEI field of the S-TAG. Note: in earlier versions of 802.1Q the same bit field in the incoming packet is occupied by the Canonical Format Indicator (CFI) field, except for S-TAGs.
The remainder of this octet is reserved for future use.
389 dot1qCustomerDEI boolean
unsigned8
 flags current


In case of a QinQ frame, the first bit of this octet it represents the inner tag's Drop Eligible Indicator (DEI) field and in case of an IEEE 802.1ad frame it represents the DEI field of the C-TAG.
The remainder of this octet is reserved for future use.


Feedback?

P.
--------------060600040702020003040801-- From yaakov_s@rad.com Mon Sep 2 23:51:32 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AA421F962D for ; Mon, 2 Sep 2013 23:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnbFbeyInZ1k for ; Mon, 2 Sep 2013 23:51:26 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6B08D21F91BF for ; Mon, 2 Sep 2013 23:51:23 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 3 Sep 2013 09:54:37 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.03.0146.000; Tue, 3 Sep 2013 09:51:19 +0300 From: Yaakov Stein To: Paul Aitken , IETF IPFIX Working Group , "ie-doctors@ietf.org" Thread-Topic: IPFIX: boolean, dot1qDEI and dot1qCustomerDEI Thread-Index: AQHOqAyqRQlG26RKI0yFIkdMliDtJpmzkvJw Date: Tue, 3 Sep 2013 06:51:18 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC904E971CA@EXRAD5.ad.rad.co.il> References: <5224DCCC.9020607@cisco.com> In-Reply-To: <5224DCCC.9020607@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC904E971CAEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A0C0205.522586E8.0090,ss=1,fgs=0 X-Mailman-Approved-At: Mon, 02 Sep 2013 23:58:49 -0700 Subject: Re: [IPFIX] IPFIX: boolean, dot1qDEI and dot1qCustomerDEI X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 06:51:32 -0000 --_000_07F7D7DED63154409F13298786A2ADC904E971CAEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fine with me since it simplifies the interpretation (DEI=3D0 means green an= d DEI=3D1 means yellow). By first bit do you mean least significant bit ? Y(J)S From: Paul Aitken [mailto:paitken@cisco.com] Sent: 02 September, 2013 21:46 To: IETF IPFIX Working Group; ie-doctors@ietf.org Cc: Yaakov Stein Subject: IPFIX: boolean, dot1qDEI and dot1qCustomerDEI Dear IPFIX experts, While reviewing IANA's IPFIX registry, I noticed that although IEs #388 dot= 1qDEI and #389 dot1qCustomerDEI are defined as "boolean" their definitions = do not correspond to that type. As a reminder, RFC5101bis says: 6.1.5. boolean The boolean data type is specified according to the TruthValue in [RFC2579]. It is encoded as a single-octet integer per Section 6.1.1, with the value 1 for true and value 2 for false. Every other value is undefined. (for consistency with MIB truthValue). So a boolean IE cannot capture a bit field such as the DEI required by #388= and #389. I checked the other boolean IEs, and they're fine. To correct this, I propose that #388 and #389 be changed from "boolean" to = "unsigned8", in line with all the other flags fields: 388 dot1qDEI boolean unsigned8 flags current The first bit of this octet is the value of the 1-bit Drop Eligible Indicat= or (DEI) field of the VLAN tag as described in 802.1Q-2011 subclause 9.6. I= n case of a QinQ frame, it represents the outer tag's DEI field and in case= of an IEEE 802.1ad frame it represents the DEI field of the S-TAG. Note: i= n earlier versions of 802.1Q the same bit field in the incoming packet is o= ccupied by the Canonical Format Indicator (CFI) field, except for S-TAGs. The remainder of this octet is reserved for future use. 389 dot1qCustomerDEI boolean unsigned8 flags current In case of a QinQ frame, the first bit of this octet it represents the inne= r tag's Drop Eligible Indicator (DEI) field and in case of an IEEE 802.1ad = frame it represents the DEI field of the C-TAG. The remainder of this octet is reserved for future use. Feedback? P. --_000_07F7D7DED63154409F13298786A2ADC904E971CAEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fine with me since it sim= plifies the interpretation (DEI=3D0 means green and DEI=3D1 means yellow).<= o:p>

 <= /p>

By first bitleast significant bit ?

 <= /p>

Y(J)S

 <= /p>

From: Paul Aitken [mailto:paitken@cisco.com]
Sent: 02 September, 2013 21:46
To: IETF IPFIX Working Group; ie-doctors@ietf.org
Cc: Yaakov Stein
Subject: IPFIX: boolean, dot1qDEI and dot1qCustomerDEI

 

Dear IPFIX experts,

While reviewing IANA's IPFIX registry, I noticed that although IEs #388 dot= 1qDEI and #389 dot1qCustomerDEI are defined as "boolean" their de= finitions do not correspond to that type.

As a reminder, RFC5101bis says:

6.1.5.  boolean
 
   The boolean data type is specified according to the Truth=
Value in
   [RFC2579].  It is encoded as a single-octet integer =
per
   Section 6.1.1, with the val=
ue 1 for true and value 2 for false.
   Every other value is undefined.


(for consistency with MIB truthValue).

So a boolean IE cannot capture a bit field such as the DEI required by #388= and #389. I checked the other boolean IEs, and they're fine.

To correct this, I propose that #388 and #389 be changed from "boolean= " to "unsigned8", in line with all the other flags fields:

388

dot1qDEI

boolean
unsigned8

flags

current


The first bit of this octet is the value of the 1-bit Drop Eligible = Indicator (DEI) field of the VLAN tag as described in 802.1Q-2011 subclause= 9.6. In case of a QinQ frame, it represents the outer tag's DEI field and = in case of an IEEE 802.1ad frame it represents the DEI field of the S-TAG. Note: in earlier versions of 802= .1Q the same bit field in the incoming packet is occupied by the Canonical = Format Indicator (CFI) field, except for S-TAGs.
The remainder of this octet is reserved for f= uture use.

389

dot1qCustomerDEI

boolean
unsigned8

flags

current


In case of a QinQ frame, the first bit of thi= s octet it represents the inner tag's Drop Eligible Indicator (DEI) field an= d in case of an IEEE 802.1ad frame it represents the DEI field of the C-TAG= .
The remainder of this octet is reserved for f= uture use.



Feedback?

P.

--_000_07F7D7DED63154409F13298786A2ADC904E971CAEXRAD5adradcoil_-- From paitken@cisco.com Tue Sep 3 02:57:59 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2F421E80D9; Tue, 3 Sep 2013 02:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LREmHACCYNYX; Tue, 3 Sep 2013 02:57:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B5B2621E80EB; Tue, 3 Sep 2013 02:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60673; q=dns/txt; s=iport; t=1378202254; x=1379411854; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=NVPSHQf8n97BGHL8ZSqCdGlE10odmpMWX35h9zx/Tb8=; b=m7aNFxM8YZn407jseJxsaSl4xtT80genFyh/o1rN8kjbCu1bbGvSUjk7 d3wWcMijZh5J6+A6f4ww9JaDwkYz3So4JkZMFrTj57p0yGBN1h4MB2mcX bLmYROYhEuMnRhJ+/j91+ooUMzvvUQbX+9TYj9QuvFkN9tMweH0ks6KlE 8=; X-Files: VLAN-TCI.jpg : 33647 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAMGxJVKQ/khM/2dsb2JhbABagkNEigqvSYgqgS0WdIIkAQEBAwEFKD4NAQULCxEEAQEGAQECCQ0IBwIHAwIBAgEFAS4JCAYNAQUCAQECh3YGuTWCW40bBgGEHQOQI4EvhiOGLIs6gyE X-IronPort-AV: E=Sophos;i="4.89,1013,1367971200"; d="jpg'145?scan'145,208,217,145";a="159187167" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 Sep 2013 09:57:31 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r839vTnH019998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Sep 2013 09:57:29 GMT Received: from [144.254.153.55] (dhcp-144-254-153-55.cisco.com [144.254.153.55]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r839vSYE024435; Tue, 3 Sep 2013 10:57:28 +0100 (BST) Message-ID: <5225B288.8050006@cisco.com> Date: Tue, 03 Sep 2013 10:57:28 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yaakov Stein References: <5224DCCC.9020607@cisco.com> <07F7D7DED63154409F13298786A2ADC904E971CA@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC904E971CA@EXRAD5.ad.rad.co.il> Content-Type: multipart/mixed; boundary="------------020109060002000407060902" Cc: "ie-doctors@ietf.org" , IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX: boolean, dot1qDEI and dot1qCustomerDEI X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 09:57:59 -0000 This is a multi-part message in MIME format. --------------020109060002000407060902 Content-Type: multipart/alternative; boundary="------------070606010903080403080201" --------------070606010903080403080201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yaakov, > Fine with me since it simplifies the interpretation (DEI=0 means green > and DEI=1 means yellow). > > By first bitdo you mean least significant bit? > Yes. If needs be we could add a figure something like so: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Reserved | DEI | +-----+-----+-----+-----+-----+-----+-----+-----+ Although if we were defining this again, it might be more useful to retain the DEI position, and potentially include the PCP bits. So, per 802.1Q-2011 Figure 9-1 (attached) : 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | PCP | DEI | Reserved | +-----+-----+-----+-----+-----+-----+-----+-----+ However I suspect that this is incompatible with current implementations, so the change is not possible? P. > *From:*Paul Aitken [mailto:paitken@cisco.com] > *Sent:* 02 September, 2013 21:46 > *To:* IETF IPFIX Working Group; ie-doctors@ietf.org > *Cc:* Yaakov Stein > *Subject:* IPFIX: boolean, dot1qDEI and dot1qCustomerDEI > > Dear IPFIX experts, > > While reviewing IANA's IPFIX registry, I noticed that although IEs > #388 dot1qDEI and #389 dot1qCustomerDEI are defined as "boolean" their > definitions do not correspond to that type. > > As a reminder, RFC5101bis says: > > 6.1.5. boolean > > The boolean data type is specified according to the TruthValue in > [RFC2579]. It is encoded as a single-octet integer per > Section 6.1.1,with the value 1 for true and value 2 for false. > Every other value is undefined. > > > (for consistency with MIB truthValue). > > So a boolean IE cannot capture a bit field such as the DEI required by > #388 and #389. I checked the other boolean IEs, and they're fine. > > To correct this, I propose that #388 and #389 be changed from > "boolean" to "unsigned8", in line with all the other flags fields: > > 388 > > > > dot1qDEI > > > > boolean > unsigned8 > > > > flags > > > > current > > > > > The first bit of this octet is the value of the 1-bit Drop Eligible > Indicator (DEI) field of the VLAN tag as described in 802.1Q-2011 > subclause 9.6. In case of a QinQ frame, it represents the outer tag's > DEI field and in case of an IEEE 802.1ad frame it represents the DEI > field of the S-TAG. Note: in earlier versions of 802.1Q the same bit > field in the incoming packet is occupied by the Canonical Format > Indicator (CFI) field, except for S-TAGs. > The remainder of this octet is reserved for future use. > > 389 > > > > dot1qCustomerDEI > > > > boolean > unsigned8 > > > > flags > > > > current > > > > > In case of a QinQ frame, the first bit of this octet it represents the > inner tag's Drop Eligible Indicator (DEI) field and in case of an IEEE > 802.1ad frame it represents the DEI field of the C-TAG. > The remainder of this octet is reserved for future use. > > > > Feedback? > > P. > --------------070606010903080403080201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Yaakov,

Fine with me since it simplifies the interpretation (DEI=0 means green and DEI=1 means yellow).

 

By first bit do you mean least significant bit ?


Yes. If needs be we could add a figure something like so:

	   0     1     2     3     4     5     6     7
	+-----+-----+-----+-----+-----+-----+-----+-----+
	|                Reserved                 | DEI |
	+-----+-----+-----+-----+-----+-----+-----+-----+
Although if we were defining this again, it might be more useful to retain the DEI position, and potentially include the PCP bits.

So, per 802.1Q-2011 Figure 9-1 (attached) :

	   0     1     2     3     4     5     6     7
	+-----+-----+-----+-----+-----+-----+-----+-----+
	|       PCP       | DEI |        Reserved       |
	+-----+-----+-----+-----+-----+-----+-----+-----+

However I suspect that this is incompatible with current implementations, so the change is not possible?

P.


From: Paul Aitken [mailto:paitken@cisco.com]
Sent: 02 September, 2013 21:46
To: IETF IPFIX Working Group; ie-doctors@ietf.org
Cc: Yaakov Stein
Subject: IPFIX: boolean, dot1qDEI and dot1qCustomerDEI

 

Dear IPFIX experts,

While reviewing IANA's IPFIX registry, I noticed that although IEs #388 dot1qDEI and #389 dot1qCustomerDEI are defined as "boolean" their definitions do not correspond to that type.

As a reminder, RFC5101bis says:

6.1.5.  boolean
 
   The boolean data type is specified according to the TruthValue in
   [RFC2579].  It is encoded as a single-octet integer per
   Section 6.1.1, with the value 1 for true and value 2 for false.
   Every other value is undefined.


(for consistency with MIB truthValue).

So a boolean IE cannot capture a bit field such as the DEI required by #388 and #389. I checked the other boolean IEs, and they're fine.

To correct this, I propose that #388 and #389 be changed from "boolean" to "unsigned8", in line with all the other flags fields:

388

dot1qDEI

boolean
unsigned8

flags

current


The first bit of this octet is the value of the 1-bit Drop Eligible Indicator (DEI) field of the VLAN tag as described in 802.1Q-2011 subclause 9.6. In case of a QinQ frame, it represents the outer tag's DEI field and in case of an IEEE 802.1ad frame it represents the DEI field of the S-TAG. Note: in earlier versions of 802.1Q the same bit field in the incoming packet is occupied by the Canonical Format Indicator (CFI) field, except for S-TAGs.
The remainder of this octet is reserved for future use.

389

dot1qCustomerDEI

boolean
unsigned8

flags

current


In case of a QinQ frame, the first bit of this octet it represents the inner tag's Drop Eligible Indicator (DEI) field and in case of an IEEE 802.1ad frame it represents the DEI field of the C-TAG.
The remainder of this octet is reserved for future use.



Feedback?

P.


--------------070606010903080403080201-- --------------020109060002000407060902 Content-Type: image/jpeg; name="VLAN-TCI.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="VLAN-TCI.jpg" /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoM DAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsN FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wgAR CADxAzIDAREAAhEBAxEB/8QAHAABAAIDAQEBAAAAAAAAAAAAAAUGAwQHAgEI/8QAFAEBAAAA AAAAAAAAAAAAAAAAAP/aAAwDAQACEAMQAAAB/SJzg64cPO1FQK8Xs1TUIMmSUOSHbjfBrnDj rpOAjzAS4KQey2mY5gdQAABUTeLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACjH55P0wfmA/X Z+WywnTDkpqEETx+pjgBTyNLMdQMxz8hCQKQbJYjGWk2CsmmVokiZMJqGsez4ahPEgSh3wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAjTnpaCkHYjnxaTlRcDbM5Gl+KeVgqhWT9SHFjoRVC0kc QRfijFpPZrHswlSLsAVQ2DKbhEFpBbQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMOem4XIkCjEQdRKMTxXy1 FFNwsRDHszkyQB5Jgp5bjKfT4ZzSNAtpVyRPJvESZyRPBnNcgSdIolTXNYsBUCUNg8FEOhnk 1zcKoWs0DcB9KkWo9EeVsuRvmkVgnDaJYrxXy0GqRAMpLmUlSgE+bJhLCRBXSZNQr5ulnJcj zQM5Wi+g5mU0lTsBzE3ywFaIskDoJQzyXgpRsFPLkUAvYIEsZzwyF4KwdYKGXMgzXIokTYKa ThIGQpBOHo+mMnSgHdjhxtHknypF/Ig0CHLqaZhKuW8rxYCKN4nigEqdfOfFdII6IdGODliI kiiWJQ1DyTpvkGVsmDTO2HGiWKuZiYIY2zopCnOgXc6UAAAAAAAAAADTNw8lQLiAADGeDOAA AAAAAARJgJ0AAAAAAAAAAxEITx6AAAMBnANExGkTRmIMykuAYDOAAQ5CkUWY1yLPRaytEmRx 9PRmMhHEgahZCFK6TBWi/nsjjyeDAbBskabZHlgOalqLAfTmx7MxuEqRRKHo2jyUYt5BGM+E geDOSxAnQyvGUwG0eDKap7NoznkgiXI0ynwzlQLyVQzk2YiMLaRRjMR8KqXM0TcJ42gAAADn prkaShFEuRJ0MoZjIg2SaI0+GIsBolrKOTRJEGQ504pZGk4Rx8NcxmIwlnKqeyaLOV40ywEa eS0lMLKTZUSZK+bQNcznsrJaSHLeVI0AeDKbZPFPN4tpBlZJgjzIejIQp18ohBFhIQtRumuU o9ltKiSZqFjJotAAAABFEkewAQxMkOTAAAAAAAAAABqHk3QACukybIAABFHskgAAAAAAQ5MA AAAAjzVJoAAAEMTB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOfliPgPpME OTxUi2gAAAAAAAAAAAAAAECTxRC9gAAAAAAAAAAAAAAgSeAAAAAAAAAAAAAB4OVlfMxoGM7M a5ZinFxAAAAAAAAAAAAAAAKyWY46diAAAAAAAAAAAAAABWSzAAAAAAAAAAAAAAAAAHOifAAA AABEEuARBLgAAAAAAArpYgAAAAAAAAAAAAAAAVM6kAAAAAAAAAAAAAAAAAUQvYAAAAAKyWYA rJZgAAAAAAAVkswAAAAAAAAAAAAAAAKQXcAAAAAAAAAAAAAAAAAohewAfn46ARxsHSgAVkyl LOqlZLMAAAAAAACslmAAAAAABUiHKOXA6aAAAAAACkF3AAAAAAAAAAAAAAAAAKIXsAFKMRpF 9NoAFZNM50d3KyWYAAAAAAAFZLMAAAAAAAVsjDeLSAAAAAACkF3AAAAAAAAAAAAAAAAAKIXs AjSSAI0kgAVkjCjHcislmAI0kgCNJIA0zMZgCslmAI0kgCNJIAjSSAPhHkiARpJAEaSQBGkk AUgu4AAAAAAAAAAAAAAAABRC9gFZLMAVkswAKyTRDlkKyWYArJZgCslmAIY3DdAKyWYArJZg CslmAKyWYA8FeLIAVkswBWSzAFZLMAUgu4AAAAAAAAAAAAAAAABzksABDEyAQxMgAhiZAIYm QCGJkAhiZAI8zmyAV0sQBDEyAQxMgEMTIB5IolwCGJkAhiZAIYmQCpHUwAAAAAAAAAAAAAAD kRaj4WchizFRN4sAAAI0rRdwDmZ0wApRcj2AAAAAUoupWSzHMjph9AAAAAAAAAAAAANUr5kL MAAAAAAAAAAAAAAAcDLSQh1cxk2UAky2AAAgConTQDkp1oA5YdGN0AAAAAqpaiEJs42dcNgA AAAAAAAAAAAAFVN8mwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAcRLMXk8mwahkPhyQ7YchOvA56fT2Xw44bRYTfOcGwSJ0A5+dH Ph4M54KyXU9gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/LpYimESdGKcV4/XR+Sj9GFOLa aoOQlkLMcdLSYT9SnCyAJg6YcQKQX0hCPLGUU/aBtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA0T6clLsSpvkcTxCk0aRugEcRplJU1T2SBomib5sGuR5IGE8HgxE0ZAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/xAA0EAACAgIBAgMH AwMDBQAAAAAEBQMGAQIAFBUHEBMSFiAwNTZAETRQF2BwITI3IyQxM4D/2gAIAQEAAQUCbtR0 a1T4iRmsd98R658VRsbzS51HqNpitq2C/wAZESJrq8UWV/FWk9Ts8NsUhXwUm2R2fWS2PWc6 kCLxQLnNAI3LC8iCIxB8+KMksaVyM/W+TA+FWEpZRuFvlrZ9drbbbLrVFMEvrwZz+mKpc5rX P8UVmGJZImUzZd/YF2T4e1qxTOSCbR7WayombpKCJP1QpDT+ntnBTdn8IvD/AOzPFB1DM+ol gHgvJteld2WjvveTxB5Xf+WLLEG5Z7NjWdYlVaV7xH8SNZNqTUChNKNcrPBFSH6bHh7KxAy5 8UtQvZVMwdVPhPaApaVVH6bHh7LD/wAw+MP2fZoZDbaAljEuVX/VD4cs0Pu7ULTiZ7bm6HUO 5o6zodakbfXbw0QR7pvEFKgGjt+rwxb4Tv02PD2ViBlz4peG/qAOv51kugbAJPDpcmOX1sZc z/pYowTjH6YtFHXW2ZoqhbK4/CdfFoipgaFi8qoj41ZWxlTZbSl6mw8Cq4oNhm8OF8p9nqsK aq1lJ1lzkj1ljl8JVO8hFXWkolfhyvXHaVobSyR0sDSXXw2B7C1SiO1qvw5Xrjta0NrZLJXR rQtIqohLfFXFxYVFQATohvC1ZDKZWRTnxdaGMsIFaGXPMeGqrCAPw/DFaE0MOd8PSFsFbV+H K9cdpWhtLIqrQydp/wDbJ+hUkQRbg45TZNYpzGwa/M2u8kNVcTsFDhq1VUuLXbSOz2TdFM/m nGTK7BI1Uibz7qiCmwz3LU/DLWJhAdV2JbKR686JilK2jjiYwsNa26yTWao1mba9wyU3UMGL KDBX6MJXy6DbZ6BoMc/XLZZHAUU9ibZSqomM4dhn9T0a2eQ6rSZn3MbB0XdRWI5u5FhGGda2 FdvD3AfGwrIY2QkyEPXRoJIKdawAxyWoocXvIJlwO0FKmYlaQkZsqrGZsbZirLfYur+8K30h nIJcMbsGScu2ZMWgtBGeDGwi/ad8uGl1ZC7hJHErCwmshl+stgWw7YaibC6NQ5AoWYpEQ7zc q4atw9yx2gpUzN8OrOU2TWKcxsGvyQRGLBo0FkhXOJNGO79fEOK1DNI4IfDvOO83KuHeQupg sawnfFnENHevu1AqJ5O4YfL85AchNNpJNYY4X209uHsisrOrsHbUWwrTiuGNg1+dWc0VpAPi 0UFPgNxZrD26wWNzvFXzGwa/PCj4AubP1umIXARASRxKwsPlWvUxYmA80iAj2dGw0fpDsExO lq8Q45SKll/Hvvor94wl5pZVDtCecqNfrnUBp6mbuzGmU20djqXtTMSaSvPb95zxTJ5Uu4hM yXUpWLUPaxKl02GtVVTDFys9d83EAkSKJvGRGpk/613Fgx6rUQU9evQzztAhyV49GjkgqlUh 26tlH7djrGpg5peskF1NQH7atwTmFR10y1tDzScewkgmCGuv++XtZdhLCIH2uw1iIgM+1a77 lnjTSV7aXHTijmDU9kPBOK5H9adKeObYdIZ9K4pxvi22TaaVgjxJh0HCWNWkUmZrU522AsgA moNnTZKTjtoJdhLCtLYkwk9xuFci03hrERAZ9i1k0cMB5pEBHs6NoIsaC1hcSFOXtPBM2gIm G1/XN240EMIzCT3G4V2PTaEaCaOszRTRq3XqbKXIZLB2PJAyGTsI0VRuYxJSAczBtygWlz0F 1HlqcuGw0X8L0xA5G02GtkUO49AmnHNWD/qK+LVThU0rGIm4LCLq3s+8ThIPPFrmIuGVFJma 1fjSCxyT821xvqFWtAovi319vSCDQaH8FotibCBqum3/ABZNc7x9tJ5rj9MfHNBoRr5nCYOD XA6rF/bSeRaZjj41UxtdQl3SZ88QaazfC2ajpANLYBsQTaF5q0x4OHuXZQRM4fC5LW2qMkaA 3Qkgy3ABT7PRfZ2ty7EW1rC00KtIYs41mBKKJsIge62zamba2EX2hbWGboGXqbATYwxOMTpD rK4bb14HR722wbtIMRLGY7cQixCCyE2MMTjCyhrjILYARPmyhRzd7h1jDtq84rFkD9re4ro8 GMY4Ja430mRb3FdHgppEKQrajOQ4WOmlmdETjq2DnQWyuSmCWto5dDZrxMwEEPe+vXaZPKZW bXLIPXBfb3rDItmqzg6NqUJ1ZtkjhIktsehfvcGzLW2m2vClMlo0IgUpRZtYkL4kl+UToGMF ZQzhtLEH7e1lGjIjfCyyE2EQPfV3DvNW3eX68yxhgyyuYYyGrSFMDltBhmNb15fNHUEpC5wD or3swkJANoCYT4sImSbu89KuvM76pq/aBpRRrIuDDGsIZGkdlE25i6AbRYN02OLsAobAayhG ZktIMK73oD6s6w6TMwbEEeCTbQAo47CPNIKRqYN8nxA+zmi8lqwLVnyUOAUxW3GQGKsELi57 LKtIzQ1A0gwI08kNsGUsEwihOzD0sq5s100EO7wKrYRDgqiwiykLGUcWKcgHCmSaqVyA0ZZ2 Y+BSMuKEtNrCINByEdsy2UsBQlEOYhE8TVRP2Y+BTEtJFs46UssAKAuYMZWQrBXr5niaFCdL WTU7KdFNCcFZwVDOJWanZTonUhGtgrHoRqV8JwVmdCMTwj8SG7JwmVfr6pH6Noaaz7GrK2So 5TxCF9bcAd0UhSMdUXTzQNxazKqs6gMuC2QBmYu80BsN1FVlmWIVJhmIOE43oREZua5YUMw0 jGYqWDdKcTRTVhrVVnYhtaV4TP1AVRYRcCkuJ9UQylqyyrmzXRgrMIbWtdM2rg+p5FpgUMtK 7AqLie5XzQ1TTefecdSfjStLSwtDVLWNAdFIcpEVlGCdoZ9v2EZxtI1rLLENNkulVSMnZTMK V74rlLIAMhQzmr2w5e1pWKGIXD64WYGzXmNa7YF2W2F0jEcH5LNWM4D00xHp8BacM8vg6gUU /wDFLFjNGCDiXCfCagBPKHHjFi+MlbEXIKBGHn52VI2zT5R68dmMCnFXZ+QyTiONf/H+bNbM SVHG9XyBd7F7zM9AhCiegSD+tp6uJ5O+8f2QdBH+elnkJD5LZ9oNvzn08gqb8zfX29EzSWvJ 1SrNe2aLSZJNFkh3DYPbHD3x6uPuXlugkJQfn179hyRnls6/Os30D+DLwTNcOgY86BjzoGPO gY86BjzoGPOgY86BjzoGPOgY86BjzoGPFMbM8DoGPOgY86BjwSNmQZ0DHnQMedAx50DHnQMe dAx50DHnQMedAx50DHnQMedAx50DHnQMedAx50DHiII/YLoGPOgY86BjzoGPOgY86BjzoGPO gY86BjzoGPOgY86BjzoGPOgY86BjzoGPOgY86BjzoGPOgY86BjzoGPOgY86BjzoGPOgY86Bj zoGPOgY86BjzoGPOgY8tY7Aau/wePvn5lb+jeaz6p+BXv2H8Bd/tP+Dx98/BFZj9K51Z7po3 YtVy5O2Iy/8Agrf0Z1vvgcjU8Ubiz6p+BXv2HzrSJMSn6zWwuY48G1fAUdfsnzrv9p/wePvn 4K1XIkyuZcxXtZ66aeKOJAJr8Fb+jWYcqaAwZ6SBxZ9U/Ar37D56VAMixJUx9la+vxhGfOu/ 2n/B4++fMszpZvNkZ25f8Fb+jW6fMYDsBGlV8WfVPPcz2GPmcZ0WvmYR0gkMnrQ+de/YecRn qH+c5nomebAzoB/POf0wuM7gv8wzOsz54M/Vj5lGdLP53f7T/g8ffPm3/e+dn+3fgrf0YoMc 6L3aUeSz6p5kfcvm+/8AV5uvo4X7Lzr37DzE+4fM/wCt+di+m+e3+2tfbnmk/wB/np9y+bb9 /wCd3+0/4MqSYa5d2K53YrndiuHlGkkd2K53YrndiuOSjWCnuxXO7Fc7sVzuxXFBRoC/uxXO 7Fc7sVwMo0czuxXO7Fc7sVyUo3dx3Yrndiud2K4zKNM07sVzuxXO7FcYHmFADsi4h+7Fc7sV zuxXELQnQLuxXO7Fc7sVyAo2Nr3Yrndiud2K4SUbMx7sVzuxXO7FcbFGnB92K53YrndiuZal ZwoLNAU92K53YrndiuLijRNu7Fc7sVzuxXNSjcOO7Fc7sVzuxXDijSSu7Fc7sVzuxXLYcUVX Pz5LQz1HMsGAtNbct1FhNhInx9y8eNpgCELPZwr+JkfGrXpm5hpnmPZSDXXna7D7urNc+1r8 sB/Kc/5Xv2HHNpIXF/mFEYFHrreZyJZvoH5+1dk52E/PC1jGWEDcn2cCyd65YV8hDGsAzr1n xP1uXCVUun3b+Z6ww6LztNYMYxBxSQC/LwFN708TiyCC8cJCZiR9No4PzK+FMFo7FkNU/wCH M3R2Y61eOItJTxoZ+5CdPuTDHNo1CkkiYCzzsTolgC/xBK3K5v4hjT2ryuNnkqsFutG1dGQ2 bdw722xripeIetmcmX7RddYLHvNcX5jUOOt3V7Y5d7uzaG63r1aerYdcmrdyIsjrVkJuVOzD Fzu3Bjx3AXqS2YYGX1uDQya7Yk1/sZMhleXG2hbLzocqO5T4z/Rtk1EaeJtPTR5p6YfTI7uA clPNjY/IstnzYLGNEJeypLb1Xq3PjBS2sNapBc1xf1t0Cnut5tQ+akaO6rEbJIPb7x4eHmH3 vnhL/ql8O3oNXXPrHi0eHFai0nqNMX4HRy6IdfD4RJA+8SIEoZ3N1YwNatc4J9ljgFkrIvpY G/saAAYWYgEcvdvV3s7RDWoE9cGRLg9hARgI4EK0UvgaRevn5KCPOR5iLRANp62pKm0QLIsE jQmQjqwxJdF4sRnBABgNDkS5nJICPMLFFpBEKCODjRCtiN1BH0L1WB6YypB2gISgFl7IFm4c cekMf+Cv/8QAFBEBAAAAAAAAAAAAAAAAAAAAsP/aAAgBAwEBPwFHn//EABQRAQAAAAAAAAAA AAAAAAAAALD/2gAIAQIBAT8BR5//xABUEAABAwIEAQYJBQ0GBAQHAAACAQMEABEFEhMhMRQi NUFRYQYgMnGBkZKk0xAVI0KhMDNAUFJic3SCsbKzwSRDU9Hh8HJ1wtIlYHCiFkRjgIOU8f/a AAgBAQAGPwJ+dKLKwyl1tx81RYkzDZOGcsS8Zx7yXaUiXKKbqq1r/NktcJ1dL5wtzb+ajcaH WJBUhFF8qilNtKwQOK2bRLdUWsdebhmUfC9lcz/fVv1eqo08W1aF8c2RV4U9PeHURuyICLZS VV4Vy1oFZVDUDaVb5V/3apGBGyrDraqIOqWzip1U7gegqG2xr62bbq2t6aV+PBdxFzMiaLPH z07Db8GphymkubKHzh86Wph5xko7jgIRMnxBez5XH3jRtpsVIiXqSnJUTAJsnDG+Mvh6bW/r TU6ISky528U7l+V6XILKyyOcltfao81lCFp8c4ofG3yngegucWNbWzbea1cuNhZCZ0DIhW40 25a2cUK1XXhThNYU4zh6XQZZupuqdWXx8QgRxcekwm87iImyr+SlBJfhO4e4Sqmg95Sf+QZk TWCOpIhC44thRUW+9eCbc+KxFVt8AZVp1HFe3DnbcE4eusWyeXyR23sLUXG42KWZYcskBW0y KmpZb996Zetl1AQ7L1XSvCNnyGZjCyY36Tq+1S9VTM6WeksFIP8Aa4fZasK/Rf1rCcLdFx2I wSSZQMjmVexLea/tViMZgHWIOJfStA+OVUPj/wB32V4VPQ1IcRgug/HUeKrvtRTsuRwsPyuD 2Eijf5PCL9AP/RWNOMBieMSGEVM4uI2xEVEXgvX/AKV4IYe9Mdbanvm2+8hc5RFzKiX9P7qw CFFkvlFUCPQccUsmxfZtWKaV82QV27MyX+y9Ye7mBIzcVNVepLJz7+m9Mv8Ag+aR40mQjGq0 GnkSy3t6qwidhcySbjr6NPNOOZkfTtt/vjUiE5IfairDRXAZcy5k229dq8NMLJ944uHmjkcS PyfK/wBKiPR3HROS624a5+uy8KV6HMkrMxN1sJEl0905pKqp2VhE7C5kk3HX0aeacczI+nbb /fGn/wBQ/wAqX9OH9a8FogSHY4PRspKyVltZb/ZWN4AL8j5sdh6umrq3Quat7+usSxyITiTl XQRc3NFFIUvbt3qH4RxMSlfOio06ThO3RzN1W9NeDTGs7EGZFu6jJWWyouZPVtXg9gkaVJai rHNCJHOeqXNV3+yscwM5ctMKj88WEeXyl4fvpwMQxGWwKTFjgUfnOmlkXIn21hbEeJMwyLJa PMxKezK5zS5yp1cK8JrE9/Ym1Nrn9aivHtqEUd823ZEomCfvuI3JePorCJ2FzJJuOvo08045 mR9O23++NSITkh9qKsNFcBlzLmTbb12rwkwpHnHIkR4dEXCvl3L/AE/Hz0OSGdh4cpJTMrXl TXGEswkpzMLXmS1YhOBx5xyd98BxUUE8yWq+rL5HqavINX6HN5qsmyVGdmK8BsXRNEkTMnYu 1PwHMzbDoaa6eyondSAGKYsApwEZAon8NPTm3pMmS62LSnJJCsKW7ETsSoEt1x5mRCPO2bCo nZxui9lYhiLRuk9OVFcQ1TKluzapOLxldB99FQmrpppeyrZLd3b8kzGAN5ZMochiSpkThw27 qmPjKmsszFzSIrT2Vtxe+ouHsYdLxmI06pXByz7N+sbDv19VYdMhwMRYhxQJXpOJp9I4VlRP 6UQGKGBJZRXgqUenJnMRTXMUVt36P91JhBRkSCg2EB+r337aYlOyZmIFG+8BLdzC15ko8bzu 8qNrRULpkt6u6sZNSeP51Sz4kSWTj5O3fR4S5NnOxlcRxMziXC3Um3Cjgy29Rgk9Kd9MSnZM zECjfeAlu5ha8yUWN53eVE1o5Lpkt6q5FKN1trOh3ZVEXbzotYdiJOPI9ADI2KKmVU79qfxn Ue5S8zoEN0yW27u6ncJHUkw3FLMj6oqrfzIlNakmbKiNFnbhvPXaFfNaoOLGbqSIgqICKpkW 9+O3fUPGDN1JMUFABFUyLe/HbvqdijZurImIiOCSplS3ZtRYTqSVZV/lIuqSZxO1ttqiYkU6 fJnR/wC9fezZ04WXbhx4dtPYoMqWw4+lnWmjRAPa2+1fMho5Ih3Vburz0W973SmJTsmZiBRv vAS3cwteZKPG87vKja0VC6ZLerurEZ7Juk9PJCcQ1TKnHht3/wD3tCMRwWTUkuZDmsPXtWNR W5rSHCMRbzMeXcM2+9Yk1ic1oSbnrHZuiDzcoW+1atIkA1wupcBvwv2emiRtzTNU5p2vapJY i4ITYzrjUjKlkBR/0stOYmrw8tTKaCTWyIRIllTtsvrpEM9QuslS16h5W87GoKyz/wAJpVy3 9a/+1amSIzqNPMtE6NxzItkvapiEnI8Whoovs8ch2494rTRqWpIJrNdUsma1YZhxT2y5S04Z mkfgo24b99RcFRxop6tm+/JybA1msNh7V2pkeUJIhkhZyIERwS6uG1uPVWLcpdQ0izTjNoI2 2S269+9YdAF1WFkkWd0RuoCgqu21uNqmJLxdnECYKxkIICNbcFqQEV8dZvYkVNwXqui1h02c 6ms+CX28ouxESsUJ19HxZmmy2Qjl5qCO32rTsFksqRwE3j67l5Ip6r+qsSJzEG2CjznIjaqy llsqIN/XUJhyc2EhWlVyIKIquLtzu1ETf11Z2Y01zlBCMrCpJxS/C/dTsgpICy05pOGv1C7F 7KJuTNZZcENQhIt0Hhf7aBk5ACZlkHszdl+3upySKIR5hAc3C5Egpf103hshxHwfYV5pzLZU UV5w/alHpKIuW5qml0qHLcNG5L7WZSEdkXzU4pIgPsOkw8KcEMf6dfpqQHzg2qNMoRxtvo91 56r/AL4UYNHmMEQiFUVFRF4Lv5loMNLNqkyryrlWybon9fsqO6MoFakFkaNOBl2JT6K6I6CX dzbIHno22XUJwUuoLsSJ1LZeqhV48uZcopxUl7ETrrlIyAJi+XOi9fC3nv1U06jmrnkDGsKL cSVURb9lr9dI488gCo5+H1e3zUxh4FqE8xro4O42uKJv33rSadQzUVNNvKFNrp2pulQm1nBF Nx3ZtURVe2Xm/wCtW5ex980fL+vtt9qUeQsh22K17VAnzXU1HW0Uita6+agcWa0Ik7oJmKy5 /wAm3bT7rUpo22PvpZtg6960Ekgj9s2iWx2te+Vd6gzIDui2WIAw4jgcQ1cnXw4U5yV8H9Ms p5V4LVpD4trlzqnYP5S9id9abkxkXNPVy5t8vb9tDMR8FjEiKLt9lrGo6vakeOjOmOTKoKWa 6L19SVmkOo2ls3bt2+aspTmc2nrWQ78zt+1Kaki+Jsu/eyDfP5u2kmDIbKMvBxF242t57064 D45WfvmbbT/4r8KSE2+hROQq9p5LKhZxRF7eC0MZJAaxXyj+VbjbttWk06hmoqabeUKbXTtT dKgxXc2pKIkSwrsiCq3+ysSaxOa0JNz1js3RB5uULfatWkSAa4XUuA34X7PTRvOlkaBLkXYl R3RdQm5C2aJE8vzVjwzpAJHhuggEqIKCighf1p59yW202wuVzU5qgvYqLTrDEht15rywFd0+ TEC+cG322STMOyJH5u6Kv20kJt9CichV7TyWVCziiL28FpGOUgjq3sira9uNl67UwDU5lwn1 VG8peVa/+S1iqBK5DyUia5Q6OwrlTnb95fZUHK7mclOtNI7l6lXcvVUlp3GQn2BDFjSESbFe Clb/AEpxOVtDphqFmW3M/K83fRDEktvkIiaoC8ELhRGZIACl1IlsiJXJAkIsLkJPqChlVCzi l7r1WWrNT2D5hObH9UVsq08XKQBGRzuanNyj279VDGYmsuvkGojYluqfJaRIBrhdS4Dfhfs9 NTIzz4jCCEEhLoiZVUiRd/RTEh2cMoFRP7VbKjnoqWIYmzFeaBcxGqZme9RX+tAEuc2mHLh+ vmIUS5ZkS/8ApQYhhskFFXWrOCiEhCRoK/vq0iQDXC6lwG/C/Z6fkBHnMpH5I2uReZKjqs5i 0gVJrn+WiJe9LLbktlHRcue/Xe1vPWNR1e1I8dGdMcmVQUs10Xr6k+XwiMmH2geebJs3GSFD RAtsqpXhcAw5KvPy1JpOTndxLBZU233RaxRjEMPny4s9RcZJhHMpJkEVAkRUy8Oumgy5Moom W97UvJwvh+KNokz81Q/7h5tTWWGHZDzmTK2y2pqvPReqmgZjTDIy+tEdBBTrVVUaxF6Q7Lih MzNkwTKCqNpsOxDfv/aqXHlRZaTmYzkfKUc7u81UFU23vtSYxhKKOJA0ok0Q5eUN9YKnb2VG RUsqNjsvmrBnEYfJptl4TdFklAVK1t7d1NYyLLkiI7G5K/ojnJvnXQrJuqeavoW3FbtcjMCD 1XTesdRxh9nUxJ14NVogzAqDZUundWAGjL5ttq9nNtoiELhZLqiV4SlGivkXKoz4CoEGsIIG ZBL9lafxBmBNYPSyG5LFzOv5qCvGvBaS/ElcnjsOMPBolnZNbWJRtfqtWN5mHmUcnm6Gq2oZ hUR338y14Ro5/e6Dwd45Mv7xWsVdl4coP/Ojkhl1+OollzIoqiqlYKaMuk2DL4m4LZKI3y2u vDqWoUaUUqPEhTjkNEcRzfnFa7nk253GvCqAkOS5Ifk67WmySiYKgcC4dS7caiP8neVnkBhq KwWVCUxW17bbXqVheI4bNkvcrN5o0U9BxFPMJXRbJa/2U9HmhqRnEsY0/iGtIYQI/JohSFzu J2uKhcOrbu3p1Zc5zEF4ouiiKnoFN6w5p1pxl1tvKQOgoKi+msekcGnp5ZO/KiCq+tF9VYsT sOQ/FPCtJcjRWcW5qootuNlqSw485NhC2GjKkNKDqcfoy/Kt299QpGi6bBwnGM4ApIhZwXfs 2SsUgxxVtmM784wnO1xecgJ+1n9aU642yvLnzCU5HvutiFdP2URPRWH4hHB1pliM4LxOtqGb Nlyhv2WVawifpuOw2kdad0xUlbUkSxWTzWp/F2IzzsL5yGRyUQ55BpZCNB/4lv6KamxcOeAE xCPIc+gVHXEEkuWS1+H7qWTJiTn4EuKDaLFQ1VskUtiEe3NWFk1AeZh8gcYABFT011BJEJer aozTGu5hZMEqNS2VFyGu3MzLxTu/NrAsjLrunOFw1bbIso5CS6286V4WtjCkq8/MUmh5Od3E sFlTbtRaVyxWy3tlW/q414OucjlHyFxFkRQEgdy5SHZNl2zXqPIh4bMQXsRjuuK404Rmglzi UVuqJavC7UYlIy9HYyGLJJnIUXhfj9WlkvG8E9yOkcWnIjjIqiKpL5XFagwzhSldYxZDcHk5 KmXlClfhulqxw1ZeBp1uPkcJokElRCvZfVU2MMN76XD1EHmGcyvLzuYpfVRP61gzrkSSAtYP pEZxz5p3Dbhx2WsEd5HJUIU83H4+iSHkznZUHrtmRaxp9GHwZfaj5HHGSBCyoV+Kd6Ub8mLM kwJMYGkOHnXIQqWyoPbmqBpwH40VrDTAfoyNG1VwVQc3ba9YJMcgyyjMcqZdaRgs7Wdy4llt e1krDJkSAbUdickhyMDdjIN7nl7bre3GsUxCAy4bCsx0JrKorIUHMxWRfzdqYlMx5QMnhxta rkcwylnFbLdPPWHwpuFzfnGBZM7qnooqbZxK9t6jNMa7mFkwSo1LZUXIa7czMvFO782sBlIy 680y+5qaQKajmbJE4d9eFoDDkq8/LUmh5Od3EsFlTbfdFrFGMQw+fLiz1FxkmEcykmQRUCRF TLw66bayIKICDkve3dTsN8FSJhzhJENfriW6eyiqPprwncHDnZKOSI5AhxyVFRBBFJE+tltf 0V4VoEWe/wArZY0SKOV3NrcLfZUd4GHhY+blb1NEkFFziqJe3Zf5PCfk8V8s0mO8IK2Q64Ag ZkFV48FpiUzHlAyeHG1quRzDKWcVst089YfDm4XO+ccPtc3NRWUy7ZxW9lunUlYOHIpQut4s jxhyY8wjrEubh+SteGMVYkknZBuuNZWSVDQmhQbdu9eD2WPINQlRzMQYNVBE4qqW2rGQjNPC r+E6DbqtkIKdz2zelKJ/5pxBqczGMCWQji5Lj5I38q69lYSUiNIDKy0y4IsLmBcu6knUnHen hitq84JtuKyPFwRJFUfsqPNbjSkjrhxtq4cYxsWcVtunctOsMRXRlhJJ1WHG1bJwdfPbftG1 fOEdt1tljDpAPE62oZsyJlDfzKteCHJmTA4iA644raigjpWVL/nLb5MWi4jh86ZGnEJslGzq BpkEVArLZOHXT5LGeFgcMbazC0ZDdCJcqFbfZUrBUdZktSozzJI3oEpISH1hxVPNXhOrXKHM Rmx1Xk3JXAXYMg5UVN/P31hsx6O+jHzZo5tAlynmRbKlrpUhkYzuZ+ej7cZptSVsNdCtZOHN rFY+IYfPmRZ5C4yUfOoEmQRUCsu3DrpcN0XWXWGhXnCuRU28kuu21YanJnVbUXEWUwzqGC7c 3hzb9vdXgo27ClCsV+Rq5mC5l0O11t3pT8kYcko7ONrJNrRJFNtQRM4pbnWXesafRh8GX2o+ RxxkgQsqFfinen4O29azobIadnWnm+RRXgu1Cxy6Y7DFMoxXDFQROy9s1vT46jmUb9Y8aBpo cjYpZET8CWO6TgJmQ0NospCSLdFT00Juy5E0x8kpCjzfQKIn4MQoatqqeUPFPXXSsv2Gf+yk S9+9fuCC4mYUW9vEejqZNi6KgpBa9l89MRAcNwGQRsSctmsmycK6Vl+wz/2UIk4Tqp9crXX1 fIzmeejusnqNusFYhW1vNwVazm+9Letl1X1S9vQiJ9niE7b6Qksq+M5MlKSMhxURUqkMrrNu Mta1jYJM4flDtulI7nnMRy0SF9tohvmXZEK3oWnxVHHdAc72kObTTv8A9Kh3M3eWIpMKy2po fNvtapL4ctJ5uGLxRCBRTLvvZfrf5VhCvsusv4gCKHN5qrlzLvUhoRK7BIJKqbXtf9ypUtkk kOORERXRbYIsqL1+bvqGrSlJWWKmwLSbmKJdV+1KguITriTUJWcjJLmsi3Tz7cKIyR4Qb09Y ibVNHP5KEnHrSpjCjIcdiChui2yS2Rb7/ZUVltXF5UOZhxW1QHNr7L5qHUU0aV3Q18v0aH2K vn27KxNXmXI7USRo5iTjsP2qpcPNUwDR1p2IGo60Ta5sv5SW4+imiZCQWtk0rtKOpmRVsKrt wRb1qgJimYhsaWVFRbL+6niNT0GT03X0HmNl2Kvp9FBhX9qajrEJzPHXKuZSREK6dSb1ATI7 NNx5qNqLa63VEUl7/wCtY2UkpTscGGHRZQVPTSx5tk4Uwbd39cc7QtJdTTjekkRizBdRW6WU VTiipVjU9PWSOryDcBcX6q08Rqegyem6+g8xsuxV9Porkpo+5I0tZAZZI8w36u3jTjYa/wBE 4TbhkwSC2qDm5y9Xpo231OMqMrIRXgtmbTiqf5cakm62+ykdtHjzN35q33S1+xaisAroLKDO wbjSiDm17IvbTO5oy85otyFH6Mz7L0+S6+Rh7QdPRKza7cexN0pI/wBI5IIFPTZS5IPbWCFM lyyfflOo2fO+kXO5YTXst1d1PkuvkYe0HT0Ss2u3HsTdKGPY3pCgruk0l1ypxX7aGVEIjYLg RAQ39dY7Gm4qUaNH0VZE30C1wuXGsCcj4g+SSZ7Qat9zacJVsvotvRwsSlPYfGJsOROiWUDX 61y7fPTThuOyDB5OUvtCiuaObckTzWoZcHEinYabVkEjzZDunp9dRH8MdIZAvXVvqdEQM1G3 7NNy4BfSzA/s69iql7/spdfRWHyJDpvPvN5zM14rWIvsuky8ywbgGC8FRKaMnnFeKKhq7m52 bLe9YTLhuPTR5KT8uMZX1RTJdR/O59/RWESokkyivoZWAtj22vXhDDSc822yLGjzvvedFzW9 XXUnDvnKYkcIYPJY0vmUlTsoMOcxCRpDhovFkK2ZzPlUqTB5b/K2JDKvRniFENLcQW3Hz0w5 GS7EQhfm9ukq5bfxL+zWJ4kzPeb046myDSplSw8e+oss5r7wOR0ztuqipmWy3T7alRpWzMlt JcH9H5P+RftU4+5fTbHMWUVJbeZKKQGsLCNg4jhtEiFm4IPavVtUoHSKM7GFDcB0bLlXgqdv op2O41IbebYWSoE3/doqJf7eHGsOBM//AIgGowWXZUy5vRtQ6imjSu6Gvl+jQ+xV8+3ZSAAO uCrhtI4I81TG+ZP/AGrXKVYNj6QxRC7EMk/pT4OKeWOoC84I81tS8m/rSjayuOZHAacIBugE VrIvtJ66clyM2g35Sgl7UUBc6SEZ1/J2UL22qKoa2nJdVkHCZJBz3VLKvbtQtgLhCThMo6g8 3ON8yf8AtWpk3lLyxmnnNQ5N7iqLuiJxt1IlOsPDIafba1yb0SLmflc26VEab1UWW3qskbao J7XVEXt3qMyqmKSVVGHVHmOKnUi/7vWJrDdfB1jmLIY4Ae21/T1VOJtwmjFkyEw4otqwqI+T /KnowKLrrZZXiyIpWLrWtbXlONOzCYQnQJVRxStl7kTvqcVzZ5Fu+jwKKilr3t2WpzMjzZAw knKTa3Vv8pLUy6jcrRe00B3QVAVT8lL0cTKWoII4q22st7fuWuRELxytLWQG2iK6Xtt66w/S I1SehaJZdlypdUXsXaps09UWobitPJpqqiSf/wB40cbJI10DUANErujwuPbXg9NjPvrCf10J kBXnqgrtl43vTsoDIBZPTcBwFEwL8lR7amLI1mTiChutK2qllXgu3VWm21IJ1VLKGllU0S1y S/FOclMvhfI6CGOZLLZfuWJ/8CfxJTcxIjjfJojzaASjmcM7Jbj1W+2oGHjCNZjQxxJrOG2Q hVd72+rWLupEOXHn5XQykNxJByqJXXurwVYBkpQwM+u6JCiJcFTrXtWsQdSOqRnsPSMLykNs 9yXhe/1qjtSGuQzsOZA2lIkKzjabLt22t6aDWtyg/pHbflruv+XorwiQIpyczUfYVTjlLZbr WBwAZKZEZaIJGg4gLn2tuqpzePCvBwHMPJOQvvq6ouBZEJDRF4/nVjMfkRPCWRYhC6It2S17 pfyr341jklYDiNyYrYN88NyRCunlfnV4JAUE7wNpHPDmfRKH5W9SYTuDMTGjkG81PPIqIJFm 5yLvdL1jsduOOZ2aM6ObhJpu201yKnH6i8amOfMQYa8TCt6aK3qOL502t56weBMw50yaFsHU bcFHGVEPvgqhdtvXSNznCdcEyyE5bPkvzc1uu1Y3hHJleSY46TEnMmWzn5W97jeo7iRnDhNY fyXlGYfKzIvC9+qoyxmtdxiWzI00VEUkE7ra9Y+8sFzJLiNttc8OcSId08r86vB6R82pNOHE 5LJhGQX4DzhXhxCt4jcDMubQbtzfPba9SsP5DrMHJN5qbqJlQTLNzk43S9Y3hHJleSY46TEn MmWzn5W97jeoLgsG5DZgLFV/MPHMK8L3+rXhPEdZKJy95wmXCIVRUIBHqXup3X8G47EltgxL dtUfXLbKNuCL31jAByhvC1iLpMSiQibOxXQVuvN4V4MCrBx24oNvG8qp1NWRB36739FRsAfj qBMugiy0JMitiebMm972S1q8JowwD1pspXGE1G+cNgS/lbeTXzi3DclRpMYWTACDOyQqq9a2 tvWBMnh554uInIds4GwKrm/H89K8JowwD1pspXGE1G+cNgS/lbeTUaRDhPuyAiqL2gbecRIt kJCW3UtNxmIz8QY30StSLZ0Xjvbtvf01jss8NfOPK0dIgNrfKNl+vWEozhZAkbEGntBHG7ts h2861/NUyLPwkpsA7aVsi/VS6Kl+2+9YfHBkpRg8udnUTMLS5rDmXrTm05iMWGWGxnGMjza2 TVcvsuVF6t9++sMVqMbwNvqbhCQplTTMete0krExRNeKGp83sCqXFHNy49+yentqBFlsLHfZ byEKki/uWpsPNk5QybWbsulqaw88OcCYLOgrmYNK9rZr3vb0XrD9OOZxmYzjKvXGyKqt22vf 6q0MiIVsLdzuHH/wnVTiPctY5KdiG3GlIwjTqkC3yCqLsi366kzCiGkM4gsI9mHykJV4Xv10 WIDh7z0TkPJs4G35WfNwUkosZmNaKMsqzGioSEW/Ei6r+mpjmJR5DL8oi1GOUKiZOApzSt5N vtqXhUiA4swWSjNfSN/SDwFfK22qJEGE7qOADL6CYXbDZD3zdl+FYZOwmO/JmRHvIKTdNJUs Y88tqdYbgOGjkY1zZw2PggcahQUZRqfGbY+heVFEibUVstupctOmxgrOFy2ybcFolDM8oGhZ bj1bVldilBcdwh0EbdJFVLuD2V4LamGuNJhwk0+quB/hZMyb8Pt7qkwncGYmNHIN5qeeRUQS LNzkXe6XoJcRh6DnkHyttTFWHg3sdr7EvN+2iiSmFaVp51RPMio4hOEV0t5+usZj8iJ4SyLE IXRFuyWvdL+Ve/GlnQ4z8CfqNpqi4KtPt82+ol+rnJ6EtU+JHRFecbsCKtrrTOInhzrEfkJM qhGGYSzovUvdWFxlw9zXYxJJJhqN7BrKd/K7FoJkSO/BzyD5W0pirDwb2O19iXm/besbYmQ1 EpMl4mmicHn5z5llReN1SpCycMnpiMiKsVpx5Wsq2RVy80uK7rv2V4JgUJweQsq3IXOHM+hy flb79lRYMrBY4nEsKYjzFQxTgqJ5WascwcIByVfdcdYkiYZSQizb3W96kNIOR11khQSXgqpX g/HeinF+bVBxwjUecQtqNhsvXekD5ucz/PXLcuo3961c9/KrwjkR4mUpEdtIxuEGUjES6r96 caKX82v/AEuGFHLVfAj1L3353++6mMLntrGJIgsndUXIQj5V0XtS9NypqoUySiGZDw4WT7N/ StNTEimcUYJsq6hD5SmK8L36qwJ0sPcJyDJkK4wJhmyuZ7KnOt9ZOuvCaNyEtebJNxkUcDnI qD391Q5nI3OThCNoizBsSkK28rurCH3IDn9klSjcbQwUsrmbKqc7vrGJDYAEuVIakNx3F2+j y2QurfL9tYiDOABAkvM6SNoTeclv2otstQ88OSJCJEMmM4IvRj2t19e/bwrDGpbPKJBDlkug SIje3Hv9H3I4ssFcYPygQ1G/qpBS9k7Vv4seS+zqPR/vaqq2T0cPkkTWxJJEi2oSuEua3Da9 vwZxh1FVpxMpIhKN086U1GYRRZaHKAqSlZPT4ySXWySQiZdVl02yVOxVFUvSNtAgAnUn3DOZ vitrfRyDBPUi0qgbxX/xXzc/iX7umIZC5Wjekh6hWy9lr2+5lHlNI8yX1Vq7ImpWtmddJxUT uUlX7i0MxnWFss4oqqm/9f8A1tOTBwp2ZAFVs8joiTluKgPX9lRpSy2m2ZCXbJ00HN66+bNR OU6Wra6erz9dSpSSmnW4wqTmk4i27vPUZ1ZbDaSBu2hupzq0s46ts2S+9u2iZzfRcmQ8vfmX 5A1BN541TK02nVdEuvYm/wCIHCcLMSSXwv3I6aJ9ifIrpQHUw8X+TrJUkTfNlvl45c3X+HzH WiyOA2qiXZ+GqPC6WpnDJGHTHJkUdIEYYUgetwVD4Jfvq2KwnJouQhAdBhXkEs5kbe3Dyk34 bU43HhORnZGD6DSCikjZpfmKfVttdad0W5ZKGHvM5XISRxS6bBw5y37KbeZiy2nTggzpO4er zb1s3MVLXBb9e3G9RxdiK1L5MikaBcR7Qz+fqo/1RP41+R8GmydcUm+aCXX74P4gd/W5P88/ k/t0PEG4cZ76BgYTqo4SLs4a24dien8Pn/ol/EitMSeTIkBCVciFf6Ra6V93GulfdxrpX3ca 6V93GulfdxrpX3ca6V93GulfdxrpX3ca6V93GulfdxrpX3cabfLFLEV//lx7bV0r7uNdK+7j XSvu41OaXFNmHBFP7OPWCL/WulfdxrpX3ca6V93GulfdxrpX3ca6V93GulfdxrpX3ca6V93G ulfdxrpX3ca6V93GulfdxrpX3ca6V93Gulfdxp3LiWROVSNtAV/vjrpX3ca6V93GulfdxrpX 3ca6V93GulfdxrpX3ca6V93GulfdxrpX3ca6V93GulfdxrpX3ca6V93GulfdxrpX3ca6V93G ulfdxrpX3ca6V93GulfdxrpX3ca6V93GulfdxrpX3ca6V93GulfdxrpX3ca6V93GulfdxrpX 3ca6V93Gp7q4jqILS83QFL/iQ/8AlyfzF+6sftfxL4mMfpg/lB+Au/rcn+ef4hxP9Cv4kP8A 5cn8xfFDFFxuM7Jy5uQE0PPW/kbb3qZHiSfm+PDygR6aGZmo5rb7IiIqVBCRKYiyHJyRylCK ZVbsXOsvDhXzeuIM4sysdXldaBEVpcyJZbbb3+zxWP2v4lpoG53ze666jYOI0jl17LLUx8/C gtOJ9/tCbXJtf9yp8mMfpg/lB+Au/rcn+ef3d0o1+VR1SQzbrIN7enh6awtGCVYjLPLzt1qS WbT+JfQleDrT1zB3EsppfimZ2sMZhKbceajoux1NSHmjmQkvw7PT93xP9Cv4kP8A5cn8xfFi tOsR1ltJznmw4rfttepUvDUjvty8qusSDVvKaJbMioi9Vtu6oSTX2pTozklPCX3tBsqZB9fX WVhltkexsbeKx+1/EtQjiR+VOMSgeVrOg3RL9a1j0dMDVFxIlUV5U3zPoxDt/N+TGP0wfyg/ AXf1uT/PP8AkJHzrrOZ1zrfL2CnclRIISZLIxXtdt0FHPm53aNvrL1VytyTJnSsuQXZJIuQe tERERE+74n+hX8SH/wAuT+YviRG8ublDulfs5hF/0+JIlKOdGW1PL228Vj9r+JajM66xm5Ml tlx0SyqgLx36uFSJ+FPNRp8YdQCZk3U7fVXfnX+TGP0wfyg8RiJl3dacdzdmVQT/AK/s8Rpc ubUdFr1rbxH37ZtIFO3bZKA7WzIi28R39bk/zz8SRGy20gA83bmzf9viRo+W+tm37LJ4mqo5 +eAW/wCIkH+vixpSDkR9oXMvZdL+JITLl0XVa8/D/PxDiZdxaR3N51VP6eJDby5uUuq1fs5h F/0+Jif6FfxIf/Lk/mL4mDfra/yXfExL9XP93isftfxLWnJYbkN3vkdFCSuioX/64f5fJjH6 YP5QeJA/VJH8bPiQ/wBbZ/i8Sd+gP+GmP0Y/u8R39bk/zz8TEf0DH73PEwv/APL/AA+In6wx /ODxFrCv1Vr+BPExL9bL9w+I9+qB/GfiYL+tl/Id8TE/0K/iRXW4b0sVgIP0KglvpF/KJK6F ne2x8SuhZ3tsfEroWd7bHxKw8xwaZZh/UK5scNMx/wAT85K6Fne2x8SuhZ3tsfEroWd7bHxK mRm8GmI460QDmNi11T9JXQs722PiV0LO9tj4ldCzvbY+JXQs722PiU0w5g0xTG/kmx2qv+JX Qs722PiV0LO9tj4ldCzvbY+JU90sGmZX3BIbGx1AKf4ndXQs722PiV0LO9tj4ldCzvbY+JUa UmDTNNth1teexe5E2qf3n5i10LO9tj4ldCzvbY+JXQs722PiVHQMGmJkfBxbmxwRf0ldCzvb Y+JXQs722PiV0LO9tj4lSWQwWbmcbIEubHWn6SmgXBZtxFE8tj4ldCzvbY+JXQs722PiV0LO 9tj4lOomETD/ALVIW4kz/jHt98roWd7bHxK6Fne2x8SuhZ3tsfEqXJXBpmR1tsU57F+bmv8A 3nfXQs722PiV0LO9tj4ldCzvbY+JUJ9MGmZGc+bnsX3T9JXQs722PiV0LO9tj4ldCzvbY+JW k3g0xC1Wj5xsfVMSX+87q6Fne2x8SuhZ3tsfEroWd7bHxKX/AMFne2x8SoUZzBpiuMsg2WU2 LXRLf4ldCzvbY+JXQs722PiV0LO9tj4lS1PBpn0r6uJY2OFk/wDqV0LO9tj4ldCzvbY+JXQs 722PiU5K+ZpmmTAt+Wxe6ES/4nfXQs722PiV0LO9tj4ldCzvbY+JWHODg0y0d9XCubHDTMf8 TtJK6Fne2x8SuhZ3tsfEroWd7bHxKxBr5oltZml55mzZPU5+IMTmCOH8mhPOt6RmQuGgL29q 1LdJBUGYYytCxau+bj3bfvqO6+/pK60jqjkLmJ2rtsnHdadZbPM41lUk7L8KP9UT+NfkhR2E ZE5Kl9NJWwDlS/rX/OmpRNo2RKSKgrcVsSpdF7Ftfx5Mx372w2ri27qVt4YZhkufJX8ysF+Q af17vEeiMu4aANyFZRp15dc0TylQfX6vEceba5RKykTbXciXUl7k/wAu2kXt+6SIPJDYYbZ1 BcdSxOc617dnyO/rcn+efyT0bbj6UIQIgdNUcfzfkfu8/wCGuOqBuZEvkbHMS+ZKfdfj8lNu QbWle6pbt76n/ol/EGKg74MjLkPyXnGpqm0mxFzVvfMlTBdXWNzB24mupeW6mpf+JKZcbw6Z GmckFlDjSG/KG/NdFVyqPX18a0pLOUmwD6YVTK4VudZOqikW+i5Ojd+/Mq/JCkFB+dYTYGJx Ob5S2sdiVEXgqemtN8dK7pm2xmzaIKvNC/d482EJZCfaIBJepeqoMj5r+agixiaPnB9Kq5bI mVfJS19/EcgJhLUcylo8k9nIjaJnzZ+ObPbu49fiYo/EmGr0iNojGyBZUt5KEvC600Drus4K bmqIl/V90OXk/s6w0az3+tnVbfI4DiWJZD7noJ0iT7F+TFs2GfOD0q3JJucU5PzURE3W42W5 c3tpsXD1DQUQi7V/DZ6PBk1Zjro73uKrstSmGku44CiKf+juJwcMwZqYkFzIRFIQPNx81Yak rDGI70iRpugsoeYG26b87zJQsOSGgeLyWyNEJfRSP8qZ0FWyO6iZVXz0DJOgLp+S2pc4vMlA AS2CM9hFHEuXmomG5LLjweU2JopJ6KkS3tmmAVwrdiVh3zhhKwoOJLliyEdQvNmTv+SHg8EU ki4RA6/wQVROCdvyw5PJ0eim8jTxX3BO399Q+TsjLlS3kZaaUrXv1/u9dYxh5MI3yAhHOhXz 3v8A5UqqtkTrqRCWNyccquRzv99FCt/v00GCSGRBk0FBkZvrKm16k4LoogNRkkat913Ta3pp pcKw8MQNV56G6jeVPTSE1gjXJBkaD7vKE5nDNt17LUpvAMISfGilkOQ46gIRdg1LxkYRtPxl ynGe25106/TUSc5ZnWYB4t9huN6lstMRxgMGQZ9a7pW+tl7KWMMplZCf3KOJm9VGj0thpQtm Q3ES1KpzY4ohZFVXU2XsoY/KWuUEl0azpmX0UKSpTMbNw1XEG/rrDgcVHCmui2KoaWEVXy17 qQhVCFd0VOv/AMj+FOnikzDdN8b8kcy575uPqrwMjlIdlE3ORNZ5bmXOHjXhd8/5PnDWLQ1v Ly75dP7OHdUArXQJeZfbKvBzkkhuSINOXJosybiVY1irTOfFWjfFh36wczq9a14POR5OERJe uKibZOLJcXrE0QVqa1KzcmJktTIl1y26q8GYMbGgxVsJIowy21lNsEXifmpRkNQUwfUOxBfV yb5evzV4JtstAyF3lyglk4U9yZnCFj5109Q3M2Xqv3194wX23axOFizcMXjH6DkikqZk3S9+ +1YQsgV0sFiWLN1uXsn2W9mvCvlstqLqOhl1StfyqeXDZASnJh8kbVkr7rx+z99YFiD2CpBZ wmzZvA+J6gku90TtuXtVjEfMn0mGg4w7+SXMyrUv5wBRmsQNB2/WomCX+TFP+YOfwjU/CsVk BBmRpBESO7Zksm6dvCsXmBGcjtXyArn10Q03SsKbcFDbOC0JCvWmRK8KpMFgRxBp2QywYJzk TLsKVFeim3/8Q5xUVAvp9TPv38P6VObxVhH8kFoybXhnygn9Vrw/kPsA65HJ1WVJPva89bp6 krwPntNIM1ya3nf+sW/b6ErF2uSwG348dEdlYm4S3S392HbXgY9LFtW+Wq06bnDT1eC93Gmu T5dDImnk8nL1W/8AI7zrMdpp15buGAIin5166aN+O08bJZmycBFUF7U7KkvxpWHPNOpZspkf 6WOn5hIlMYS7lmNAKoeoGxqq3XamiYgRmSavpkDQooX42pW4sdqM2q5lFoEFL9u1cqZw+M1J /wAUGkQvX8hvRYMeO8flG00gqvyNPuR2nH2vvbhAikHmXq8R0o0VmOTq3NWm0HMvfbjROvYX CedNbkZxxVV9NqaQMOiAjR6jaCwPMLtTbZdk9VEy+0D7JeU24OYV9FarERhlzIjedttBXL+T 5qOWEZkZRplN9ATOSd6+hPkIYsdqMJFnJGgQUVe3ahclwI0ox4E60hLXJnI7RxrW0SBFC3mo G2wFtsEyiApZETso+Tx2mM5Zz0gQcxdq1ywIEYZV76yNJmv56OUMdoZJplJ5ATOSdirUlBiM Ikn7/ZtPpf8Ai7aZZWHHVllczTatJlBe1E6qCU9CjuyQ8l020Uk9NckXD4vJc2fR0Ry37bUL bYoDYplERSyIn/oX/8QALRABAAICAgEDAwQCAwEBAQAAAREhADFBUWEgcYEQkaEwULHwQMFg cNHhgPH/2gAIAQEAAT8hcFI4lXADtUD3ynxDzJr2WTvZ2YF8KlABzhkf7FSmvmfE1lHkTJxI T57yO/hEgdwbHFymhMAiDFcvk7yFUHKbRv4xPlIwwA/n4cKSwZy8+RXzgvqFpU0imJfjIv48 geB/LCbnk0fY6ywgTR1ejs++bHqcQlfk19degzyJVxt7MbGDYko+zmMLUbAYcYQ4R+rWnRpA 8GHhCABWpj6x5+xhXB57xLsfrtcw9ZFcPgEk4DJAtcQk7oqcEjfb66PYgo1yL8c4rogbSwLI b3/wFixJGqBcDEfOIZkaGjpTWcEj/ccBVLsaVI2pL7NYJrPNUBj85bcOeJTEOoHxxLArdzD+ H88/t+WQVsqOY/qKYhWWG3ciUCx8Ybq3NCSfLBHkMF7WRQmHibPf6f2XWVMCpCII6RqLluZx hl/Qx8Nz6wVcdLSTE8oMdjh+VMeF8jXlURN/AJZIZ0u8xQQ6yeckMv6QlXw/DrHyiQjcposY 6yVb+KoTD2JY8Y84mJiBHQrWTKE+rJpyZ+OckMv6QlXw/DrPwH0jLRwt1yPCyJ84haGYAYna X4OTkMuITejlhymBj4z3B22DOO6UQEiH3Yex1Mhujsn2ZFbEmmCS8xL3qZjNH5BQsnF8iiPG RT9JOKBXYU9ZC+Wk5ZD72TQFhnIjY4z1OSGX9ISr4fh1j5RIRuU0WMdYQglISh+Q+z9+k1RL iux4TeI+PqB8Q/vGO4QY8ZqJBfK4RH+sYTHzPnAIAKA4wSYIkRG1VXEbcYORDPcAn4ylXYA9 jKHWqwQB0t3WSCuNllRYEj894tulqxEQJvlc2xD5FFgll7n6BvelAcVuO15xCmZMyrAJi2p5 eKyKaHuw4tdOx8ST/wChZk6YkQdPym4Rso2JhHCs8n2Ux/ZwYlmkYMg2tc8yzMufbE1GgDX2 8YNr6OLuLT7s/Ct4BAm+54xCd/TEQniW1GRlsImENB4TPtiajQBr7eMD199LuLTXeOt8CGUa HPWKcJWaStlvhMLnBTOYLTTnDiROeCT0PfP4K5mQ/u5wi/3gAUty0mQ7bagFhab6TjHn6DVI gB45XJRE0PlgSINJz7ZIaWDNDa0DwbbzxJm7HfdHeNItIZFACEfGfbE1GgDX28YNr6OLuLT7 seTF8oqoE22v/wC2qnPXupIl4+cXiLhCDwrYrOayCyBXlt7ytJsNiE9FdMM4x2CbuHeHFmxe bPG495UBqAVNyFl8uMdaZSfYMRSBJqCv4n2wfMOHK5DpjhyXtJhAkAeDI9c84SUeIRS0aJyH tchB1cHtmskJEbSdS2C29YggFBgJzBfkRvIi+YzNnZ9nxh0hLOZBUmCxqcjElf5wHcW+Z1kF dyWcSoTezvFdnERWmmtg0HGGQyQBkh3Oy8oqNwRJY5hLx5U6hSiZQm1QVGLBzdAUOw+XswWS eA2F2HIZMtumQKffWb7Mh3LvYJD3GA5JI2RJxSNSlwHpH0sHgMn2yOsexoIFJCHOxneBcmQm +QSfvkLqFrDpcZywkGkMeRA8DAqgc+cdskgh8ssFhCjUCmh8ZRLksAYotZ+3uMsKpxlRLFtN eHrFbwmUBJlNavDgiOWOgZcOnCK6odhAtQNHWeBqRv8A6TlNYgI1/NBiWJRD8mRfHJS9mBIJ JWjnFSVBVaCCHbI1HkwWUhECBPESBJO8F40GOwjZww684rUxNAQ7H9JjAokU1juMpxY6SwAO dAGe4CQEJKyxTrFzkgggLJ0Rc6xcG3E+ogRAshjrLrlUtNhPZPDjCZuqqb+MikLZKnuDT2rG Rxp20CB2iO5rAN+Ss0Q+Wo7wkL+vC827MsZBUoO0Ghy6MGmqICUgGOGjuawDEj1KalqBo6co Zlan/wABG5reTyMjU4EsINbvGJpTjsgSQpHD5xgjfonrelyDXOCykIgQJ4iQJJ3kvRTQNKg8 CN34zmsgsgV5be8rSbDYhPRXTDAAyE1yPtgvzPESSacgvsTkQU0S+Xm43h+iq5gkgEURCLwT oDIgsT7SJ9KB6GoEDvTbU4xNKcdkCSFI4fOWkQ4p3yuyGucHhByzQQ+fcisDjpsAtCDEEO/B wuTCuDRkRNkO0p1hrkRGpXyuNUCt5N6ab8ILvxVklFPCKX8mPH9GA2rxkRMicQGE2I498Qwt qEFz6gecShxIm2mQtw6cOGa0EmT4uPpWk2GxCeiumGQxZHWU+325oq9KFgQVbABvjLDOMPRH tKULrvKNXOQubZJYd4ZH2AUx1y+2VpNhsQnorphm8bIShqISwSsFvWEWIUbRDwA3jAGo0P5h UbwkL+vC827PqAnQri0AbMPt96p8ExmQuy3IwQ9dNpgGkRpCJES798aJRPCy/m+9eMhCciqV QeBwqhhd5QIKGDawc49gSoCUu5NXajHJoQ2AtlB90ziy1JSS2hhuXP4Z8bQhGGEN+igjTC5Y h25qs+HgwY3gZDIKHQAV7f8AgzomJhBQSMsQdr70MAJaxZEDi1QCWinFnEjEbIysLsOYJuIc 7e/IhC0gqfOStXsYmCBz5O8FllKi51O4BmsFSbH5iTh7xU0pSriQnuzqXwnGQ7C9Kq1dh8IU VgkyVtNYVLXfVCUFDf2yfOyu3b3OPhLWCZnZN3URczERc5OjxxIZ5kgCJiQlzd6hPxoxCPfP 0egOEiwHpBr4mIWcDFFTyhiHnFsdWLXEKLpJtjxnI5yjKMlvWQHqr/SIMs9YmdD8iPOvlis4 a8lAiqV1XeRLNGxE5SyeJySru6ItlWgbbYyO3SbliWAFk2qIlsrPL5dmAbeSMkYwSmtNqdsU guXUzWtEkTa6Q4xTCENJSBgndhCp970SNvPsy1Y8beInJGqxjk3DBA3hOc9MqYFJYn2hYJtW oDMQhaG/ONDTQiAnYrE0Du3BfyK+sxsxkq8jeAE6zSGJyWiJ+jw6SJhSefDAyhAS03SH93Nu AXHLgIEI/wBY5fx+Q6VmhvC5+Y7tfmBv2ZHebToJBK6S9YmJNNZ9yASFDkyk7iBQk/8A9srE 5y1uCALEPKUMWFk/FJBRR4dYay6Ra2ksNBtYiJcupmtaJIm10hxh/wAxTgpOEgnRzh//ALVT 4JjMhdluRgh66bTHRoYIiLO8tu0yQfl+cOsepUN88blA6cY10dNMSoYZ6CdGFY2en2qgMKP0 enRhIFgNKDfziwsn4pIKKPDrDPECkR8KgJViIvOco4JqLxBfxl8wN1ShaDRqLjIDr/g3Uoec Fo+XhriBjm5xtyV3Yk06kQaJqpVLQG3pAiif/WaqWiBb3FXOspA4SSuyY/0ThAVdyUESYPwM BIRL6AIqKuq7yFA3g1KEMuuy9X9KgAxMiJR3pDKmCF1SD7YTyHLsMgHuCFNYkT1KKhJa6SOm qyfARzdKiWB2GNQoZ6dC0EpxrBrAIzIwGPXTaYIoC6WCP3B98HTNKlUooc38zZY3zciHIImF 1hLN8aqiiWBOpxy/j8h0rNDf+O7UdpWcS9qCvA7+mowlDGDMOBB1EVwhZFMnr100TQPbCw9E x/hSgipAlOwDjSH/ADAQpJoqUW27f8Z0VAIfKQT7n0Io4mEOx8/oQQRvYU1Jz7Poof5OhDEE /Gax17FZANHX0In0KER5WAfY+nKpJtlsVQhHeB0sA+gEaJi0E6PQUqhKtHB0e3qjAfNhLBRr 3axM2E9HSNvax+JaT+1DZ8kc4neN1lyj8BYkxcYOhCBArhCoUbZMjkalpoEZKxZ6cYOMf3pA lREpO4rCHd5gMR5sfORqadyXjoE8MvzOkAsQAGxNhvJFVCCZo7DlODcqwiMlR2QMTcY/lsoJ QqyFeskenFanFLS3w9YVEVFq2Op2aNLOJRUZda6XiBx2x4JiIXMBKNPKIuMCoCmGLAJNtUYX mIz8yT3WVTPPmR8CEoJyTJyJBt9ymD2S2MYiUWDQ0xYmIPsxlkUYyPUCCfbnFMfWRSCYghLY 2cpijVAd1CliJrCiFx4IE90JiBpRyqZ58yPgQlBOSYon61AA0LeHTOAtuMaihWOYaxEv8D+L uVHhl2pYLV2XMbOc5xFxwLIQbMSjzegJHyRBSHhccgT8XNtNhT/rCyCgAFN6LanbqcKTFNII CKNo06xyBPxc202FP+sixHXGDaVIO3ic/MtXUBFPOsit5+FoGzce2MSd1lCiJGOVZyHZhXzi wRWOJbIyjfBjiB6ihYiMQgQIpDaXTh1HnEi+Cy1Ds1q7wCdCJcykeBjzMOqmaKfg+Mg9QQV0 9/Zy/GCrNz341gwDITBzNCUBDSO0pnEhE4OEZk+HNV16V0pbeFoxr0KVbM+AVi3uKzsgMTEx rE5NLO4igpZCe5ysZtJkyD58McU3CSZGVbPmIDHhhRZCqI4/OQm+fBZHuxF5ZfrFAG6FcPMY O+4jdpK2MRHpXPBpitbXW8uYlwUBuH+A1i22ZWFIPba8KiKi1bHU7NGlnJN8ngXtkiGUiSJy 61ESxNy3BnzikMkiFhzuShiSYwe+drLydLIQFsIuozszEx9tYDDIk0QSjbLEbw55gOMBhSXB 7TE5MBzExeySIZiJIMBD9FvnCAdCeMnyqDC+wgpNzJGUSZWoEFIBPz1jUDLhkvsBSY6TlUGi xIt24S6TaYxjoIM0T7YTENMAByNz585Ic1pKWl5gIUYiI7V38xMgvxkHnWg+QCU61s5MnOBr lKa3TwO3CJwvlBbtavGTqZwcxYELPDVzGEaMTRE6QlvNQNckSQTVOnnG48W3Dg0H/wB1eJBm TIYRJApHZiyKT4oSCZKQcyRhriIzpbCtTMHMZaAgoG6c5U3NYdZJqAkk4b/SlQS5EAdKZIHW ArWKRnJAZ2rwoUXyZT1SwbBFUhJN4oE1qx8JTpNGTpcmA8YUuMQhATV7KQlDcaYL3bxpYTwL DwMrv7FNGAie/D4x/ETJUpIXuWYKdJv5iYQqqU8waw4y/WTSgWKwiIhOUQIff2qNLapwyEv6 YCzU1jQ72TfOXURutbybAMuiSIWDALMjIFqJNDgPlc6Ityy1RIQyQ6Mwq4w3/K0576NUx/OE CixDvmcCKaZgjBVJkvFzpbRiy346YEgmO3A+oGeDdCzbGnLw+DRZ0K07LHJGs8fd2u5Me0sS wQWlvES3lourN4QKLEO+ZwIppmCMd3OeGp6S45yGuWQEUZLcjw5N15KCpNuSwgq9k1xdeqxI Gi71liyWeSITY+Ba6yKyPLMcosDb1eKbr2wAnyN+MhtfiKkgpTmFvAGawKAHPo3Tim69sAJ8 jfjKK0Y0POhxFseJmZIOHIakjTIfhrIMo5FLmERbWGE7AIxa5RIJpDjEr8158BRKh3sgy6QL stBAZeUVExknlUSYsqCFqT8nBcGUH1gXoecSmVAgAdgI3NGB1LX7ORYzZIAuTy/ODRi1otd5 keCMiwxIlC6StR1hTulEA/mThMKE0EsRIulYyxtRvgijpkV3QKs+zRGGXLZIpYMFoBEc4CWU GOFn025wgC1WlFbSEBnrnEHSaoSKBaCTbOHAGjE4A5Ea6MrQWIsSB3ZWZit4wCIk5iSNDfN5 Y2BHJqjjna6AtCscPBlmkX38GQhCp/YHM8Gh3sm+cuojda3nU0+LbM9IDcvMRVgchIUIPB8Y cZfrJpQLFYREQnIQQ6AWHeShBOw8KsfBAWE8TEY4NMMkIily0vExg6xyobSjTXeOwW6FNlek jfuFdq3b5SigHnInw4PBmAsGnhRkHLLvqmfI2r7ZD/ENE6YiC4i2eEaBy1fRQVTUecjF2tYk KSbeMlxkagmbkUpYo71wd/8AgATFR3kuZ+grCGl6kYwANHL9CHiGPGmG5t3gACCgF8ZwDf8A AYepBDvImvGTxJHR3HOO+6/dxWxYQ5zS2lIYMoiJ7jxOQ30PXzCzvZWckBGvwRiMkz4cGiv5 jr6ymninWXPHaoOoBHLLOiLJde+ww1QQYhSe8vRsTBsjsgeT1+lE07RZm1jiCIIFl8rb6TPs WdMjylYNjEfQFfE2EtkESxBz/jIuyqE2SCYcNkTMgJS0eoUOYlOoEeHNP4ezle17d/oEAWj7 WZ8496MMB8CR8frvOXbEsvCSDrj9NOEC9oyIliPJmp2nX4kDVHR+iVSPKUiwSELTJgAgoP8A uwTIowqEdaYllxhhf3hcEi/GCMwz1StCZocNXk4jxOJ5UtA84T4RC+Bdo1WfZpu+KbiecVNQ 6CtP2PpHqIgsmtEAi32/YHHES67+APj6FbymJmPdJHLmI/z1SiJy/wA2wmRI2ZEAzP6HEQhZ kXOWWiZOlWzGoXKssrvw1SkKcEJyIylCxj0iAlgjd400HPd0dONkILRjkAhm5IfDs4n67FHR jWBGjoF/YroaLhWHFjBvQbdH/Al9HcMo5zzMfMx8zHzMfMx8zHzMfMx8zHzMfMx8zGS1Jhwv /TPMx8zHzMYpzmWn8njzMfMx8zHzMfMx8zHzMfMx8zHzMfMx8zHzMfMx8zHzMXB4F2AS/LL8 55mPmY+Zj5mPmY+Zj5mPmY+Zj5mPmY+Zj5mPmY+Zj5mPmY+Zj5mPmY+Zj5mPmY+Zj5mPmY+Z j5mPmY+Zj5mPmYyO8LgOpP3Hf+f+7eRd/pOz9p380em0YSJuKxP1pR3LhAalVsxGAgSkNdsJ JrFo5DfBPYBRzb0/n53XyEhjERLjfjDBJZMQMUCdj5/YpF2hp8tqPxDhGmNVST/48kJesZxC l8GS+s40AkyIlG4fr/0nZ+072fdAFkMjHLND3049Nokj3YQaanT2jIQ8rfGI0JlKX7en8/PH ncFilwcmJowscr3K5fP7HIup6TRUGoYRxHlvEJJj7JXJD+JiecrMRGSghLE1+v8A0nZ+0bxa ckSjmPPH59BtLGGKJifT+fnvASzRY9xCfOSza8VeGcAQjO/VIOctk9Mjz6AX3qzEbnx6Bcih rFhj8Z+MzUk/oXRnaYlyUjx/L0C81XPjP+/QJtDHMct8X+PRIPRhPIGma0J+fQYzmks0FPoH Odm7po/u/QabQkorP88fn0f0nZ+2b5H9f39P5+fvUgT3D+nskLf6br6P6/tn9p0/UugPwf4v 0Mn47/giB3z3/Sdn7I+dGLKW/wCL6Pfv2Oe69Og7z+T0e/ftY8kIICfT9+/ftaMTVF/zPo9+ /b3YnKBGfevR79+4ZNN1AOsfg9Hv37WPRbU1jv6Pfv2Xw8xpQJ+ePmvYhkPR9+/YEdpGKzYW aeJKkv0e/fuHDvIirvj/AD6Pfv2ceETMiCPR9+/YwMkCI+yK9Hv37OtxjeLNKQ1HWvR79+1k +L5BfevR79+1xGM3Ae2B6Pfv2cPcaVX7/ZT6Pfv3T1T5HZH7D+wNhTZoyrFFVvOfMMBUogon YkqyZBiPLXlQKBjAgkCGAZtpkOPrsG97J0xW5KJNdMlPKRnc6oek9czKS7IJg84e8Jinyxao tDlWvQOlQSBgPMT0I0kmMD4SFvyjYzxsH9RkHM6k2ONam3eo9F146FcSYJXhuZFYMg69/wDM BpLJeCG3LliYBcWK8or9hXdAtOIeLpGiTCEsez855JTn3xKyEvRkdqCChFNZXAEyk0Vgew3W AipWFx0PZ+i/gra1eMy01czyXyRWBVOqNFHrB5pQIWfExicEN05JkyZQbK36EETQJNO2IeSd PQ8WLEAuhoqycdGNWNHV+1P1D6K8GroTOkvX0BsUAz/qV+lrKXdsAj5Az5Z4PjDFvz/my4lP Weh563gHnQYl9/8Ap2RvRhDMohuWsWRLftDnLdjWD5+Rx8JlxBY/CjCUTTgk7Uog3yOMt9V0 Ngm4z8/snEMmKmwtSwTXnGOZoVVNSrH35v6XmSuqPlEXxZ9ZO9mxVwIuj8McY10PMJ5hgDee 7sIisA2NKtBh/hVuVEwm+a66ZxRninAdLU+TGKbk8iP9PGP5WVoUyrwjEwZosgoYSVvG97Ni 2DE/niisWehYwgMQs7RxGGWIU6M7eCd4T/f4zHZJfE7c2weRP3zktRjfPUy1OQfPCnavfjEE joetySnGQ2n4tK8CrmqQFJ1GZ5jjDviJyB0j/wAHE/NZT54093EfJNukrnJ9T/8AqKnjtGIj SMPBD/KZXXHIKgk5jjzkOMDVE/L+dw/Sk+iN8J5rgYcqdKkGSUFr1gC6jn03qIKngXIhIFan hTzrvKZRzmRLBhAsLK58ZFImM/q3+snpX+1ANNOJz5gtDP7wfusSz6VrtE+598h90519c3+R jFgS6ooqXyYIThf5A+L+y5O4nnTw8v0EGYm3FnUZ3v8A4BxHeHrcgPxG49x6wUgAyISOUWwi 8PyQg7jOUOa/MBpaOPdkgLSpeGuvy5ZmWSA8CzZ4zpLaEqB6EAcRmuqlIUJ4BJZFvm+DIv0y u9FYC5TazRwcRH/Bwi8XuTCROzvvPJcBhKlqLMZ+oEomSQ5qXC2ihljM5qX+MkkyRAQkEkm+ 8RgFMluA35x8rTy9uhz9JMmWlbsPpNqG2DcxMvHokBY13XBa3feTbwG/tUnIqpgSn84C6dYL uYC5NqnOLlk3ESCYQVqjI5LxqlQyn8B9GWmTL2gW0X4wuRQNDqU1jdiDgBomRGHmKKGIAGgO MCSWCQNwFvnHifQ/mpM+cLAcYBEQZSivGSwEgO0zrvLvtw160EWoULyZBTSn7UImsNLCCp9p E+cNzuCFQAaP+i//2gAMAwEAAgADAAAAEJIJJIAIJIIJBJBAJJJIJJJJJJJJJJJJJJJJJJJJ JJJJJJJJJJJJIIBAJAJIBIIJBBIJBBBABJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJBIAJJIJJ IBBIAJJABIJIJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJIIIBAIIJAAJABIABIABIAJIAIAIAIBAAJABJA ABAABAJAIJBJBJJIIJIJBJBIIBAIAIIBBJJABIJJIIIJBABIAAIIIJIJBJBAAJIIJJJJJJJJ JJJJBJJJIJJJJJJJJIBJJJJJJJJJJJJJJJBJBJIJJBJJJJABJIIJJJAJAIJABAJIAAJAIIBB JAIJJIBBAAIIJAIAABBJJJJJAIIBJBJIBBIIAJJABIAABIIBIAAAJJIJAAIAJIJABJBIIBBJ JJJAJJBBJJJJJJJJJJIJJJJJJJJJJJJJJJJJJJJIBJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ JJJJJJJJJJJJJJJJJJJIJJBBJJJJJJJJJJJJJJJBJJJJJJJJJJJJJJJIJJJJJJJJJJJJJJAA AAIJJJJJJJJJJJJJJJIIJJJJJJJJJJJJJJJBJJJJJJJJJJJJJJJJJIAAAAAAAAAAAAAAAAIA AAAAAAAAAAAAAABJJJJJJJJJJJJJJJJJJJJJJJJBJBJJJJJJJIJJJJJJJJJJJJJJJJBJJJJJ JJJJJJJJJJJJJJJAJJIJIJJJJJJJJBJJJJJJJABJJJJJJIJJJJJJJJJJJJJJJJJJJJAAJJBB BJJJJJJJIJJJJJJJIJJJJJJJJBJJJJJJJJJJJJJJJJJJJJJJJIJIJJJJJJBJBJJJJJJJBJJJ IJJJIJJJJJJJJJJJJJJJJJJJIJIJJAJBJBJBJAJIJIJIJIJJJJBJBJBJBJJJJJJJJJJJJJJJ JJIAIAIABABABABAAIAAAIAIAIAJABABABABJJJJJJJJJJJJJJJJIAIJJJIBJBJJJJJJJJII JJJJJJJJJJJJJJABJJJJJJJJJJJJJJJIBBAJJJIJJJIJJJJJJJBJJJJJJJJJJJJJJJIJJJJJ JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ JBIABJBJBJBAJBJAAJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJIAIIJAJIIBBJBAJBBJJJ JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJAJIIBBJBIBIAAAJABJJJJJJJJJJJJJJJJJJJJJJJ JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ//xAAUEQEAAAAAAAAAAAAAAAAA AACw/9oACAEDAQE/EEef/8QAFBEBAAAAAAAAAAAAAAAAAAAAsP/aAAgBAgEBPxBHn//EACsQ AQEAAgIBBAICAgICAwAAAAERACExQVEQYcHwIHFQgTBAYHChsYCR0f/aAAgBAQABPxDZJyoo uinBQoqG8eEEaBEiBwSRaJsCxdgNVLwALcYVemdyNz38GAuo4srHKFQ0ZbvB+LjIBigF45E6 zwzDaEYoqV1gnK8o9QgBw2+CdAYGcqYwTrAFgQViCAvTTp1hIiQIGYLMKts5QSowDKpPaHXf hxhxcrpYumiN67wt+6odAWHnfDznDG0nehNqrRs49WB9fGy3gBcM63sHhJaFVEe5FMpW5Kxi I7TsURfQXrKwKwFX2MV7gwB0pBhwL+/UvkTjR71fPw4wgok9uw4Ok7w1QNTUFF7lw/BVHAHL gTt0bpQKAugIlp+ZLVLSStduGyNIrQArmgTgLgAa4f8AgIsOHMVfKq7m0UmFUTuEE2wIUbXE l5aOOeDPfx74feqAbd9byFRDDWxOIovc0xy1ADm+AB6df0A6hF2Blu6AR7x/4/OxFMvQKCxV ZE6ybr/e0dgijufOhb4bD9GQb2fQuIiHvH7M0ewAdj6kYjJXcAhVvnArB2QWRsNqEpQrNjhP WPljVSMVBJzAugF5239TXtc3QCCRkOOied83JMQZ02R2DDhhscc+HPg5BXTVipGlWvuIzpKn AFIsXFJHMJdOg4ApfOFdJ3OqM1jTVxRR73gAFkFqi7A458OfByCumrFSNP0XnH1XjCVZmpyD gNamxsMRacC50bIF5YqzDVfpVQ5ChPILrAFrWxbLsNJ0Zuri9BPK2C7SMHvHkHhaFRsqAIoS GCfgqg7lQdPYeAF4eyKnGnqORGmlDVlgQ30otIOcY4klKdC4PGsHoY7RlKMQaKEZjnw58HIK 6asVI0q19xGdJU4ApFi4pHDaJAvucgtzb/PbxGqStgNoAPSDihp7ykJAQWdC0CDgCQ75wBEs SjWPAkFyBoXfjXi1prDkiBQBwBnKd29cHQqUjn2RPc1FwNgEAlR7YXNoEfAAD9YvU7JFKKhV Nnjd99qrLLrU1zttimArXwAG98DOJZqmTC3KIGAEDAFjuqAmS/3rTiQLszgFm1/ZiLDqzi/b uBQFI5OBxJGoiZEulogIhg0tWyiKaRFEeRw8zTISIdIHKp0IYyZWLbDRZTVXYElaSYUWSGCd EHYETODIQ4vFt686y9komPnSU23Pdd6OJ8xV1qNnZN49ZrrNz9qKJ7iIoyVpJhRZIYJ0QdgR 4YaohweL7151ikL0z4sDa8vfAF1bMas4HwLNYihddNHD+8s268AEcyYCSAQiAHY0IGw0iwvF ErxS7ILUCO9iF00JdI/st6zLUOnE4taO6G1ElgRDwvlYor0CdvDOp5NtCjrvOIF4ACuxVER6 wK3YpSSikCBjFG8aci6Gk4aaKMlaSYUWSGCdEHYETODIQ4vFt686wLaHMwAC26B/f/zZ0ha+ ivIAAb01uTH5TRzVA8hwNx4yIwkjhf2K7UF4M5akYAgEgEQFEHTlj0EJ1rUPJqliO8cKPFzB bXBQa6JiGZXbpfo6gaeAyNySArzAA6A6O3ebiSXeSoKc9hxuZhloNHgUEo7kQcVezrxwidpC jBsMRFZIBVA2zlXebNL/AHgGWx8lgbwACmYXPlvBVEDMUqH48QlYJKbEOjmgcZ1G00ZNPLT4 TxKGqj2CcNRAgKqsFWFi6kQAQHmjGDOJANiABig4MX46xlFYRzEzS4hr541gWKraUeIF1JKV nBBPUYibbjWoRzsUV4IKkmbO1MQaNKiAc3DDLriayfXoggiEYxE0m21ChNI2XKYkowR5+AIS 83VjDSzzh7TywUAIg0yx2HdHEjNIRRAimLEUsdeqVYAjNMFFJ8IFdj2B+8DuKieGwIgRanY7 wncHlpVu1V+97dx0UIBmgILowIcuMX5MfKA64I1HHzAdt3q7Jp8kwQJk0skSLhG18iMdUcym ECGrJvKoPcx1LSOnQxcJJlWKMI2iCxMg41JEgIHE59q8C6xaqVzm4cCCYAWjCisFAKIBBFCi 4mknOSGNqIAbMH9jcg0gTDijeDAALnzEVxprxhzmv5gGNCJKsE1dYSUKEjrYWeMT2e4WwUFM BVgCuBlLCDPQgrQhCLDebFdhRUQ4JbGxTE1wvnKGjwgQY6c3tj8ftI6djChkEsCyQA5KhHhG imMiL4qwpaNMS95d89ubaRQHt2MOHUddPKKAG1BLrN+XqmZQbdUwBAu4ZYxgGZWgqbCpcFxc 5IompqdG2LTcJdoA2gQUETTHEyBV8A8v/o1wzctgmRqgMgmm8ZTEz2nRJFEJU0EhbIq7ATSN qwwRx/Y3INIEw4o3giswnMEGoeTeRZEYSRwv7FdqC8GctSMAQCQCICiDpxfwylFtYOhteAFd GPFKFQqNgA8KDRca31UschailWBzMS4gwENlAFBEHB7uSSBHewFBEd69HIGghIXbKtd1aDKY me06JIohKmgh311I8kGhlmWCOBXDgFUmliC8u0xHyjqqUiIG7ihkJS4QGmqNQJwAUW6FU4gd ZplVKpYtCpVcJLQu2hdmWmzDledBKd+ZgbgGBKpoAKroxHDrWq4aStMV4UTCU31SmDopmrxv CJxD2E6iDp0aXCdYJTpDvYQ2DUPTlqRgCASARAUQdOCfsEsDbSLtBXWASqfNv1PR0gFTDVR6 SaEFcAUOlcexpb0gUUoBWmUDEZ5rmoZuijGnOWpGAIBIBEBRB04IBGjwmOBR1GpY9gCDbDFM eeOwLtk8CTnWQzgNNRjsqVKUAqZvy9UzKDbqmAIF36TFF2IVAc0+HhzQHkfMm4wJQl0IqOH8 HKIJaRVAYK5GdBjuBJW2Vx7x+270cRCNLsaGIEhxbjiA6sNYBzhtxesNxVkPBybcp20VNNOY Lh7SuLLmMlDS0aWiWXF0KG5RQh2OGrRYCJEeEesuye45GHQ50yzBeBFnTyjZIjRwhRhSmwie igDUcDKQo6GERGNhZvBYsN5H4wqvuw3hja2azgibcoTkcEnpw2sL1sVCNGGINWvNtUooH1g7 7CRDbVuOCaDrDYLPu/AFEuV48mCfj14vtKs4EIVwq/xX7lXsCTcpkqCBSNeZQLGEgwCz34Ai REAqW0YokwdeXtuEJtRYpaTFgex4DAkQwjUQCaYejIS0ATcwuBqrHeBItJAQyh9TGYTzTvhc UehwxRmNmwj5y1oZGj+5C3usGeR5JngqEVAbJiBC6JK3tuIjNmAmUJjAdQkUGgV1i1WhwTE4 uwbDoUyAUl2UCwshqg7Ys0PHOYoAAjKiLtZfGMoVSAzbBXCsExULgNRoAPFzhkYFEwZBpEIL BJynhNc6YM4G3HF14NgZV6zMAKs9SEpW69GKEFAoR9jvNtKWObwM0YvN7G3JQNEuqLEXsTfs n/6E1LlG/slb+uAhA71iknwSAAPAKlgjAsYjIEg0yKKNBwyaTIE/xUA1OwMQNBCuIUyy0FaZ OmACNhvExedWMY3Q5LSyIWWpwxgF5siEymqxeOgjpO0eKu0ReBNuC+LQxNSQoCNhN4MSIS0u ZiMTR5cZIE8QN2iRJUrq74dawPQphWjypm9lh7JGDg1EUCjTOguPJC6kdKJh4EO6HcgquyIl uKIjVdtodY1TAAs9SEpW69GKEFApu5xQLpRqOUFBvNHqRcybhAlCXQio4fwcoglpFUBj6/JR h7AgSu3vnFKFQh1i+ReEDAl4S7J0Q52reWNWWvbkiUVGAoZeDKpScmSIJs0s9K7vDqcJW4dI UFPAh3Q7kFV2REtxqU4xqehBoI6CHPFCgGOF+unsTJcgMs58UTRtgwjW0fdI94HwOcH1c0Ku 5ORXYhUZ/ng00EibiowX/SEwLsIZN0sXhZtT2vaZ/wCRZgknTzlYjSaiiJayCLMCGl6RyMXw Ni6TzmKEAIyoin8CZ7LKQhu7ceg+XGNUhwUilAM2IOMPHCARaeaYFEX0eXNpoV0jqgFmy7sx bkyNA7AF9KaudjPuSCqGMH6k+dVXiJeWsdqKeyjeWwqgMf8A6yeLA3Z5EXdh5vJKQhnoJAcu V7PsmHwC3muRgoHfbJQEUZKujQ4L4tDE1JCgI2E3/rqsNjaroIZRyCATBRV4ookYkT9m8Elt saOEwKwIUH8nE4AAO6Rj78+N4PTVqB7u17Vqqqq/6SsUInavSlEoUc70yLURY0xEAAD/AKr3 1PQkCRTkoeR9OIE/BAocoBXnQHt/gmIjRMWJAjHYUGUPwlmnk4pGYpVc450aGh0LIBYs3fTj ak9xeAd/Qe3ooIsGw8BVUGRa3jhrYcWinOqIHYOj1umVuHFZSysgVVrv8gFvp6FBYVDQKVMe T7Z1TwnVHvJvDSgumNKYkdhbbg2B+w4M2rEpqhFJUoWUimglUgTZUGcTj3JOGAElYFvdt1Qk D0KFCiYczjwzVTVTxN3rGFwrqGkrK6EiuidohCgV0AspBUwiZhLAprqeeCTePBdgKcikYQQy cDhLNMJAKkvQFWYCeHZSPBVR7FqCYLTQ2XfYnZAEK2XWEkhimEVQlJg9ObJovbCqiAsYyfun 9b1pL1x3LQ6Hh4kSiRFEw2nWr4xb2FxMYIMVIT4bLW0auEI3Q3JKwGpiSjRUPDj2VoIjvlgq hnOktwYSArVFOwLM/wCwc1FwUe5RFLFX0MGd2yUyAQNp1q+MW9hcTGCFWI8VteEhRsEibIIA uZisvQ2FTW8PhLvqr3ZRAAizke3BlpRcLBwEGa6tIaTs7oM0grifyvwoa6RmOSwoXqrYxM6E XO0ELiAx0liaAAKXQEJivRlpNLQtdcRJAvVWxiZ0IudoIXDMbkm4BAgi0YIYrC01bl2mJA0J aMCetBRNAytrsGjI4peDBcA4Dlu3Kbccl0USLMyHRcHAWsEvaFCDGgh5caLsSWUWL0C8s2Y4 g8OmDHBd6JwjYuGEVaf3HK1HVBeAgBAAGryq1ufc4ycCkQTfFmVwdhMiI0d4PCTWaIQJNbFk CHRtMTW2GZXLDBGjWTARt+dR8f1oniYmSJ2dLYmkiXrNT+MQe4gdGB66zR0/9NX5pBGqNDHd JAyTXZ91w4EuOJpJamreAHNuhHqpIaQQqQ6JmrY1IVOoaudTwGIuXYwFRAA4BzTwhkUzGkrJ CrjzNDUoCASaXMCBiYc8uKJL2RJDBclqwXM8hMAthUZMFpobLvsTsgCBsRo3UdhShSLFJ0NA CwAnQ6EgpvHlL5a2LUISBoONjS0TcO2QQAowNgaQIqWpUMKWyCgLwjSBBA9PsEijVNEC6Baz fQgZdbf/ABFEzpBVFynlkxkSR8EgBZjdqweVpRMyKEDrEJUlcuKjAMIKqB2GPBnkahABWZVU IYktF0YAEYEUwWZR2JCMaMmNqBmAnsi8orGmllOwErISIApM319LtN0gDLsQSZQhC9eg4qGS xC4uvrDgABcLXhBSvizi3dX0GLu8TKWY9HI0CNJAJRjWM/QS2y1AbEFRiMxiK3Lry3PpvBHG +YjByAF0AlYMwx23OOeIykJcHH0mYNAzAVFSzKHLBgB6MMaCNZG+PVZy5CG2IFxaQAzGT7gK Ox1/iQWTMWVxP4RdHwi7Tp2IpHXXxd7lLRNdgbh0zYd08zFjCHcrtvBU/J7XR97WXyZr5BDM DXMeor0K2M+r0yKnELMJqt3azHLvHgvWKbRPUEqRb2ApKEYQ5CSUkqhyIGQ7Eb7krC8DYoYO 8uEyGKwhYAGZeFrrH4wqmALkkpFORUioTQnyoe9Y6vAkCNaMCkgSJqflTIAdORAVLBuqX5ih FwipMRkMOOs2AgRfkm8BertehrujTV2tZDlU95QAxYl2WhI8L0EldNr2sjzgj5G2PPgpAZzj 2znlFQOhBDycUcxKxFC1j2jI2BvDPBHccpYLGI04CpYtlgQQfBuIcqnvKAGLEuy0CK7NFooG bCPY5KnLhk/KxyAGHdAPpEMYTTd0oTTj4u6E+GixYJtKt8zUhr6N2QEERhvFhoPRE+CjqmBb I+DVgYXSGMC0FbYnIeHYlMLslPkyKXwSqah2g1S2R8GrAwukMYFoBAXmAqOb9nlAYtgkuKgH ihD0QiwHyAvXhQ2NnM4xW2AiYpDQQKNS7nmcg7ErCmK0InicqiGJo6CZDfADI3acZQCUtBFC zPsgKrvADquoq0O1tMitghpqRm7gWTXZISPN9sQQAioRM7iGe2CG/WNFYnNfJo5xpwzmHAht qx7XQOQrgcI6Oo6GkEBotyR2kCO2wNmO9QbdLKK0LzNhg0wbxMQJcKg3qbxQ7DqPESyxyreS bB7A1YpHs0kcOOn+JhaMVW0bMjEf/wAGkBagDSbU2/qARhazbbEMmgOCgAglJjZVxidsDAzy g6aMbxq/SSUp7YT0lqYrGyjgUutIlOU1hU7Rm6BspSpF6CurwJAjWjApIEiXCrNcCdM1aUMr hHoQAD0QsFL0rvLhMhisIWABmTkhjs1jUQbQEcEoPUmLWqbGBdobyDAhfHcAQ8jkoP8AIg7G N5JDYSBt0ZBkEnxNUOwBXDf2qtKDiVCkOG4sXBAT22aEtBhDECf0ohWw/Yc4YJCo5jNHSKKr WR5DFoo2aW6gwbxAL0CeK6AFSeLlCU1/JHI8kx2TAXLC2ymz+5b+m8seDpoCAwQUbDmwAgQt hR2zKc8LcOJKAymLwWYIPFEUnoISqTULgY4QRE8RFwUblRfpPZS2A3RDohc3RgMZ4fRWNEwN tthIUdANBpNpUHtabgQEXApjMFxPi+0mK8KIK05s51L4LYFNjQQc6AHcMY1URV0BBKL4aqXl KQoInD/FwLzTQArFBlmjCDTZ8PLU91V/E8XA6KEhQZsBI79CM2YZBuhCCCnP+sNYe8E2JCjE 0uKNlhBDcgAVYAfk73ohxUEKsVCvnLpGampqGqFVFSqq/wCAm8DPxWqp28K63owHGCKA3Q17 gf8AOk4JRAZdUheYeT/Hdfj5CLAMEQRKJi2xG3EViSUgOw0f4QoAK2mlEA3B2OGAAQAgH/di ZxoBtm1oVOiJZrP8sDBE2PIdOXwAuaUbDQjhNRzeDSzpEEoKBUGIF95zLfnCKiJiJ3TG5FNv KDSVmOdickJNy2Bz16I8H+ljqsp1QVQ/gBTq6CaanAL2236HP57QLXQN1Gj2/wB8wyYiiaSi f7ptEYeUJR85UUYkastxjaBqoLSgVt+msASIgwoHlQqmHAgUBdYWtJsE2XkJena8ZEy0ClrQ 9JrErsOhMGLsNiaNX1AtPfWbwCog8AvB/BZ4oXEPGjd39Aqz/fPvPH8JFpCOelOP9Z98+c++ fOffPnPvnzn3z5z758598+c++fOffPnPvnzn3z5z7584goKsCV/4GffPnPvnzn3z5xgFhQzr /af1n3z5z758598+c++fOffPnPvnzn3z5z758598+c++fOffPnPvnzn3z5z758598+c++fOC 0uyKy3wQ60NGffPnPvnzn3z5z758598+c++fOffPnPvnzn3z5z758598+c++fOffPnPvnzn3 z5z758598+c++fOffPnPvnzn3z5z758598+c++fOffPnPvnzn3z5z758598+c++fOffPnPvn ziuyniwKSnPJ/wBIVvj7OwrOkERTox0QEJqUS4FSn5Stk2i0ACpaR99ZEKqhDGICK+0BquKQ hfMbPx+Mo/AJYg2NSdt5HddRE0qdYCwfwT7OhdRoSUTkZjpHjJxkEYX2WXaTHmNvnqwR0Xoz Zrij8bskkFDQ/wAwwrP76xSgBoFQdYK2HmEL5Hk7CbJiLtNw0NDjpVkpiw8Qu8oQX8vjvjsV eFA3JKH/AAMg+R0mgdfwb7O/dbciaAOj1NiuW04TvdJB0dDbTTkm1+QTrC0Cwn8uwrLYCDdK 5Hgo13uo+tbgtZWUMslj+XxOTcxx2LfNoORiKXQxkGsFBKfdH8nz1CDSBHVvS26rTdepyko2 pji3azvz+DJ3OwNijLpZgBoipuhF75/wZx2jzYQAjWzdb4T8BsOhkoaTd05J+G+gnum1HkI7 01b+Gr7RmUmIVgRwWaWFn4XhBNrM6JdJvjn8J3FfCOBuqbf01+B0ABJ05OQ51xbqP8qwrIif wAJjVrZGlKxnb/CEHwBB1oZ2qH5914/lRrRsBYb9l5zQCk8nnj8AoUKNPeOkJKtaMIbUB9Qo UKsHc8AISFdwf1+IUKFCvDlZsyKHgdc38AoUKtOqMqigG4i6T9HqFChRy7dd0GiKVRFgaz1C hQs+M/yZwrBo0Xs/AKFCk07BLUhoUWDjEYVyCM8afgFChUhRi0EXVWRsVBeoUKFWnc7S0NAd cXjhq+oUKFGnIH0L6OxtT+/wChQr6asMootpjW1Khs9QoUKbaoF8WXdxtq1oWlFBnR+AUKFO D17jRQlPRTjf4BQoWc3XnYE04Jto6/AKFCjl/wA4UCK0IwhWgPqFChQBUKgUXSZOx7fwHiWl 1UzKRooNXJtpAAERaApUAAK4u7SxTnHzbKKbygoLYTjIIdmdz1AmkDB8U9X2zGrosypshKge JRfzwAEv1+/cSHumBm6k2DhAIgTRU+sJfJ04xs8RVfwVabqoSm9mtUFwMqAqB1S/5Oek4pGV s6JDQSfXOIWArBLeVEnjFzVjRZyP3/uWDsWRxuEdB79G81g4SzAxXuEOheX7zx/AewU/Ozd/ oIXE1kMWI0WRYYPdSEjltSTWuK74lgp72YaSk5LAbA4hZensQ7SG+PR6RkS9MDkCTAtxXTIC S1RVQiaUQfzvZki1INxsnVxpDuKqE1ot9Av4SPtiTe3QlohD/CAYAZQQIQKLTJecP10CQPGv H+RnzyI/ASu05S3XoDMpJVqnalORY7PQbTXE4kGji726YsRfSJJHqhf7/wB2DnD50KkbqDsM JyEMqaFaP7/6dKwl6lKRLw0yb5MOWIGwqxcbqBNme5rVChAadh1lvpkFCc0oIN0+MG4wnAqR gArBkc4MK78Yp9gs7ypptX7GxB1sxEdBZSgdqQO1MFLcEmAQmsWQDAIxLL7bcOTmHDQu56DL R8LoyPJws943s8MzcFAtRyMSroUe9Ma9a84nQDsAVVeAMd0ywqQAQEJNWG6EB0paQZzaUdXD 2ZFrXRA2bcHftPEEAbNIcTAn+H3FGCiE4Cucu1pzhOjTaFINSwspgdGz1htIEc047uwVlyNp orjws6AKBG30tRKY+T0bMKiIwHrrDLqADNkHYSy0mGRArzwzr72/bKMIDTexCboSZsQ22bzQ P/pjpAgq/wDRAARRRUOg9k1QNIiIn/B6sGpFotPK9nvZRfi8PkNufoMS2dgMA5/T/wCgLl+i AefP9D+8UV1e8y6EB2oChTI+7iqkIw3yFQ7CVOTjrAQuOPGgsRVvBoghBQCqGnjI+ylIGlkA Hdc5uN/aipFVTpbgMLENyioAVVV5VrhocFYGhJwmls16CoBR0oXZFTe5WFUoI0RL3W1jiCNW z2+WLN36YRRtkkSVwQ9vJMDlYXiNbqjsFF4zZUdoqq5ohm03eVMYnWr7QCppamk9FDTEDk78 bKm6MivNqFKmCDAjccIHUDVqmgV2ySdXj9uxFE983JClI4bgzwMb6TBWmdI1U2o2Kgzu8KkZ dA6NjgzoadEFOG024Tii04kxVNbaNhBAFcPN6H4rAIxU0i4C1DsAVygUBYC9Y9oQwSe7R4ya k/4PqLKcqEIalMry4HhhVSIyapodHjBfs6dpdBW0BNUVpNsD1oG3BsDZS4mu5WwWrqQiNNya wS5whBULFYZf4pstUBRpqNbu4lI8ZEyIQ0ITMUFLF3z6JGVz3y0gAaL3+AcUjDKHBo9p28uL cI7/AMqk91x/cHCNyNjquxpBLCAwIAqAg7OQwcLkMDEtwu40GjBEKB71L4YVP1HoGSg8QDAo Ctsb1gIie+8E/pxiTDrhBVEkEJCHjADKzXCwAAAAADAnPRZIivCqrOcYyB2VbOCrar25q3AT KBE0JQjwY7VWMMhg4Bu9KcuWgy4mpSqwRK4E5xdFaAVs3rqZK3tB3yZOpBduGP1MIB4AAACA B/0X/9k= --------------020109060002000407060902-- From paitken@cisco.com Tue Sep 3 06:26:27 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5CE21F84DB for ; Tue, 3 Sep 2013 06:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HCmIfXJS9kp for ; Tue, 3 Sep 2013 06:26:10 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E395821E814C for ; Tue, 3 Sep 2013 06:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=606; q=dns/txt; s=iport; t=1378214770; x=1379424370; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/8JMUtQCBLeMKH9SjPvFO+ekm9TaWQxJnQiTP0aINIE=; b=ZMa7RFxRRH/gkE1ASyH9qfHRHmfvwKSgdebHOouEt6B3Adpyf8Lej9a8 nmu9+nSBWvaKkLTNiQrS5fcT+0kH/wISIkN5lrP31v6+3NrFOpg8Vs7s7 vXA8A7KHQIybMstoqsMhqTY5fk/L8h/QomrYfzo/fU7I7Tw3jQHewIp0k 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAAHjJVKQ/khR/2dsb2JhbABaDoJ5NYMxvhSBKRZ0giQBAQEDAR0bQAEFCwsOExYPCQMCAQIBRQYNAQcBAQWHcwYMuGmOPYE5B4QdA5d1hiyLOoJhQIFw X-IronPort-AV: E=Sophos;i="4.89,1014,1367971200"; d="scan'208";a="17239983" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 03 Sep 2013 13:26:02 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r83DQ07r025596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Sep 2013 13:26:00 GMT Received: from [144.254.153.55] (dhcp-144-254-153-55.cisco.com [144.254.153.55]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r83DPx0M007995; Tue, 3 Sep 2013 14:26:00 +0100 (BST) Message-ID: <5225E367.7010307@cisco.com> Date: Tue, 03 Sep 2013 14:25:59 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nevil Brownlee References: <5202C647.5030204@auckland.ac.nz> <521C1DC8.2070102@auckland.ac.nz> In-Reply-To: <521C1DC8.2070102@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] WG Last call for draft-ietf-ipfix-mediation-protocol-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 13:26:28 -0000 Nevil, > This WGLC has finished, with no comments at all on the list. > I need at least a few "looks OK to me" or "I can live with that" > responses before I can put together its Shepherd writeup! I thoroughly reviewed -05: http://www.ietf.org/mail-archive/web/ipfix/current/msg06921.html and previously reported that the -05 to -06 changes are good: http://www.ietf.org/mail-archive/web/ipfix/current/msg06966.html I've re-checked the -05 to -06 changes, and they are still good. The -06 document looks good to me; for once I have no further review comments! :-o P. From andrewf@plixer.com Wed Sep 4 14:50:24 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0497021F8749 for ; Wed, 4 Sep 2013 14:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoorQts4m5eZ for ; Wed, 4 Sep 2013 14:50:19 -0700 (PDT) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id CEF7921F91BF for ; Wed, 4 Sep 2013 14:50:09 -0700 (PDT) Received: from [10.12.1.82] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Sep 2013 17:50:07 -0400 Message-ID: <5227AB0E.2010400@plixer.com> Date: Wed, 4 Sep 2013 17:50:06 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: , Paul Aitken References: <5224DCCC.9020607@cisco.com> <07F7D7DED63154409F13298786A2ADC904E971CA@EXRAD5.ad.rad.co.il> <5225B288.8050006@cisco.com> In-Reply-To: <5225B288.8050006@cisco.com> Content-Type: multipart/alternative; boundary="------------080009000500030203050307" Subject: Re: [IPFIX] IPFIX: boolean, dot1qDEI and dot1qCustomerDEI X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 21:50:24 -0000 --------------080009000500030203050307 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi Paul, all, I think some clarification is needed, but I'm not sure what the right answer is. I see at least three valid readings of the combination of boolean, flags, and "The value of the 1-bit Drop Eligible Indicator (DEI) field" 1) send "the value": if DEI bit set (0x01) / unset (0x00) (looks a lot like least significant bit set/unset ;-) This is what the initial correction seems to assume. 2) semantics "flags": if DEI bit set (0x10) / unset (0x00). This is the interpretation that including pcp would require 3) strict data type "boolean": if DEI bit set (0x01) / unset (0x02). This is a variation on option 1 where boolean was interpreted strictly. 1 and 2 can be viewed as the same except for which bit gets flipped. On 09/03/2013 05:57 AM, Paul Aitken wrote: > Yaakov, > >> Fine with me since it simplifies the interpretation (DEI=0 means >> green and DEI=1 means yellow). >> >> By first bitdo you mean least significant bit? >> > > Yes. If needs be we could add a figure something like so: > > 0 1 2 3 4 5 6 7 > +-----+-----+-----+-----+-----+-----+-----+-----+ > | Reserved | DEI | > +-----+-----+-----+-----+-----+-----+-----+-----+ This is option 1 and is compatible with 3 as long as reserved bit 6 is never used. Option 2 only ever sets bit 7 to 0, but does change bit 3 in the reserved area. > > > Although if we were defining this again, it might be more useful to > retain the DEI position, and potentially include the PCP bits. > > So, per 802.1Q-2011 Figure 9-1 (attached) : > > 0 1 2 3 4 5 6 7 > +-----+-----+-----+-----+-----+-----+-----+-----+ > | PCP | DEI | Reserved | > +-----+-----+-----+-----+-----+-----+-----+-----+ > > However I suspect that this is incompatible with current > implementations, so the change is not possible? This is a total change as this is no longer just dot1qDEI. I'm slightly in favor of option 1, but ultimately I simply don't want to receive an identical value from different exporters which I am expected to interpret differently. -Andrew > > P. > > >> *From:*Paul Aitken [mailto:paitken@cisco.com] >> *Sent:* 02 September, 2013 21:46 >> *To:* IETF IPFIX Working Group; ie-doctors@ietf.org >> *Cc:* Yaakov Stein >> *Subject:* IPFIX: boolean, dot1qDEI and dot1qCustomerDEI >> >> Dear IPFIX experts, >> >> While reviewing IANA's IPFIX registry, I noticed that although IEs >> #388 dot1qDEI and #389 dot1qCustomerDEI are defined as "boolean" >> their definitions do not correspond to that type. >> >> As a reminder, RFC5101bis says: >> >> 6.1.5. boolean >> >> The boolean data type is specified according to the TruthValue in >> [RFC2579]. It is encoded as a single-octet integer per >> Section 6.1.1,with the value 1 for true and value 2 for false. >> Every other value is undefined. >> >> >> (for consistency with MIB truthValue). >> >> So a boolean IE cannot capture a bit field such as the DEI required >> by #388 and #389. I checked the other boolean IEs, and they're fine. >> >> To correct this, I propose that #388 and #389 be changed from >> "boolean" to "unsigned8", in line with all the other flags fields: >> >> 388 >> >> >> >> dot1qDEI >> >> >> >> boolean >> unsigned8 >> >> >> >> flags >> >> >> >> current >> >> >> >> >> The first bit of this octet is the value of the 1-bit Drop Eligible >> Indicator (DEI) field of the VLAN tag as described in 802.1Q-2011 >> subclause 9.6. In case of a QinQ frame, it represents the outer tag's >> DEI field and in case of an IEEE 802.1ad frame it represents the DEI >> field of the S-TAG. Note: in earlier versions of 802.1Q the same bit >> field in the incoming packet is occupied by the Canonical Format >> Indicator (CFI) field, except for S-TAGs. >> The remainder of this octet is reserved for future use. >> >> 389 >> >> >> >> dot1qCustomerDEI >> >> >> >> boolean >> unsigned8 >> >> >> >> flags >> >> >> >> current >> >> >> >> >> In case of a QinQ frame, the first bit of this octet it represents >> the inner tag's Drop Eligible Indicator (DEI) field and in case of an >> IEEE 802.1ad frame it represents the DEI field of the C-TAG. >> The remainder of this octet is reserved for future use. >> >> >> >> Feedback? >> >> P. >> > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------080009000500030203050307 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Hi Paul, all,

I think some clarification is needed, but I'm not sure what the right answer is.

I see at least three valid readings of the combination of boolean, flags, and "The value of the 1-bit Drop Eligible Indicator (DEI) field"

1) send "the value": if DEI bit set (0x01) / unset (0x00) (looks a lot like least significant bit set/unset ;-)
This is what the initial correction seems to assume. 


2) semantics "flags": if DEI bit set (0x10) / unset (0x00).
This is the interpretation that including pcp would require


3) strict data type "boolean": if DEI bit set (0x01) / unset (0x02).
This is a variation on option 1 where boolean was interpreted strictly.

1 and 2 can be viewed as the same except for which bit gets flipped.


On 09/03/2013 05:57 AM, Paul Aitken wrote:
Yaakov,

Fine with me since it simplifies the interpretation (DEI=0 means green and DEI=1 means yellow).

 

By first bit do you mean least significant bit ?


Yes. If needs be we could add a figure something like so:

	   0     1     2     3     4     5     6     7
	+-----+-----+-----+-----+-----+-----+-----+-----+
	|                Reserved                 | DEI |
	+-----+-----+-----+-----+-----+-----+-----+-----+

This is option 1 and is compatible with 3 as long as reserved bit 6 is never used.  Option 2 only ever sets bit 7 to 0, but does change bit 3 in the reserved area.
Although if we were defining this again, it might be more useful to retain the DEI position, and potentially include the PCP bits.

So, per 802.1Q-2011 Figure 9-1 (attached) :

	   0     1     2     3     4     5     6     7
	+-----+-----+-----+-----+-----+-----+-----+-----+
	|       PCP       | DEI |        Reserved       |
	+-----+-----+-----+-----+-----+-----+-----+-----+

However I suspect that this is incompatible with current implementations, so the change is not possible?

This is a total change as this is no longer just dot1qDEI.

I'm slightly in favor of option 1, but ultimately I simply don't want to receive an identical value from different exporters which I am expected to interpret differently.


-Andrew



P.


From: Paul Aitken [mailto:paitken@cisco.com]
Sent: 02 September, 2013 21:46
To: IETF IPFIX Working Group; ie-doctors@ietf.org
Cc: Yaakov Stein
Subject: IPFIX: boolean, dot1qDEI and dot1qCustomerDEI

 

Dear IPFIX experts,

While reviewing IANA's IPFIX registry, I noticed that although IEs #388 dot1qDEI and #389 dot1qCustomerDEI are defined as "boolean" their definitions do not correspond to that type.

As a reminder, RFC5101bis says:

6.1.5.  boolean
 
   The boolean data type is specified according to the TruthValue in
   [RFC2579].  It is encoded as a single-octet integer per
   Section 6.1.1, with the value 1 for true and value 2 for false.
   Every other value is undefined.


(for consistency with MIB truthValue).

So a boolean IE cannot capture a bit field such as the DEI required by #388 and #389. I checked the other boolean IEs, and they're fine.

To correct this, I propose that #388 and #389 be changed from "boolean" to "unsigned8", in line with all the other flags fields:

388

dot1qDEI

boolean
unsigned8

flags

current


The first bit of this octet is the value of the 1-bit Drop Eligible Indicator (DEI) field of the VLAN tag as described in 802.1Q-2011 subclause 9.6. In case of a QinQ frame, it represents the outer tag's DEI field and in case of an IEEE 802.1ad frame it represents the DEI field of the S-TAG. Note: in earlier versions of 802.1Q the same bit field in the incoming packet is occupied by the Canonical Format Indicator (CFI) field, except for S-TAGs.
The remainder of this octet is reserved for future use.

389

dot1qCustomerDEI

boolean
unsigned8

flags

current


In case of a QinQ frame, the first bit of this octet it represents the inner tag's Drop Eligible Indicator (DEI) field and in case of an IEEE 802.1ad frame it represents the DEI field of the C-TAG.
The remainder of this octet is reserved for future use.



Feedback?

P.




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

--------------080009000500030203050307-- From paitken@cisco.com Wed Sep 4 15:27:11 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B689521E8092 for ; Wed, 4 Sep 2013 15:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2JScMlbS4wW for ; Wed, 4 Sep 2013 15:27:06 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id A3E3021E80AC for ; Wed, 4 Sep 2013 15:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20577; q=dns/txt; s=iport; t=1378333624; x=1379543224; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=UnseXJnxHr5uNJQk3yCqaUTAr+xTEw5AHBaDpY/cGIc=; b=X/4RqcZqXzqe8Lw2SMlO+5mVzySOE9mtoFVfmBuIPREwOV1fpD/KEi2Z 1891rAuizKHM982FUEP0bV5i0hqUxM8aOh3bzamVuSfQ0QlFcybRzdmg0 WfXfGMk1g39B4zij41LmejCa47Vc3lgqDxav1yeU9MnYt6CP6kSdLQChW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAFAJ6yJ1KQ/khL/2dsb2JhbABbgkNENYlWuD+BKRZ0giQBAQEEAQEBKj4DCgEQCxEEAQEBCRYIBwkDAgECARUfCQgGDQEFAgEBh34MuiMEgluNBQYBhB0Dl3WGLIs6gyE X-IronPort-AV: E=Sophos;i="4.90,843,1371081600"; d="scan'208,217";a="17756334" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 04 Sep 2013 22:27:03 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r84MR153016734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Sep 2013 22:27:01 GMT Received: from [10.61.220.173] ([10.61.220.173]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r84MQxun025354; Wed, 4 Sep 2013 23:27:00 +0100 (BST) Message-ID: <5227B3B3.4040005@cisco.com> Date: Wed, 04 Sep 2013 23:26:59 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Feren References: <5224DCCC.9020607@cisco.com> <07F7D7DED63154409F13298786A2ADC904E971CA@EXRAD5.ad.rad.co.il> <5225B288.8050006@cisco.com> <5227AB0E.2010400@plixer.com> In-Reply-To: <5227AB0E.2010400@plixer.com> Content-Type: multipart/alternative; boundary="------------060400030909050207010204" Cc: Yaakov Stein , ipfix@ietf.org Subject: Re: [IPFIX] IPFIX: boolean, dot1qDEI and dot1qCustomerDEI X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 22:27:11 -0000 This is a multi-part message in MIME format. --------------060400030909050207010204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andrew, I think it depends a lot on what was already implemented - or perhaps, on what we suspect may already have been implemented, given that we can't possibly expect to know them all. In practice, I suspect that only Yaakov Stein has implemented these fields so far... so I'd be happy to be guided by whatever he did. From his earlier reply, I suspect that may be option 1 : LSB = 0 or 1. P. On 04/09/13 22:50, Andrew Feren wrote: > Hi Paul, all, > > I think some clarification is needed, but I'm not sure what the right > answer is. > > I see at least three valid readings of the combination of boolean, > flags, and "The value of the 1-bit Drop Eligible Indicator (DEI) field" > > 1) send "the value": if DEI bit set (0x01) / unset (0x00) (looks a lot > like least significant bit set/unset ;-) > This is what the initial correction seems to assume. > > > 2) semantics "flags": if DEI bit set (0x10) / unset (0x00). > This is the interpretation that including pcp would require > > > 3) strict data type "boolean": if DEI bit set (0x01) / unset (0x02). > This is a variation on option 1 where boolean was interpreted strictly. > > 1 and 2 can be viewed as the same except for which bit gets flipped. > > > On 09/03/2013 05:57 AM, Paul Aitken wrote: >> Yaakov, >> >>> Fine with me since it simplifies the interpretation (DEI=0 means >>> green and DEI=1 means yellow). >>> >>> By first bitdo you mean least significant bit? >>> >> >> Yes. If needs be we could add a figure something like so: >> >> 0 1 2 3 4 5 6 7 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> | Reserved | DEI | >> +-----+-----+-----+-----+-----+-----+-----+-----+ > > This is option 1 and is compatible with 3 as long as reserved bit 6 is > never used. Option 2 only ever sets bit 7 to 0, but does change bit 3 > in the reserved area. > >> >> Although if we were defining this again, it might be more useful to >> retain the DEI position, and potentially include the PCP bits. >> >> So, per 802.1Q-2011 Figure 9-1 (attached) : >> >> 0 1 2 3 4 5 6 7 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> | PCP | DEI | Reserved | >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> >> However I suspect that this is incompatible with current >> implementations, so the change is not possible? > > This is a total change as this is no longer just dot1qDEI. > > I'm slightly in favor of option 1, but ultimately I simply don't want > to receive an identical value from different exporters which I am > expected to interpret differently. > > > -Andrew > > >> >> P. >> >> >>> *From:*Paul Aitken [mailto:paitken@cisco.com] >>> *Sent:* 02 September, 2013 21:46 >>> *To:* IETF IPFIX Working Group; ie-doctors@ietf.org >>> *Cc:* Yaakov Stein >>> *Subject:* IPFIX: boolean, dot1qDEI and dot1qCustomerDEI >>> >>> Dear IPFIX experts, >>> >>> While reviewing IANA's IPFIX registry, I noticed that although IEs >>> #388 dot1qDEI and #389 dot1qCustomerDEI are defined as "boolean" >>> their definitions do not correspond to that type. >>> >>> As a reminder, RFC5101bis says: >>> >>> 6.1.5. boolean >>> >>> The boolean data type is specified according to the TruthValue in >>> [RFC2579]. It is encoded as a single-octet integer per >>> Section 6.1.1,with the value 1 for true and value 2 for false. >>> Every other value is undefined. >>> >>> >>> (for consistency with MIB truthValue). >>> >>> So a boolean IE cannot capture a bit field such as the DEI required >>> by #388 and #389. I checked the other boolean IEs, and they're fine. >>> >>> To correct this, I propose that #388 and #389 be changed from >>> "boolean" to "unsigned8", in line with all the other flags fields: >>> >>> 388 >>> >>> >>> >>> dot1qDEI >>> >>> >>> >>> boolean >>> unsigned8 >>> >>> >>> >>> flags >>> >>> >>> >>> current >>> >>> >>> >>> >>> The first bit of this octet is the value of the 1-bit Drop Eligible >>> Indicator (DEI) field of the VLAN tag as described in 802.1Q-2011 >>> subclause 9.6. In case of a QinQ frame, it represents the outer >>> tag's DEI field and in case of an IEEE 802.1ad frame it represents >>> the DEI field of the S-TAG. Note: in earlier versions of 802.1Q the >>> same bit field in the incoming packet is occupied by the Canonical >>> Format Indicator (CFI) field, except for S-TAGs. >>> The remainder of this octet is reserved for future use. >>> >>> 389 >>> >>> >>> >>> dot1qCustomerDEI >>> >>> >>> >>> boolean >>> unsigned8 >>> >>> >>> >>> flags >>> >>> >>> >>> current >>> >>> >>> >>> >>> In case of a QinQ frame, the first bit of this octet it represents >>> the inner tag's Drop Eligible Indicator (DEI) field and in case of >>> an IEEE 802.1ad frame it represents the DEI field of the C-TAG. >>> The remainder of this octet is reserved for future use. >>> >>> >>> >>> Feedback? >>> >>> P. >>> >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > --------------060400030909050207010204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Andrew,

I think it depends a lot on what was already implemented - or perhaps, on what we suspect may already have been implemented, given that we can't possibly expect to know them all.

In practice, I suspect that only Yaakov Stein has implemented these fields so far... so I'd be happy to be guided by whatever he did.

From his earlier reply, I suspect that may be option 1 : LSB = 0 or 1.

P.


On 04/09/13 22:50, Andrew Feren wrote:
Hi Paul, all,

I think some clarification is needed, but I'm not sure what the right answer is.

I see at least three valid readings of the combination of boolean, flags, and "The value of the 1-bit Drop Eligible Indicator (DEI) field"

1) send "the value": if DEI bit set (0x01) / unset (0x00) (looks a lot like least significant bit set/unset ;-)
This is what the initial correction seems to assume. 


2) semantics "flags": if DEI bit set (0x10) / unset (0x00).
This is the interpretation that including pcp would require


3) strict data type "boolean": if DEI bit set (0x01) / unset (0x02).
This is a variation on option 1 where boolean was interpreted strictly.

1 and 2 can be viewed as the same except for which bit gets flipped.


On 09/03/2013 05:57 AM, Paul Aitken wrote:
Yaakov,

Fine with me since it simplifies the interpretation (DEI=0 means green and DEI=1 means yellow).

 

By first bit do you mean least significant bit ?


Yes. If needs be we could add a figure something like so:

	   0     1     2     3     4     5     6     7
	+-----+-----+-----+-----+-----+-----+-----+-----+
	|                Reserved                 | DEI |
	+-----+-----+-----+-----+-----+-----+-----+-----+

This is option 1 and is compatible with 3 as long as reserved bit 6 is never used.  Option 2 only ever sets bit 7 to 0, but does change bit 3 in the reserved area.
Although if we were defining this again, it might be more useful to retain the DEI position, and potentially include the PCP bits.

So, per 802.1Q-2011 Figure 9-1 (attached) :

	   0     1     2     3     4     5     6     7
	+-----+-----+-----+-----+-----+-----+-----+-----+
	|       PCP       | DEI |        Reserved       |
	+-----+-----+-----+-----+-----+-----+-----+-----+

However I suspect that this is incompatible with current implementations, so the change is not possible?

This is a total change as this is no longer just dot1qDEI.

I'm slightly in favor of option 1, but ultimately I simply don't want to receive an identical value from different exporters which I am expected to interpret differently.


-Andrew



P.


From: Paul Aitken [mailto:paitken@cisco.com]
Sent: 02 September, 2013 21:46
To: IETF IPFIX Working Group; ie-doctors@ietf.org
Cc: Yaakov Stein
Subject: IPFIX: boolean, dot1qDEI and dot1qCustomerDEI

 

Dear IPFIX experts,

While reviewing IANA's IPFIX registry, I noticed that although IEs #388 dot1qDEI and #389 dot1qCustomerDEI are defined as "boolean" their definitions do not correspond to that type.

As a reminder, RFC5101bis says:

6.1.5.  boolean
 
   The boolean data type is specified according to the TruthValue in
   [RFC2579].  It is encoded as a single-octet integer per
   Section 6.1.1, with the value 1 for true and value 2 for false.
   Every other value is undefined.


(for consistency with MIB truthValue).

So a boolean IE cannot capture a bit field such as the DEI required by #388 and #389. I checked the other boolean IEs, and they're fine.

To correct this, I propose that #388 and #389 be changed from "boolean" to "unsigned8", in line with all the other flags fields:

388

dot1qDEI

boolean
unsigned8

flags

current


The first bit of this octet is the value of the 1-bit Drop Eligible Indicator (DEI) field of the VLAN tag as described in 802.1Q-2011 subclause 9.6. In case of a QinQ frame, it represents the outer tag's DEI field and in case of an IEEE 802.1ad frame it represents the DEI field of the S-TAG. Note: in earlier versions of 802.1Q the same bit field in the incoming packet is occupied by the Canonical Format Indicator (CFI) field, except for S-TAGs.
The remainder of this octet is reserved for future use.

389

dot1qCustomerDEI

boolean
unsigned8

flags

current


In case of a QinQ frame, the first bit of this octet it represents the inner tag's Drop Eligible Indicator (DEI) field and in case of an IEEE 802.1ad frame it represents the DEI field of the C-TAG.
The remainder of this octet is reserved for future use.



Feedback?

P.




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


--------------060400030909050207010204-- From andrewf@plixer.com Thu Sep 5 05:43:09 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDB221F93BA for ; Thu, 5 Sep 2013 05:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3vCsMaCsNFz for ; Thu, 5 Sep 2013 05:43:04 -0700 (PDT) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3BD21F9BD3 for ; Thu, 5 Sep 2013 05:43:01 -0700 (PDT) Received: from [10.12.1.82] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Sep 2013 08:43:00 -0400 Message-ID: <52287C55.3060902@plixer.com> Date: Thu, 5 Sep 2013 08:43:01 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Aitken References: <5224DCCC.9020607@cisco.com> <07F7D7DED63154409F13298786A2ADC904E971CA@EXRAD5.ad.rad.co.il> <5225B288.8050006@cisco.com> <5227AB0E.2010400@plixer.com> <5227B3B3.4040005@cisco.com> In-Reply-To: <5227B3B3.4040005@cisco.com> Content-Type: multipart/alternative; boundary="------------000203030302020203020506" Cc: Yaakov Stein , ipfix@ietf.org Subject: Re: [IPFIX] IPFIX: boolean, dot1qDEI and dot1qCustomerDEI X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 12:43:09 -0000 --------------000203030302020203020506 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 09/04/2013 06:26 PM, Paul Aitken wrote: > Andrew, > > I think it depends a lot on what was already implemented - or perhaps, > on what we suspect may already have been implemented, given that we > can't possibly expect to know them all. > > In practice, I suspect that only Yaakov Stein has implemented these > fields so far... so I'd be happy to be guided by whatever he did. > > From his earlier reply, I suspect that may be option 1 : LSB = 0 or 1. Works for me. -Andrew > > P. > > > On 04/09/13 22:50, Andrew Feren wrote: >> Hi Paul, all, >> >> I think some clarification is needed, but I'm not sure what the right >> answer is. >> >> I see at least three valid readings of the combination of boolean, >> flags, and "The value of the 1-bit Drop Eligible Indicator (DEI) field" >> >> 1) send "the value": if DEI bit set (0x01) / unset (0x00) (looks a >> lot like least significant bit set/unset ;-) >> This is what the initial correction seems to assume. >> >> >> 2) semantics "flags": if DEI bit set (0x10) / unset (0x00). >> This is the interpretation that including pcp would require >> >> >> 3) strict data type "boolean": if DEI bit set (0x01) / unset (0x02). >> This is a variation on option 1 where boolean was interpreted strictly. >> >> 1 and 2 can be viewed as the same except for which bit gets flipped. >> >> >> On 09/03/2013 05:57 AM, Paul Aitken wrote: >>> Yaakov, >>> >>>> Fine with me since it simplifies the interpretation (DEI=0 means >>>> green and DEI=1 means yellow). >>>> >>>> By first bitdo you mean least significant bit? >>>> >>> >>> Yes. If needs be we could add a figure something like so: >>> >>> 0 1 2 3 4 5 6 7 >>> +-----+-----+-----+-----+-----+-----+-----+-----+ >>> | Reserved | DEI | >>> +-----+-----+-----+-----+-----+-----+-----+-----+ >> >> This is option 1 and is compatible with 3 as long as reserved bit 6 >> is never used. Option 2 only ever sets bit 7 to 0, but does change >> bit 3 in the reserved area. >> >>> Although if we were defining this again, it might be more useful to >>> retain the DEI position, and potentially include the PCP bits. >>> >>> So, per 802.1Q-2011 Figure 9-1 (attached) : >>> >>> 0 1 2 3 4 5 6 7 >>> +-----+-----+-----+-----+-----+-----+-----+-----+ >>> | PCP | DEI | Reserved | >>> +-----+-----+-----+-----+-----+-----+-----+-----+ >>> >>> However I suspect that this is incompatible with current >>> implementations, so the change is not possible? >> >> This is a total change as this is no longer just dot1qDEI. >> >> I'm slightly in favor of option 1, but ultimately I simply don't want >> to receive an identical value from different exporters which I am >> expected to interpret differently. >> >> >> -Andrew >> >> >>> >>> P. >>> >>> >>>> *From:*Paul Aitken [mailto:paitken@cisco.com] >>>> *Sent:* 02 September, 2013 21:46 >>>> *To:* IETF IPFIX Working Group; ie-doctors@ietf.org >>>> *Cc:* Yaakov Stein >>>> *Subject:* IPFIX: boolean, dot1qDEI and dot1qCustomerDEI >>>> >>>> Dear IPFIX experts, >>>> >>>> While reviewing IANA's IPFIX registry, I noticed that although IEs >>>> #388 dot1qDEI and #389 dot1qCustomerDEI are defined as "boolean" >>>> their definitions do not correspond to that type. >>>> >>>> As a reminder, RFC5101bis says: >>>> >>>> 6.1.5. boolean >>>> >>>> The boolean data type is specified according to the TruthValue in >>>> [RFC2579]. It is encoded as a single-octet integer per >>>> Section 6.1.1,with the value 1 for true and value 2 for false. >>>> Every other value is undefined. >>>> >>>> >>>> (for consistency with MIB truthValue). >>>> >>>> So a boolean IE cannot capture a bit field such as the DEI required >>>> by #388 and #389. I checked the other boolean IEs, and they're fine. >>>> >>>> To correct this, I propose that #388 and #389 be changed from >>>> "boolean" to "unsigned8", in line with all the other flags fields: >>>> >>>> 388 >>>> >>>> >>>> >>>> dot1qDEI >>>> >>>> >>>> >>>> boolean >>>> unsigned8 >>>> >>>> >>>> >>>> flags >>>> >>>> >>>> >>>> current >>>> >>>> >>>> >>>> >>>> The first bit of this octet is the value of the 1-bit Drop Eligible >>>> Indicator (DEI) field of the VLAN tag as described in 802.1Q-2011 >>>> subclause 9.6. In case of a QinQ frame, it represents the outer >>>> tag's DEI field and in case of an IEEE 802.1ad frame it represents >>>> the DEI field of the S-TAG. Note: in earlier versions of 802.1Q the >>>> same bit field in the incoming packet is occupied by the Canonical >>>> Format Indicator (CFI) field, except for S-TAGs. >>>> The remainder of this octet is reserved for future use. >>>> >>>> 389 >>>> >>>> >>>> >>>> dot1qCustomerDEI >>>> >>>> >>>> >>>> boolean >>>> unsigned8 >>>> >>>> >>>> >>>> flags >>>> >>>> >>>> >>>> current >>>> >>>> >>>> >>>> >>>> In case of a QinQ frame, the first bit of this octet it represents >>>> the inner tag's Drop Eligible Indicator (DEI) field and in case of >>>> an IEEE 802.1ad frame it represents the DEI field of the C-TAG. >>>> The remainder of this octet is reserved for future use. >>>> >>>> >>>> >>>> Feedback? >>>> >>>> P. >>>> >>> >>> >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> > --------------000203030302020203020506 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 09/04/2013 06:26 PM, Paul Aitken wrote:
Andrew,

I think it depends a lot on what was already implemented - or perhaps, on what we suspect may already have been implemented, given that we can't possibly expect to know them all.

In practice, I suspect that only Yaakov Stein has implemented these fields so far... so I'd be happy to be guided by whatever he did.

From his earlier reply, I suspect that may be option 1 : LSB = 0 or 1.

Works for me.

-Andrew


P.


On 04/09/13 22:50, Andrew Feren wrote:
Hi Paul, all,

I think some clarification is needed, but I'm not sure what the right answer is.

I see at least three valid readings of the combination of boolean, flags, and "The value of the 1-bit Drop Eligible Indicator (DEI) field"

1) send "the value": if DEI bit set (0x01) / unset (0x00) (looks a lot like least significant bit set/unset ;-)
This is what the initial correction seems to assume. 


2) semantics "flags": if DEI bit set (0x10) / unset (0x00).
This is the interpretation that including pcp would require


3) strict data type "boolean": if DEI bit set (0x01) / unset (0x02).
This is a variation on option 1 where boolean was interpreted strictly.

1 and 2 can be viewed as the same except for which bit gets flipped.


On 09/03/2013 05:57 AM, Paul Aitken wrote:
Yaakov,

Fine with me since it simplifies the interpretation (DEI=0 means green and DEI=1 means yellow).

 

By first bit do you mean least significant bit ?


Yes. If needs be we could add a figure something like so:

	   0     1     2     3     4     5     6     7
	+-----+-----+-----+-----+-----+-----+-----+-----+
	|                Reserved                 | DEI |
	+-----+-----+-----+-----+-----+-----+-----+-----+

This is option 1 and is compatible with 3 as long as reserved bit 6 is never used.  Option 2 only ever sets bit 7 to 0, but does change bit 3 in the reserved area.


          Although if we were defining this again, it might be more
          useful to retain the DEI position, and potentially include the
          PCP bits.

          

          So, per 802.1Q-2011 Figure 9-1 (attached) :

          

          
	   0     1     2     3     4     5     6     7
	+-----+-----+-----+-----+-----+-----+-----+-----+
	|       PCP       | DEI |        Reserved       |
	+-----+-----+-----+-----+-----+-----+-----+-----+

          

          However I suspect that this is incompatible with current
          implementations, so the change is not possible?

        

        

        This is a total change as this is no longer just dot1qDEI.

        

        I'm slightly in favor of option 1, but ultimately I simply don't
        want to receive an identical value from different exporters
        which I am expected to interpret differently.

        

        

        -Andrew

        

        

        
 

          P.

          

          

          

            

              

                

                  
From:
                      Paul Aitken [mailto:paitken@cisco.com]
                      

                      Sent: 02 September, 2013 21:46

                      To: IETF IPFIX Working Group; ie-doctors@ietf.org

                      Cc: Yaakov Stein

                      Subject: IPFIX: boolean, dot1qDEI and
                      dot1qCustomerDEI

                

              

              
 

              
Dear IPFIX experts,

                

                While reviewing IANA's IPFIX registry, I noticed that
                although IEs #388 dot1qDEI and #389 dot1qCustomerDEI are
                defined as "boolean" their definitions do not correspond
                to that type.

                

                As a reminder, RFC5101bis says:

              
6.1.5.  boolean

              
 

              
   The boolean data type is specified according to the TruthValue in

              
   [RFC2579].  It is encoded as a single-octet integer per

              
   Section 6.1.1, with the value 1 for true and value 2 for false.

              
   Every other value is undefined.

              


                (for consistency with MIB truthValue).

                

                So a boolean IE cannot capture a bit field such as the
                DEI required by #388 and #389. I checked the other
                boolean IEs, and they're fine.

                

                To correct this, I propose that #388 and #389 be changed
                from "boolean" to "unsigned8", in line with all the
                other flags fields:

                

                

              

                
                  

                    
                      
388

                    		
                    
                      
dot1qDEI

                    		
                    
                      
boolean

                        unsigned8

                    		
                    
                      
flags

                    		
                    
                      
current

                    		
                    
                      


                          The first bit of this octet is the
                        value of the 1-bit Drop Eligible Indicator (DEI)
                        field of the VLAN tag as described in
                        802.1Q-2011 subclause 9.6. In case of a QinQ
                        frame, it represents the outer tag's DEI field
                        and in case of an IEEE 802.1ad frame it
                        represents the DEI field of the S-TAG. Note: in
                        earlier versions of 802.1Q the same bit field in
                        the incoming packet is occupied by the Canonical
                        Format Indicator (CFI) field, except for S-TAGs.

                        The remainder of
                          this octet is reserved for future use.

                    		
                  

                  

                    
                      
389

                    		
                    
                      
dot1qCustomerDEI

                    		
                    
                      
boolean

                        unsigned8

                    		
                    
                      
flags

                    		
                    
                      
current

                    		
                    
                      


                        In case of a QinQ frame, the first bit of this
                          octet it represents the inner
                        tag's Drop Eligible Indicator (DEI) field and in
                        case of an IEEE 802.1ad frame it represents the
                        DEI field of the C-TAG.

                        The remainder of
                          this octet is reserved for future use.

                    		
                  

                
              

              


                

                Feedback?

                

                P.

            

          

          

          

          

          

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


        

        

      

      

    

    

  


--------------000203030302020203020506--

From trammell@tik.ee.ethz.ch  Fri Sep  6 03:36:14 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5741E11E828E for ; Fri,  6 Sep 2013 03:36:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cglefy7RDy8d for ; Fri,  6 Sep 2013 03:36:09 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A7FDD11E828D for ; Fri,  6 Sep 2013 03:36:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E2D7CD9304 for ; Fri,  6 Sep 2013 12:36:05 +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 yeUDab0ptAWq for ; Fri,  6 Sep 2013 12:36:05 +0200 (MEST)
Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A612ED9300 for ; Fri,  6 Sep 2013 12:36:05 +0200 (MEST)
From: Brian Trammell 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 6 Sep 2013 12:36:04 +0200
References: <20130906103153.12035.82313.idtracker@ietfa.amsl.com>
To: "ipfix@ietf.org Group" 
Message-Id: <342399C2-1D8E-4685-B6C2-4A863D0F31AA@tik.ee.ethz.ch>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-tcpcontrolbits-revision-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Sep 2013 10:36:14 -0000

Greetings, all,

I've submitted a new draft, essentially an Internet-Draft version of the =
revision of the tcpControlBits Information Element discussed on the =
IPFIX list and approved by the IE-DOCTORS. _Why_ this needs to be =
published as an RFC is explained in the Introduction section of the =
draft:

   The revised definition of the Information Element in Section 2 was
   developed and approved through the IE-DOCTORS process
   [I-D.ietf-ipfix-ie-doctors] in August 2013.  Section 5.1 of
   [I-D.ietf-ipfix-ie-doctors] states "This process should not in any
   way be construed as allowing the IE-DOCTORS to overrule IETF
   consensus.  Specifically, Information Elements in the IANA IE
   registry which were added with IETF consensus require IETF consensus
   for revision or deprecation".  Since the tcpControlBits Information
   Element was defined in [RFC5102], an IETF Proposed Standard, any
   revision of this Information Element definition requires IETF
   Consensus.  The publication of this document fulfills that
   requirement.

If you have any comments, please give them quickly; my intention is to =
seek publication as quickly as possible, as the document merely =
formalizes for process reasons a decision already made within the WG and =
approved by the IE-DOCTORS.

Many thanks, best regards,

Brian


Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-trammell-ipfix-tcpcontrolbits-revision-00.txt
> Date: September 6, 2013 12:31:53 PM GMT+02:00
> To: Brian Trammell , Paul Aitken =

>=20
>=20
> A new version of I-D, =
draft-trammell-ipfix-tcpcontrolbits-revision-00.txt
> has been successfully submitted by Brian Trammell and posted to the
> IETF repository.
>=20
> Filename:	 draft-trammell-ipfix-tcpcontrolbits-revision
> Revision:	 00
> Title:		 Revision of the tcpControlBits IPFIX =
Information Element
> Creation date:	 2013-09-06
> Group:		 Individual Submission
> Number of pages: 5
> URL:             =
http://www.ietf.org/internet-drafts/draft-trammell-ipfix-tcpcontrolbits-re=
vision-00.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-trammell-ipfix-tcpcontrolbits-revisi=
on
> Htmlized:        =
http://tools.ietf.org/html/draft-trammell-ipfix-tcpcontrolbits-revision-00=

>=20
>=20
> Abstract:
>   This document revises the tcpControlBits IPFIX Information Element
>   defined in [RFC5102] to reflect changes to the TCP Flags header =
field
>   since [RFC0793].
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat


From trammell@tik.ee.ethz.ch  Fri Sep  6 11:01:44 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159AC21E80C9 for ; Fri,  6 Sep 2013 11:01:44 -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=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55A9IHPaXrFg for ; Fri,  6 Sep 2013 11:01:39 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E5E2B11E81A7 for ; Fri,  6 Sep 2013 11:01:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4E2C0D9307 for ; Fri,  6 Sep 2013 20:01:38 +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 DhdhGEwgsMDg for ; Fri,  6 Sep 2013 20:01:38 +0200 (MEST)
Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1C031D9304 for ; Fri,  6 Sep 2013 20:01:38 +0200 (MEST)
From: Brian Trammell 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 6 Sep 2013 20:01:37 +0200
References: <20130906180035.21414.34847.idtracker@ietfa.amsl.com>
To: "ipfix@ietf.org Group" 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-tcpcontrolbits-revision-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Sep 2013 18:01:44 -0000

Greetings, all,

FYI, have posted a new version of the tcpControlBits draft, including =
comments (thanks Paul and Andrew!)

Cheers,

Brian

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-trammell-ipfix-tcpcontrolbits-revision-01.txt
> Date: September 6, 2013 8:00:35 PM GMT+02:00
> To: Brian Trammell , Paul Aitken =

>=20
>=20
> A new version of I-D, =
draft-trammell-ipfix-tcpcontrolbits-revision-01.txt
> has been successfully submitted by Brian Trammell and posted to the
> IETF repository.
>=20
> Filename:	 draft-trammell-ipfix-tcpcontrolbits-revision
> Revision:	 01
> Title:		 Revision of the tcpControlBits IPFIX =
Information Element
> Creation date:	 2013-09-06
> Group:		 Individual Submission
> Number of pages: 5
> URL:             =
http://www.ietf.org/internet-drafts/draft-trammell-ipfix-tcpcontrolbits-re=
vision-01.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-trammell-ipfix-tcpcontrolbits-revisi=
on
> Htmlized:        =
http://tools.ietf.org/html/draft-trammell-ipfix-tcpcontrolbits-revision-01=

> Diff:            =
http://www.ietf.org/rfcdiff?url2=3Ddraft-trammell-ipfix-tcpcontrolbits-rev=
ision-01
>=20
> Abstract:
>   This document revises the tcpControlBits IPFIX Information Element
>   defined in [RFC5102] to reflect changes to the TCP Flags header =
field
>   since [RFC0793].
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat


From braun@net.in.tum.de  Tue Sep 10 01:32:51 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA5A21E8191 for ; Tue, 10 Sep 2013 01:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.351
X-Spam-Level: 
X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa-s6vEHxu9x for ; Tue, 10 Sep 2013 01:32:46 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mailsender1x.informatik.tu-muenchen.de [131.159.0.99]) by ietfa.amsl.com (Postfix) with ESMTP id 6416721E8180 for ; Tue, 10 Sep 2013 01:32:45 -0700 (PDT)
Received: from horst.fritz.box (mnch-5d876293.pool.mediaWays.net [93.135.98.147]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 8DAA01826075; Tue, 10 Sep 2013 10:32:43 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Lothar Braun 
In-Reply-To: <342399C2-1D8E-4685-B6C2-4A863D0F31AA@tik.ee.ethz.ch>
Date: Tue, 10 Sep 2013 10:32:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130906103153.12035.82313.idtracker@ietfa.amsl.com> <342399C2-1D8E-4685-B6C2-4A863D0F31AA@tik.ee.ethz.ch>
To: Brian Trammell 
X-Mailer: Apple Mail (2.1508)
Cc: "ipfix@ietf.org Group" 
Subject: Re: [IPFIX] New Version Notification for draft-trammell-ipfix-tcpcontrolbits-revision-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Sep 2013 08:32:51 -0000

Hi,

I have some clarification questions/comments inline (I'm commenting on =
version 02)


>=20
>=20
> IPFIX Working Group                                          B. =
Trammell
> Internet-Draft                                                ETH =
Zurich
> Intended status: Informational                                 P. =
Aitken
> Expires: March 13, 2014                               Cisco Systems, =
Inc
>                                                       September 09, =
2013
>=20
>=20
>         Revision of the tcpControlBits IPFIX Information Element
>           draft-trammell-ipfix-tcpcontrolbits-revision-02.txt
>=20
> Abstract
>=20
>    This document revises the tcpControlBits IPFIX Information Element
>    defined in [RFC5102] to reflect changes to the TCP Flags header =
field
>    since [RFC0793].
>=20
> Status of This Memo
>=20
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>=20
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current =
Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>=20
>    Internet-Drafts are draft documents valid for a maximum of six =
months
>    and may be updated, replaced, or obsoleted by other documents at =
any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>=20
>    This Internet-Draft will expire on March 13, 2014.
>=20
> Copyright Notice
>=20
>    Copyright (c) 2013 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>=20
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with =
respect
>    to this document.  Code Components extracted from this document =
must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
>=20
>=20
>=20
>=20
> Trammell & Aitken        Expires March 13, 2014                 [Page =
1]
> Internet-Draft            IPFIX tcpControlBits            September =
2013
>=20
>=20
> 1.  Introduction
>=20
>    Octets 12 and 13 of the TCP header encode the data offset (header
>    length) in four bits, as well as 12 bits of flags.  The least
>    significant 6 bits of these were defined in [RFC0793] as URG, ACK,
>    PSH, RST, SYN, and FIN for TCP control.  Subsequently, [RFC3168]
>    defined the CWR and ECE flags for Explicit Congestion Notification
>    (ECN) negotiation and signaling; [RFC3540] additionally defined the
>    NS flag for the ECN Nonce Sum.
>=20
>    As defined in the IANA IPFIX Information Element Registry
>    [IANA-IPFIX], taken from [RFC5102], the tcpControlBits Information
>    Element for IPFIX [I-D.ietf-ipfix-protocol-rfc5101bis] only covers
>    the original six bits from [RFC0793].  To allow IPFIX to be used to
>    measure the use of ECN, and to bring the IPFIX Information Element
>    definition in line with the current definition of the TCP Flags
>    header field, it is necessary to revise this definition.
>=20
>    The revised definition of the Information Element in Section 2 was
>    developed and approved through the IE-DOCTORS process
>    [I-D.ietf-ipfix-ie-doctors] in August 2013.  Section 5.1 of
>    [I-D.ietf-ipfix-ie-doctors] states "This process should not in any
>    way be construed as allowing the IE-DOCTORS to overrule IETF
>    consensus.  Specifically, Information Elements in the IANA IE
>    registry which were added with IETF consensus require IETF =
consensus
>    for revision or deprecation".  Since the tcpControlBits Information
>    Element was defined in [RFC5102], an IETF Proposed Standard, any
>    revision of this Information Element definition requires IETF
>    Consensus.  The publication of this document fulfills that
>    requirement.
>=20
>    The following section defines the revised tcpControlBits =
Information
>    Element as in Section 9.1 of [I-D.ietf-ipfix-ie-doctors].
>=20
> 2.  The tcpControlBits Information Element
>=20
>    ElementId:   6
>    Data Type:   unsigned16
>    Data Type Semantics:   flags
>    Description:   TCP control bits observed for the packets of this
>       Flow.  This information is encoded as a bit field; for each TCP
>       control bit, there is a bit in this set.  The bit is set to 1 if
>       any observed packet of this Flow has the corresponding TCP =
control
>       bit set to 1.  The bit is cleared to 0 otherwise.
>=20
>       The values of each bit are shown below, per the definition of =
the
>       bits in the TCP header [RFC0793]:
>=20
>=20
>=20
>=20
> Trammell & Aitken        Expires March 13, 2014                 [Page =
2]
> Internet-Draft            IPFIX tcpControlBits            September =
2013
>=20
>=20
>     MSb                                                         LSb
>      0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
>    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>    |               |           | N | C | E | U | A | P | R | S | F |
>    |     Zero      |   Future  | S | W | C | R | C | S | S | Y | I |
>    | (Data Offset) |    Use    |   | R | E | G | K | H | T | N | N |
>    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>=20
>    bit    flag
>    value  name  description
>    ------+-----+-------------------------------------
>    0x8000       Zero (see tcpHeaderLength)
>    0x4000       Zero (see tcpHeaderLength)
>    0x2000       Zero (see tcpHeaderLength)
>    0x1000       Zero (see tcpHeaderLength)
>    0x0800       Future Use
>    0x0400       Future Use
>    0x0200       Future Use
>    0x0100   NS  ECN Nonce Sum
>    0x0080  CWR  Congestion Window Reduced
>    0x0040  ECE  ECN Echo
>    0x0020  URG  Urgent Pointer field significant
>    0x0010  ACK  Acknowledgment field significant
>    0x0008  PSH  Push Function
>    0x0004  RST  Reset the connection
>    0x0002  SYN  Synchronize sequence numbers
>    0x0001  FIN  No more data from sender
>=20
>=20
>       As the most significant four bits of octets 12 and 13 of the TCP
>       header [RFC0793] are used to encode the TCP data offset (header
>       length), the corresponding bits in this IE must be exported as
>       zero and must be ignored by the collector; use the =
tcpHeaderLength
>       Information Element to encode this value.

Are there good reasons for the two "must" in this sentence? (And =
shouldn't this be a MUST if this really should be zero?).=20

We could, at some point in the future, decide to use those four bits for =
something else. This happened for example with the CWR and ECE bits of =
the previous definition that had a requirement to be zero. Later on, it =
turned out that those bits had to be used for encoding something that =
the original definition hadn't thought about.=20

I understand that these four bits are not likely to be used in the TCP =
header length to encode any useful information for flow data, but we =
might decide to use those four bits for encoding other information, e.g. =
some more information about the TCP connection state (or whatever else =
we might think about).=20

What I would like to have would be some text that sets the bits to =
reserved and says something like:

"Bits 0x1000 through 0x.8000 are reserved for future use. A collector =
must not assume to receive information about the TCP header length; the =
field tcpHeaderLength Information Element should be used to encode this =
value."

What do you think?


>       Each of the three future use bits (0x800, 0x400, and 0x200) =
should
>       be exported as one if the corresponding bit is observed in the =
TCP
>       headers of the packets of this Flow, as they may be subsequent =
to
>       a future update of [RFC0793].

What does "as one" in "exported AS ONE if" mean? Does this mean that =
these bits must be exported as seen in the packet headers?

>       If exported as a single octet with reduced length encoding,

Nit: RFC 5101 calls it reduced size encoding (at least most of the time =
;))

> this
>       Information Element covers the low-order octet of this field =
(i.e,
>       bits 0x80 to 0x01), omitting the ECN Nonce Sum and the three
>       Future Use bits.  A collector receiving this Information Element
>       with reduced length encoding must not assume anything about the
>       content of these four bits.

I just wanted to raise this point (without objecting). This would =
clearly be an exception to what I would expect from reduced size =
encoding in RFC 5101bis:

   The reduction in size can be to any number of
   octets smaller than the original type if the data value still fits,
   i.e., so that only leading zeroes are dropped.

Whenever I see reduced size encoding, I assume that there is no further =
information in the field and that all leading bits are zero because of =
this text. But I would assume this is not a hard requirement from RFC =
5101(bis), and it is probably ok if the data type has an explicit =
definition that states that the first bits are not zero.

>=20
>=20
> Trammell & Aitken        Expires March 13, 2014                 [Page =
3]
> Internet-Draft            IPFIX tcpControlBits            September =
2013
>=20
>=20
>       Note that previous revisions of this Information Element's
>       definition specified that the CWR and ECE bits must be exported =
as
>       zero, even if observed.  Collectors should therefore not assume
>       that a value of zero for these bits in this Information Element
>       indicates the bits were never set in the observed traffic,
>       especially if these bits are zero in every Flow Record sent by a
>       given exporter.
>    References:   [RFC0793][RFC3168][RFC3540]
>    Revision:  1
>=20
> 3.  IANA Considerations
>=20
>    IANA will update the definition of the tcpControlBits Information
>    Element in the the IANA IPFIX Information Element Registry
>    [IANA-IPFIX] to reflect the changes in Section 2 above.
>=20
> 4.  Security and Privacy Considerations
>=20
>    This document has no security or privacy considerations; the =
security
>    considerations for IPFIX [I-D.ietf-ipfix-protocol-rfc5101bis] =
apply.
>=20
> 5.  Acknowledgments
>=20
>    Thanks to Andrew Feren for comments on the revised definition.  =
This
>    work is partially supported by the European Commission under grant
>    agreement FP7-ICT-318627 mPlane; this does not imply endorsement by
>    the Commission.
>=20
> 6.  References
>=20
> 6.1.  Normative References
>=20
>    [I-D.ietf-ipfix-protocol-rfc5101bis]
>               Claise, B. and B. Trammell, "Specification of the IP =
Flow
>               Information eXport (IPFIX) Protocol for the Exchange of
>               Flow Information", =
draft-ietf-ipfix-protocol-rfc5101bis-10
>               (work in progress), July 2013.
>=20
>    [I-D.ietf-ipfix-ie-doctors]
>               Trammell, B. and B. Claise, "Guidelines for Authors and
>               Reviewers of IPFIX Information Elements", draft-ietf-
>               ipfix-ie-doctors-07 (work in progress), October 2012.
>=20
>    [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
>               793, September 1981.
>=20
>=20
>=20
>=20
>=20
>=20
> Trammell & Aitken        Expires March 13, 2014                 [Page =
4]
> Internet-Draft            IPFIX tcpControlBits            September =
2013
>=20
>=20
>    [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
>               of Explicit Congestion Notification (ECN) to IP", RFC
>               3168, September 2001.
>=20
>    [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
>               Congestion Notification (ECN) Signaling with Nonces", =
RFC
>               3540, June 2003.
>=20
> 6.2.  Informative References
>=20
>    [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
>               Meyer, "Information Model for IP Flow Information =
Export",
>               RFC 5102, January 2008.
>=20
>    [IANA-IPFIX]
>               Internet Assigned Numbers Authority, ., "IP Flow
>               Information Export Information Elements
>               (http://www.iana.org/assignments/ipfix)", .
>=20
> Authors' Addresses
>=20
>    Brian Trammell
>    Swiss Federal Institute of Technology Zurich
>    Gloriastrasse 35
>    8092 Zurich
>    Switzerland
>=20
>    Phone: +41 44 632 70 13
>    Email: trammell@tik.ee.ethz.ch
>=20
>=20
>    Paul Aitken
>    Cisco Systems, Inc.
>    96 Commercial Quay
>    Commercial Street, Edinburgh EH6 6LX
>    United Kingdom
>=20
>    Phone: +44 131 561 3616
>    Email: paitken@cisco.com



--
Lothar Braun
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universit=E4t M=FCnchen
Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany
Phone:  +49 89 289-18010       Fax: +49 89 289-18033
E-mail: braun@net.in.tum.de=20







From trammell@tik.ee.ethz.ch  Tue Sep 10 04:11:58 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1C611E819C for ; Tue, 10 Sep 2013 04:11: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUEcEMqwze44 for ; Tue, 10 Sep 2013 04:11:53 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE2111E818B for ; Tue, 10 Sep 2013 04:11:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0EB35D9309; Tue, 10 Sep 2013 13:11:47 +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 Z5Ek2kOqSP5Y; Tue, 10 Sep 2013 13:11:46 +0200 (MEST)
Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BDC74D9305; Tue, 10 Sep 2013 13:11:46 +0200 (MEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Brian Trammell 
In-Reply-To: 
Date: Tue, 10 Sep 2013 13:11:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C0C8370-E6DF-4A67-83DF-F470BB6EC87E@tik.ee.ethz.ch>
References: <20130906103153.12035.82313.idtracker@ietfa.amsl.com> <342399C2-1D8E-4685-B6C2-4A863D0F31AA@tik.ee.ethz.ch> 
To: Lothar Braun 
X-Mailer: Apple Mail (2.1508)
Cc: "ipfix@ietf.org Group" 
Subject: Re: [IPFIX] New Version Notification for draft-trammell-ipfix-tcpcontrolbits-revision-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Sep 2013 11:11:59 -0000

On 10 Sep 2013, at 10:32 , Lothar Braun  wrote:

> Hi,
>=20
> I have some clarification questions/comments inline (I'm commenting on =
version 02)
>=20
>=20
>>=20
>>=20
>> IPFIX Working Group                                          B. =
Trammell
>> Internet-Draft                                                ETH =
Zurich
>> Intended status: Informational                                 P. =
Aitken
>> Expires: March 13, 2014                               Cisco Systems, =
Inc
>>                                                      September 09, =
2013
>>=20
>>=20
>>        Revision of the tcpControlBits IPFIX Information Element
>>          draft-trammell-ipfix-tcpcontrolbits-revision-02.txt
>>=20
>> Abstract
>>=20
>>   This document revises the tcpControlBits IPFIX Information Element
>>   defined in [RFC5102] to reflect changes to the TCP Flags header =
field
>>   since [RFC0793].
>>=20
>> Status of This Memo
>>=20
>>   This Internet-Draft is submitted in full conformance with the
>>   provisions of BCP 78 and BCP 79.
>>=20
>>   Internet-Drafts are working documents of the Internet Engineering
>>   Task Force (IETF).  Note that other groups may also distribute
>>   working documents as Internet-Drafts.  The list of current =
Internet-
>>   Drafts is at http://datatracker.ietf.org/drafts/current/.
>>=20
>>   Internet-Drafts are draft documents valid for a maximum of six =
months
>>   and may be updated, replaced, or obsoleted by other documents at =
any
>>   time.  It is inappropriate to use Internet-Drafts as reference
>>   material or to cite them other than as "work in progress."
>>=20
>>   This Internet-Draft will expire on March 13, 2014.
>>=20
>> Copyright Notice
>>=20
>>   Copyright (c) 2013 IETF Trust and the persons identified as the
>>   document authors.  All rights reserved.
>>=20
>>   This document is subject to BCP 78 and the IETF Trust's Legal
>>   Provisions Relating to IETF Documents
>>   (http://trustee.ietf.org/license-info) in effect on the date of
>>   publication of this document.  Please review these documents
>>   carefully, as they describe your rights and restrictions with =
respect
>>   to this document.  Code Components extracted from this document =
must
>>   include Simplified BSD License text as described in Section 4.e of
>>   the Trust Legal Provisions and are provided without warranty as
>>   described in the Simplified BSD License.
>>=20
>>=20
>>=20
>>=20
>> Trammell & Aitken        Expires March 13, 2014                 [Page =
1]
>> Internet-Draft            IPFIX tcpControlBits            September =
2013
>>=20
>>=20
>> 1.  Introduction
>>=20
>>   Octets 12 and 13 of the TCP header encode the data offset (header
>>   length) in four bits, as well as 12 bits of flags.  The least
>>   significant 6 bits of these were defined in [RFC0793] as URG, ACK,
>>   PSH, RST, SYN, and FIN for TCP control.  Subsequently, [RFC3168]
>>   defined the CWR and ECE flags for Explicit Congestion Notification
>>   (ECN) negotiation and signaling; [RFC3540] additionally defined the
>>   NS flag for the ECN Nonce Sum.
>>=20
>>   As defined in the IANA IPFIX Information Element Registry
>>   [IANA-IPFIX], taken from [RFC5102], the tcpControlBits Information
>>   Element for IPFIX [I-D.ietf-ipfix-protocol-rfc5101bis] only covers
>>   the original six bits from [RFC0793].  To allow IPFIX to be used to
>>   measure the use of ECN, and to bring the IPFIX Information Element
>>   definition in line with the current definition of the TCP Flags
>>   header field, it is necessary to revise this definition.
>>=20
>>   The revised definition of the Information Element in Section 2 was
>>   developed and approved through the IE-DOCTORS process
>>   [I-D.ietf-ipfix-ie-doctors] in August 2013.  Section 5.1 of
>>   [I-D.ietf-ipfix-ie-doctors] states "This process should not in any
>>   way be construed as allowing the IE-DOCTORS to overrule IETF
>>   consensus.  Specifically, Information Elements in the IANA IE
>>   registry which were added with IETF consensus require IETF =
consensus
>>   for revision or deprecation".  Since the tcpControlBits Information
>>   Element was defined in [RFC5102], an IETF Proposed Standard, any
>>   revision of this Information Element definition requires IETF
>>   Consensus.  The publication of this document fulfills that
>>   requirement.
>>=20
>>   The following section defines the revised tcpControlBits =
Information
>>   Element as in Section 9.1 of [I-D.ietf-ipfix-ie-doctors].
>>=20
>> 2.  The tcpControlBits Information Element
>>=20
>>   ElementId:   6
>>   Data Type:   unsigned16
>>   Data Type Semantics:   flags
>>   Description:   TCP control bits observed for the packets of this
>>      Flow.  This information is encoded as a bit field; for each TCP
>>      control bit, there is a bit in this set.  The bit is set to 1 if
>>      any observed packet of this Flow has the corresponding TCP =
control
>>      bit set to 1.  The bit is cleared to 0 otherwise.
>>=20
>>      The values of each bit are shown below, per the definition of =
the
>>      bits in the TCP header [RFC0793]:
>>=20
>>=20
>>=20
>>=20
>> Trammell & Aitken        Expires March 13, 2014                 [Page =
2]
>> Internet-Draft            IPFIX tcpControlBits            September =
2013
>>=20
>>=20
>>    MSb                                                         LSb
>>     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
>>   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>>   |               |           | N | C | E | U | A | P | R | S | F |
>>   |     Zero      |   Future  | S | W | C | R | C | S | S | Y | I |
>>   | (Data Offset) |    Use    |   | R | E | G | K | H | T | N | N |
>>   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>>=20
>>   bit    flag
>>   value  name  description
>>   ------+-----+-------------------------------------
>>   0x8000       Zero (see tcpHeaderLength)
>>   0x4000       Zero (see tcpHeaderLength)
>>   0x2000       Zero (see tcpHeaderLength)
>>   0x1000       Zero (see tcpHeaderLength)
>>   0x0800       Future Use
>>   0x0400       Future Use
>>   0x0200       Future Use
>>   0x0100   NS  ECN Nonce Sum
>>   0x0080  CWR  Congestion Window Reduced
>>   0x0040  ECE  ECN Echo
>>   0x0020  URG  Urgent Pointer field significant
>>   0x0010  ACK  Acknowledgment field significant
>>   0x0008  PSH  Push Function
>>   0x0004  RST  Reset the connection
>>   0x0002  SYN  Synchronize sequence numbers
>>   0x0001  FIN  No more data from sender
>>=20
>>=20
>>      As the most significant four bits of octets 12 and 13 of the TCP
>>      header [RFC0793] are used to encode the TCP data offset (header
>>      length), the corresponding bits in this IE must be exported as
>>      zero and must be ignored by the collector; use the =
tcpHeaderLength
>>      Information Element to encode this value.
>=20
> Are there good reasons for the two "must" in this sentence?=20

Well, we'd really like to enable the following code on the first packet =
(assuming you have an alignment-friendly architecture):

tcp_control_bits =3D ntohl((uint16_t *)(tcp_hdr_base + 12)) & 0x0FFF;

and the following on subsequent packets:

tcp_control_bits |=3D ntohl((uint16_t *)(tcp_hdr_base + 12)) & 0x0FFF;

> (And shouldn't this be a MUST if this really should be zero?).=20

This section doesn't use 2119 language because it's meant to be inserted =
into the registry, where, IIRC, 2119 isn't explicitly in effect.

> We could, at some point in the future, decide to use those four bits =
for something else.

I'm not sure how you'd get such a proposal past the IE doctors :). The =
other header-field-like IEs in the information model are clearly taken =
from a portion of the packet, so an IE that used the top four bits for =
something else would break that precedent.

> This happened for example with the CWR and ECE bits of the previous =
definition that had a requirement to be zero. Later on, it turned out =
that those bits had to be used for encoding something that the original =
definition hadn't thought about.=20

Right, but in that case, the bits were reserved for future use in TCP, =
not in IPFIX. The mistake we made in the 5101 revision of this IE is =
referencing 793 only, and not the updates to it. (This is why there's a =
difference between Zero and Future Use in this IE definition).

> I understand that these four bits are not likely to be used in the TCP =
header length to encode any useful information for flow data, but we =
might decide to use those four bits for encoding other information, e.g. =
some more information about the TCP connection state (or whatever else =
we might think about).=20

I'm a big fan of "each IE means one thing", even at the expense of =
efficiency, especially as these IEs are beginning to see use outside =
IPFIX. But it's entirely possible if unlikely that at some point in the =
future we'll reuse these four bits for something else, at which point =
the solution is a matter for the people writing the redefinition, and =
will probably look a lot like what we did for the ECN flag bits.

> What I would like to have would be some text that sets the bits to =
reserved and says something like:
>=20
> "Bits 0x1000 through 0x.8000 are reserved for future use. A collector =
must not assume to receive information about the TCP header length; the =
field tcpHeaderLength Information Element should be used to encode this =
value."
>=20
> What do you think?

Again, I'm not sure that I'd want to explicitly encourage such reuse.

>=20
>>      Each of the three future use bits (0x800, 0x400, and 0x200) =
should
>>      be exported as one if the corresponding bit is observed in the =
TCP
>>      headers of the packets of this Flow, as they may be subsequent =
to
>>      a future update of [RFC0793].
>=20
> What does "as one" in "exported AS ONE if" mean? Does this mean that =
these bits must be exported as seen in the packet headers?
>=20
>>      If exported as a single octet with reduced length encoding,
>=20
> Nit: RFC 5101 calls it reduced size encoding (at least most of the =
time ;))

Yeah, it turns out I'm the only one who calls it reduced-length. Will =
fix, thanks.

>> this
>>      Information Element covers the low-order octet of this field =
(i.e,
>>      bits 0x80 to 0x01), omitting the ECN Nonce Sum and the three
>>      Future Use bits.  A collector receiving this Information Element
>>      with reduced length encoding must not assume anything about the
>>      content of these four bits.
>=20
> I just wanted to raise this point (without objecting). This would =
clearly be an exception to what I would expect from reduced size =
encoding in RFC 5101bis:
>=20
>   The reduction in size can be to any number of
>   octets smaller than the original type if the data value still fits,
>   i.e., so that only leading zeroes are dropped.
>=20
> Whenever I see reduced size encoding, I assume that there is no =
further information in the field and that all leading bits are zero =
because of this text. But I would assume this is not a hard requirement =
from RFC 5101(bis), and it is probably ok if the data type has an =
explicit definition that states that the first bits are not zero.

Well, it could mean two things: the top bits are zero because the Nonce =
Sum bit was never set on any packet in the flow (which, given studies on =
the usage of ECN, and anecdotes about ECN Nonce deployment, I would say =
is the case 99.99...% of the time), or because it was not observed =
(since nobody uses ECN nonce, nobody measures it, either).

Perhaps we should state that unsigned16 encoding should ONLY be used by =
EPs connected to MPs which actually know how to measure at least one of =
the bits, so that 0s here won't be interpreted as actual assertions of =
no flag present.

Cheers,

Brian=

From andrewf@plixer.com  Thu Sep 12 05:28:09 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26B121E81F5 for ; Thu, 12 Sep 2013 05:28:09 -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=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wQ+21LZhgD1 for ; Thu, 12 Sep 2013 05:28:04 -0700 (PDT)
Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D021E81EF for ; Thu, 12 Sep 2013 05:27:59 -0700 (PDT)
Received: from [10.8.1.10] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Sep 2013 08:27:57 -0400
Message-ID: <5231B344.6010105@plixer.com>
Date: Thu, 12 Sep 2013 08:27:48 -0400
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: 
References: <20130906103153.12035.82313.idtracker@ietfa.amsl.com> <342399C2-1D8E-4685-B6C2-4A863D0F31AA@tik.ee.ethz.ch>  <4C0C8370-E6DF-4A67-83DF-F470BB6EC87E@tik.ee.ethz.ch>
In-Reply-To: <4C0C8370-E6DF-4A67-83DF-F470BB6EC87E@tik.ee.ethz.ch>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [IPFIX] New Version Notification for draft-trammell-ipfix-tcpcontrolbits-revision-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 12:28:09 -0000

On 09/10/2013 07:11 AM, Brian Trammell wrote:
> On 10 Sep 2013, at 10:32 , Lothar Braun  wrote:
[ snip ]
> I'm a big fan of "each IE means one thing", even at the expense of
> efficiency, especially as these IEs are beginning to 

+1

> see use outside IPFIX. But it's entirely possible if unlikely that at
> some point in the future we'll reuse these four bits 

Where else?  Just curious.

> for something else, at which point the solution is a matter for the
> people writing the redefinition, and will probably look a lot like
> what we did for the ECN flag bits.
>> What I would like to have would be some text that sets the bits to reserved and says something like:
>>
>> "Bits 0x1000 through 0x.8000 are reserved for future use. A collector must not assume to receive information about the TCP header length; the field tcpHeaderLength Information Element should be used to encode this value."
>>
>> What do you think?
> Again, I'm not sure that I'd want to explicitly encourage such reuse.

I'd go one step stronger and say such reuse should be actively discouraged.

[ snip ]

>>> this
>>>      Information Element covers the low-order octet of this field (i.e,
>>>      bits 0x80 to 0x01), omitting the ECN Nonce Sum and the three
>>>      Future Use bits.  A collector receiving this Information Element
>>>      with reduced length encoding must not assume anything about the
>>>      content of these four bits.
>> I just wanted to raise this point (without objecting). This would clearly be an exception to what I would expect from reduced size encoding in RFC 5101bis:
>>
>>   The reduction in size can be to any number of
>>   octets smaller than the original type if the data value still fits,
>>   i.e., so that only leading zeroes are dropped.
>>
>> Whenever I see reduced size encoding, I assume that there is no further information in the field and that all leading bits are zero because of this text. But I would assume this is not a hard requirement from RFC 5101(bis), and it is probably ok if the data type has an explicit definition that states that the first bits are not zero.
> Well, it could mean two things: the top bits are zero because the Nonce Sum bit was never set on any packet in the flow (which, given studies on the usage of ECN, and anecdotes about ECN Nonce deployment, I would say is the case 99.99...% of the time), or because it was not observed (since nobody uses ECN nonce, nobody measures it, either).
>
> Perhaps we should state that unsigned16 encoding should ONLY be used by EPs connected to MPs which actually know how to measure at least one of the bits, so that 0s here won't be interpreted as actual assertions of no flag present.

I like this idea.  It provides an avenue to reduce/remove ambiguity.

-Andrew

From andrewf@plixer.com  Fri Sep 13 07:56:51 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCEB21F9E96 for ; Fri, 13 Sep 2013 07:56:45 -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=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtdTHH-3USFp for ; Fri, 13 Sep 2013 07:56:40 -0700 (PDT)
Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1DD11E8180 for ; Fri, 13 Sep 2013 07:56:39 -0700 (PDT)
Received: from [10.8.1.10] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Sep 2013 10:56:38 -0400
Message-ID: <523327A7.6040106@plixer.com>
Date: Fri, 13 Sep 2013 10:56:39 -0400
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: IPFIX Working Group 
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] draft-ietf-ipfix-protocol-rfc5101bis-10 [editorial error]
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Sep 2013 14:56:51 -0000

I just noticed the following in
http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-10

   [RFC5101]      Claise, B., Ed., "Bidirectional Flow Export Using IP
                  Flow Information Export (IPFIX)", RFC 5103, January
                  2008.

   [RFC5103]      Trammell, B., and E. Boschi, "Specification of the IP
                  Flow Information Export (IPFIX) Protocol for the
                  Exchange of IP Traffic Flow Information", RFC 5101,
                  January 2008.

should be

   [RFC5103]      Claise, B., Ed., "Bidirectional Flow Export Using IP
                  Flow Information Export (IPFIX)", RFC 5103, January
                  2008.

   [RFC5101]      Trammell, B., and E. Boschi, "Specification of the IP
                  Flow Information Export (IPFIX) Protocol for the
                  Exchange of IP Traffic Flow Information", RFC 5101,
                  January 2008.

It appears to have been wrong since bis-00 so we all skipped over it
multiple times.

-Andrew

From bclaise@cisco.com  Sun Sep 15 08:36:59 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E36411E8117 for ; Sun, 15 Sep 2013 08:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.543
X-Spam-Level: 
X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBON-L2423V6 for ; Sun, 15 Sep 2013 08:36:55 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 04B1F21E8087 for ; Sun, 15 Sep 2013 08:36:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1331; q=dns/txt; s=iport; t=1379259403; x=1380469003; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OPNMGfBM7G11sdtjqIijlArVO2ROj4QKW456TZIW+H0=; b=fW9vFXUA5YhPGI8TCqynJ13tfor8xRC9ViiSHAQy7siS3poRBCnzk15E GMleEksUTrR3tVrz1wo3ApDc6M3lBu8smKRSam1sN/2CMDYYyK/Tg9z0F U3VBQFIQKZXpiN4sd9Z0B7n6+/E+/MEXVDrGlTE45JNAG54sGwyoELyT5 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFALrSNVKQ/khR/2dsb2JhbABbgwc4wTyBFxZ0giYBAQQBAQE1NgoBEAshFg8JAwIBAgEVMAYNAQUCAQGHfwy5eI9zB4QeA5d7gS+FAYtEgyY6
X-IronPort-AV: E=Sophos;i="4.90,909,1371081600"; d="scan'208";a="86676371"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 15 Sep 2013 15:36:39 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8FFabJc005077; Sun, 15 Sep 2013 15:36:37 GMT
Message-ID: <5235D405.3050407@cisco.com>
Date: Sun, 15 Sep 2013 17:36:37 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Andrew Feren 
References: <523327A7.6040106@plixer.com>
In-Reply-To: <523327A7.6040106@plixer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] draft-ietf-ipfix-protocol-rfc5101bis-10 [editorial error]
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Sep 2013 15:36:59 -0000

Thanks Andrew,

Corrected part of the AUTH48 process.

Regards, Benoit
> I just noticed the following in
> http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-10
>
>     [RFC5101]      Claise, B., Ed., "Bidirectional Flow Export Using IP
>                    Flow Information Export (IPFIX)", RFC 5103, January
>                    2008.
>
>     [RFC5103]      Trammell, B., and E. Boschi, "Specification of the IP
>                    Flow Information Export (IPFIX) Protocol for the
>                    Exchange of IP Traffic Flow Information", RFC 5101,
>                    January 2008.
>
> should be
>
>     [RFC5103]      Claise, B., Ed., "Bidirectional Flow Export Using IP
>                    Flow Information Export (IPFIX)", RFC 5103, January
>                    2008.
>
>     [RFC5101]      Trammell, B., and E. Boschi, "Specification of the IP
>                    Flow Information Export (IPFIX) Protocol for the
>                    Exchange of IP Traffic Flow Information", RFC 5101,
>                    January 2008.
>
> It appears to have been wrong since bis-00 so we all skipped over it
> multiple times.
>
> -Andrew
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
> .
>


From wwwrun@rfc-editor.org  Sun Sep 15 22:05:31 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D6D11E81E6; Sun, 15 Sep 2013 22:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.7
X-Spam-Level: 
X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxzzGq74dTO1; Sun, 15 Sep 2013 22:05:30 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 186AE11E81C3; Sun, 15 Sep 2013 22:05:30 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 712758E01B; Sun, 15 Sep 2013 21:59:07 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130916045909.712758E01B@rfc-editor.org>
Date: Sun, 15 Sep 2013 21:59:07 -0700 (PDT)
Cc: drafts-update-ref@iana.org, ipfix@ietf.org, rfc-editor@rfc-editor.org
Subject: [IPFIX] STD 77, RFC 7011 on Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Sep 2013 05:05:31 -0000

A new Request for Comments is now available in online RFC libraries.

        STD 77        
        RFC 7011

        Title:      Specification of the IP Flow 
                    Information Export (IPFIX) Protocol for the 
                    Exchange of Flow Information 
        Author:     B. Claise, Ed.,
                    B. Trammell, Ed.,
                    P. Aitken
        Status:     Standards Track
        Stream:     IETF
        Date:       September 2013
        Mailbox:    bclaise@cisco.com, 
                    trammell@tik.ee.ethz.ch, 
                    paitken@cisco.com
        Pages:      76
        Characters: 170852
        Obsoletes:  RFC 5101
        See Also:   STD 77

        I-D Tag:    draft-ietf-ipfix-protocol-rfc5101bis-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7011.txt

This document specifies the IP Flow Information Export (IPFIX)
protocol, which serves as a means for transmitting Traffic Flow
information over the network.  In order to transmit Traffic Flow
information from an Exporting Process to a Collecting Process, a
common representation of flow data and a standard means of
communicating them are required.  This document describes how
the IPFIX Data and Template Records are carried over a number of
transport protocols from an IPFIX Exporting Process to an IPFIX
Collecting Process.  This document obsoletes RFC 5101.

This document is a product of the IP Flow Information Export Working Group of the IETF.

This is now an Internet Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From wwwrun@rfc-editor.org  Sun Sep 15 22:06:38 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECA411E8201; Sun, 15 Sep 2013 22:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.73
X-Spam-Level: 
X-Spam-Status: No, score=-101.73 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9NesbICm6Qw; Sun, 15 Sep 2013 22:06:38 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD8211E81F8; Sun, 15 Sep 2013 22:06:35 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 7D9678E021; Sun, 15 Sep 2013 22:00:10 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130916050016.7D9678E021@rfc-editor.org>
Date: Sun, 15 Sep 2013 22:00:10 -0700 (PDT)
Cc: drafts-update-ref@iana.org, ipfix@ietf.org, rfc-editor@rfc-editor.org
Subject: [IPFIX] RFC 7012 on Information Model for IP Flow Information Export (IPFIX)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Sep 2013 05:06:39 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7012

        Title:      Information Model for IP Flow 
                    Information Export (IPFIX) 
        Author:     B. Claise, Ed.,
                    B. Trammell, Ed.
        Status:     Standards Track
        Stream:     IETF
        Date:       September 2013
        Mailbox:    bclaise@cisco.com, 
                    trammell@tik.ee.ethz.ch
        Pages:      24
        Characters: 50237
        Obsoletes:  RFC 5102

        I-D Tag:    draft-ietf-ipfix-information-model-rfc5102bis-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7012.txt

This document defines the data types and management policy for the
information model for the IP Flow Information Export (IPFIX)
protocol.  This information model is maintained as the IANA "IPFIX
Information Elements" registry, the initial contents of which were
defined by RFC 5102.  This information model is used by the IPFIX
protocol for encoding measured traffic information and information
related to the traffic Observation Point, the traffic Metering
Process, and the Exporting Process.  Although this model was developed
for the IPFIX protocol, it is defined in an open way that allows it
to be easily used in other protocols, interfaces, and applications.
This document obsoletes RFC 5102.

This document is a product of the IP Flow Information Export Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From wwwrun@rfc-editor.org  Sun Sep 15 22:07:06 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDCE11E820A; Sun, 15 Sep 2013 22:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.755
X-Spam-Level: 
X-Spam-Status: No, score=-101.755 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cXP-d4RKan3; Sun, 15 Sep 2013 22:07:06 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4210E11E820D; Sun, 15 Sep 2013 22:07:03 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 4A1FA8E022; Sun, 15 Sep 2013 22:00:43 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130916050043.4A1FA8E022@rfc-editor.org>
Date: Sun, 15 Sep 2013 22:00:43 -0700 (PDT)
Cc: drafts-update-ref@iana.org, ipfix@ietf.org, rfc-editor@rfc-editor.org
Subject: [IPFIX] RFC 7014 on Flow Selection Techniques
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Sep 2013 05:07:06 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7014

        Title:      Flow Selection Techniques 
        Author:     S. D'Antonio, T. Zseby,
                    C. Henke, L. Peluso
        Status:     Standards Track
        Stream:     IETF
        Date:       September 2013
        Mailbox:    salvatore.dantonio@uniparthenope.it, 
                    tanja@caida.org, 
                    christian.henke@tektronix.com,
                    lorenzo.peluso@unina.it
        Pages:      33
        Characters: 72581
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ipfix-flow-selection-tech-18.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7014.txt

The Intermediate Flow Selection Process is the process of selecting a
subset of Flows from all observed Flows.  The Intermediate Flow
Selection Process may be located at an IP Flow Information Export
(IPFIX) Exporter or Collector, or within an IPFIX Mediator.  It
reduces the effort of post-processing Flow data and transferring Flow
Records.  This document describes motivations for using the
Intermediate Flow Selection process and presents Intermediate Flow
Selection techniques.  It provides an information model for
configuring Intermediate Flow Selection Process techniques and
discusses what information about an Intermediate Flow Selection
Process should be exported.

This document is a product of the IP Flow Information Export Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From wwwrun@rfc-editor.org  Sun Sep 15 22:07:21 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA3C11E821C; Sun, 15 Sep 2013 22:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.075
X-Spam-Level: 
X-Spam-Status: No, score=-102.075 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxPd+nq7GHfB; Sun, 15 Sep 2013 22:07:20 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 73B9711E8219; Sun, 15 Sep 2013 22:07:12 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 066688E025; Sun, 15 Sep 2013 22:00:50 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130916050051.066688E025@rfc-editor.org>
Date: Sun, 15 Sep 2013 22:00:50 -0700 (PDT)
Cc: drafts-update-ref@iana.org, ipfix@ietf.org, rfc-editor@rfc-editor.org
Subject: [IPFIX] BCP 184, RFC 7013 on Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Sep 2013 05:07:21 -0000

A new Request for Comments is now available in online RFC libraries.

        BCP 184        
        RFC 7013

        Title:      Guidelines for Authors and Reviewers 
                    of IP Flow Information Export (IPFIX) 
                    Information Elements 
        Author:     B. Trammell,
                    B. Claise
        Status:     Best Current Practice
        Stream:     IETF
        Date:       September 2013
        Mailbox:    trammell@tik.ee.ethz.ch, 
                    bclaise@cisco.com
        Pages:      32
        Characters: 76406
        See Also:   BCP 184

        I-D Tag:    draft-ietf-ipfix-ie-doctors-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7013.txt

This document provides guidelines for how to write definitions of new
Information Elements for the IP Flow Information Export (IPFIX)
protocol.  It provides instructions on using the proper conventions
for Information Elements to be registered in the IANA IPFIX
Information Element registry, and provides guidelines for expert
reviewers to evaluate new registrations.

This document is a product of the IP Flow Information Export Working Group of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From wwwrun@rfc-editor.org  Sun Sep 15 22:08:03 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC43111E8201; Sun, 15 Sep 2013 22:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.815
X-Spam-Level: 
X-Spam-Status: No, score=-101.815 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX7qoSrotDUB; Sun, 15 Sep 2013 22:08:03 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6552D11E81C3; Sun, 15 Sep 2013 22:08:01 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 941998E022; Sun, 15 Sep 2013 22:01:35 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130916050136.941998E022@rfc-editor.org>
Date: Sun, 15 Sep 2013 22:01:35 -0700 (PDT)
Cc: drafts-update-ref@iana.org, ipfix@ietf.org, rfc-editor@rfc-editor.org
Subject: [IPFIX] RFC 7015 on Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Sep 2013 05:08:03 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7015

        Title:      Flow Aggregation for the IP 
                    Flow Information Export (IPFIX) Protocol 
        Author:     B. Trammell,
                    A. Wagner,
                    B. Claise
        Status:     Standards Track
        Stream:     IETF
        Date:       September 2013
        Mailbox:    trammell@tik.ee.ethz.ch, 
                    arno@wagner.name, 
                    bclaise@cisco.com
        Pages:      49
        Characters: 112055
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ipfix-a9n-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7015.txt

This document provides a common implementation-independent basis for
the interoperable application of the IP Flow Information Export
(IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX
Flows representing packets from multiple Original Flows sharing some
set of common properties.  It does this through a detailed
terminology and a descriptive Intermediate Aggregation Process
architecture, including a specification of methods for Original Flow
counting and counter distribution across intervals.

This document is a product of the IP Flow Information Export Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From bclaise@cisco.com  Tue Sep 17 23:46:28 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B9F11E819E for ; Tue, 17 Sep 2013 23:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.51
X-Spam-Level: 
X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[AWL=-0.988,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMr02LQNo-2R for ; Tue, 17 Sep 2013 23:46:23 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1D23311E8194 for ; Tue, 17 Sep 2013 23:46:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=175; q=dns/txt; s=iport; t=1379486785; x=1380696385; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=fdzzCIM+BfmI1ls5ioq5T86El6LtEfKVcNia1/7ibik=; b=CViWBlt3e/XFYSxscbHyGQDZ6pvuGLOwZ8NtKb9hVZeYW04R4spJcYYC pnVFtAr2UabpDbBTAcGRgn6EJS+c5K/oSRzZZRmwWYZUNoRHE7hAtGH+x mogrreaTowRiGE50aktK0RJ0NFDiCprRODX23zl5piuxCIOZZc6QnO4jc c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnAFAM5KOVKQ/khM/2dsb2JhbABagweNRrYUFmQJB4JkQD0WGAMCAQIBSw0IAQGHf5kLoQ2UDAOXe4Ywi0SDJjo
X-IronPort-AV: E=Sophos;i="4.90,872,1371081600"; d="scan'208";a="17618734"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 18 Sep 2013 06:46:23 +0000
Received: from [10.61.66.221] (ams3-vpn-dhcp733.cisco.com [10.61.66.221]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8I6kKZT018148 for ; Wed, 18 Sep 2013 06:46:20 GMT
Message-ID: <523936B2.1010202@cisco.com>
Date: Wed, 18 Sep 2013 07:14:26 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "ipfix@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] RFC 7011 - 7015
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 06:46:28 -0000

Dear all,

Congratulations for this major achievement in the IPFIX WG.
Thanks to the editors, authors, contributors, chairs, and the IPFIX WG.

Regards, Benoit (OPS AD)


From paitken@cisco.com  Wed Sep 18 01:27:02 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8203611E81E3 for ; Wed, 18 Sep 2013 01:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZCeVIgYYX+5 for ; Wed, 18 Sep 2013 01:26:57 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4902411E81E0 for ; Wed, 18 Sep 2013 01:26:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=403; q=dns/txt; s=iport; t=1379492817; x=1380702417; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tijqwi8SIkGGUq+Ruz1AxH+47Xg7t8nhAlRLVaUihds=; b=mSKvjqZgYbl/R4QeAbQPU5MVThh8pvmwEFs/kW0CHuQjOfGwJE1q8TlC plSIxshe7IwHa1aN3QRNPKU+n2T/rNuAFETuPKFnkTI6TACU9qLZvIqre Mi3iP3cZf3nMI5LCCVuR1i3Z+5+vPJwll86EbWe7czsw1l9KM5bJ9yIl8 A=;
X-IronPort-AV: E=Sophos;i="4.90,929,1371081600"; d="scan'208";a="159733036"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2013 08:26:56 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8I8QskG010423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Sep 2013 08:26:54 GMT
Received: from [10.61.221.92] ([10.61.221.92]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8I8Qrf8001194; Wed, 18 Sep 2013 09:26:53 +0100 (BST)
Message-ID: <523963CE.10104@cisco.com>
Date: Wed, 18 Sep 2013 09:26:54 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Benoit Claise 
References: <523936B2.1010202@cisco.com>
In-Reply-To: <523936B2.1010202@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "ipfix-ads@tools.ietf.org" , "ipfix@ietf.org" 
Subject: Re: [IPFIX] RFC 7011 - 7015
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 08:27:02 -0000

Thanks to the AD(s) too!

P.


On 18/09/13 06:14, Benoit Claise wrote:
> Dear all,
>
> Congratulations for this major achievement in the IPFIX WG.
> Thanks to the editors, authors, contributors, chairs, and the IPFIX WG.
>
> Regards, Benoit (OPS AD)
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From braun@net.in.tum.de  Thu Sep 19 00:42:15 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A3021F992B for ; Thu, 19 Sep 2013 00:42:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExOV2a70yMsV for ; Thu, 19 Sep 2013 00:42:10 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (smtp1.informatik.tu-muenchen.de [131.159.0.99]) by ietfa.amsl.com (Postfix) with ESMTP id 211C821F969F for ; Thu, 19 Sep 2013 00:42:09 -0700 (PDT)
Received: from willet.net.in.tum.de (willet.net.in.tum.de [131.159.20.24]) by mail.net.in.tum.de (Postfix) with ESMTPSA id AB77819CA8F2; Thu, 19 Sep 2013 09:42:05 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Lothar Braun 
In-Reply-To: <4C0C8370-E6DF-4A67-83DF-F470BB6EC87E@tik.ee.ethz.ch>
Date: Thu, 19 Sep 2013 09:42:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130906103153.12035.82313.idtracker@ietfa.amsl.com> <342399C2-1D8E-4685-B6C2-4A863D0F31AA@tik.ee.ethz.ch>  <4C0C8370-E6DF-4A67-83DF-F470BB6EC87E@tik.ee.ethz.ch>
To: Brian Trammell 
X-Mailer: Apple Mail (2.1508)
Cc: "ipfix@ietf.org Group" 
Subject: Re: [IPFIX] New Version Notification for draft-trammell-ipfix-tcpcontrolbits-revision-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 07:42:15 -0000

On Sep 10, 2013, at 1:11 PM, Brian Trammell  =
wrote:

>=20
> On 10 Sep 2013, at 10:32 , Lothar Braun  wrote:
>=20
>> Hi,
>>=20
>> I have some clarification questions/comments inline (I'm commenting =
on version 02)
>>=20
>>=20
>>>=20
>>>=20
>>> IPFIX Working Group                                          B. =
Trammell
>>> Internet-Draft                                                ETH =
Zurich
>>> Intended status: Informational                                 P. =
Aitken
>>> Expires: March 13, 2014                               Cisco Systems, =
Inc
>>>                                                     September 09, =
2013
>>>=20
>>>=20
>>>       Revision of the tcpControlBits IPFIX Information Element
>>>         draft-trammell-ipfix-tcpcontrolbits-revision-02.txt
>>>=20
>>> Abstract
>>>=20
>>>  This document revises the tcpControlBits IPFIX Information Element
>>>  defined in [RFC5102] to reflect changes to the TCP Flags header =
field
>>>  since [RFC0793].
>>>=20
>>> Status of This Memo
>>>=20
>>>  This Internet-Draft is submitted in full conformance with the
>>>  provisions of BCP 78 and BCP 79.
>>>=20
>>>  Internet-Drafts are working documents of the Internet Engineering
>>>  Task Force (IETF).  Note that other groups may also distribute
>>>  working documents as Internet-Drafts.  The list of current =
Internet-
>>>  Drafts is at http://datatracker.ietf.org/drafts/current/.
>>>=20
>>>  Internet-Drafts are draft documents valid for a maximum of six =
months
>>>  and may be updated, replaced, or obsoleted by other documents at =
any
>>>  time.  It is inappropriate to use Internet-Drafts as reference
>>>  material or to cite them other than as "work in progress."
>>>=20
>>>  This Internet-Draft will expire on March 13, 2014.
>>>=20
>>> Copyright Notice
>>>=20
>>>  Copyright (c) 2013 IETF Trust and the persons identified as the
>>>  document authors.  All rights reserved.
>>>=20
>>>  This document is subject to BCP 78 and the IETF Trust's Legal
>>>  Provisions Relating to IETF Documents
>>>  (http://trustee.ietf.org/license-info) in effect on the date of
>>>  publication of this document.  Please review these documents
>>>  carefully, as they describe your rights and restrictions with =
respect
>>>  to this document.  Code Components extracted from this document =
must
>>>  include Simplified BSD License text as described in Section 4.e of
>>>  the Trust Legal Provisions and are provided without warranty as
>>>  described in the Simplified BSD License.
>>>=20
>>>=20
>>>=20
>>>=20
>>> Trammell & Aitken        Expires March 13, 2014                 =
[Page 1]
>>> Internet-Draft            IPFIX tcpControlBits            September =
2013
>>>=20
>>>=20
>>> 1.  Introduction
>>>=20
>>>  Octets 12 and 13 of the TCP header encode the data offset (header
>>>  length) in four bits, as well as 12 bits of flags.  The least
>>>  significant 6 bits of these were defined in [RFC0793] as URG, ACK,
>>>  PSH, RST, SYN, and FIN for TCP control.  Subsequently, [RFC3168]
>>>  defined the CWR and ECE flags for Explicit Congestion Notification
>>>  (ECN) negotiation and signaling; [RFC3540] additionally defined the
>>>  NS flag for the ECN Nonce Sum.
>>>=20
>>>  As defined in the IANA IPFIX Information Element Registry
>>>  [IANA-IPFIX], taken from [RFC5102], the tcpControlBits Information
>>>  Element for IPFIX [I-D.ietf-ipfix-protocol-rfc5101bis] only covers
>>>  the original six bits from [RFC0793].  To allow IPFIX to be used to
>>>  measure the use of ECN, and to bring the IPFIX Information Element
>>>  definition in line with the current definition of the TCP Flags
>>>  header field, it is necessary to revise this definition.
>>>=20
>>>  The revised definition of the Information Element in Section 2 was
>>>  developed and approved through the IE-DOCTORS process
>>>  [I-D.ietf-ipfix-ie-doctors] in August 2013.  Section 5.1 of
>>>  [I-D.ietf-ipfix-ie-doctors] states "This process should not in any
>>>  way be construed as allowing the IE-DOCTORS to overrule IETF
>>>  consensus.  Specifically, Information Elements in the IANA IE
>>>  registry which were added with IETF consensus require IETF =
consensus
>>>  for revision or deprecation".  Since the tcpControlBits Information
>>>  Element was defined in [RFC5102], an IETF Proposed Standard, any
>>>  revision of this Information Element definition requires IETF
>>>  Consensus.  The publication of this document fulfills that
>>>  requirement.
>>>=20
>>>  The following section defines the revised tcpControlBits =
Information
>>>  Element as in Section 9.1 of [I-D.ietf-ipfix-ie-doctors].
>>>=20
>>> 2.  The tcpControlBits Information Element
>>>=20
>>>  ElementId:   6
>>>  Data Type:   unsigned16
>>>  Data Type Semantics:   flags
>>>  Description:   TCP control bits observed for the packets of this
>>>     Flow.  This information is encoded as a bit field; for each TCP
>>>     control bit, there is a bit in this set.  The bit is set to 1 if
>>>     any observed packet of this Flow has the corresponding TCP =
control
>>>     bit set to 1.  The bit is cleared to 0 otherwise.
>>>=20
>>>     The values of each bit are shown below, per the definition of =
the
>>>     bits in the TCP header [RFC0793]:
>>>=20
>>>=20
>>>=20
>>>=20
>>> Trammell & Aitken        Expires March 13, 2014                 =
[Page 2]
>>> Internet-Draft            IPFIX tcpControlBits            September =
2013
>>>=20
>>>=20
>>>   MSb                                                         LSb
>>>    0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
>>>  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>>>  |               |           | N | C | E | U | A | P | R | S | F |
>>>  |     Zero      |   Future  | S | W | C | R | C | S | S | Y | I |
>>>  | (Data Offset) |    Use    |   | R | E | G | K | H | T | N | N |
>>>  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>>>=20
>>>  bit    flag
>>>  value  name  description
>>>  ------+-----+-------------------------------------
>>>  0x8000       Zero (see tcpHeaderLength)
>>>  0x4000       Zero (see tcpHeaderLength)
>>>  0x2000       Zero (see tcpHeaderLength)
>>>  0x1000       Zero (see tcpHeaderLength)
>>>  0x0800       Future Use
>>>  0x0400       Future Use
>>>  0x0200       Future Use
>>>  0x0100   NS  ECN Nonce Sum
>>>  0x0080  CWR  Congestion Window Reduced
>>>  0x0040  ECE  ECN Echo
>>>  0x0020  URG  Urgent Pointer field significant
>>>  0x0010  ACK  Acknowledgment field significant
>>>  0x0008  PSH  Push Function
>>>  0x0004  RST  Reset the connection
>>>  0x0002  SYN  Synchronize sequence numbers
>>>  0x0001  FIN  No more data from sender
>>>=20
>>>=20
>>>     As the most significant four bits of octets 12 and 13 of the TCP
>>>     header [RFC0793] are used to encode the TCP data offset (header
>>>     length), the corresponding bits in this IE must be exported as
>>>     zero and must be ignored by the collector; use the =
tcpHeaderLength
>>>     Information Element to encode this value.
>>=20
>> Are there good reasons for the two "must" in this sentence?=20
>=20
> Well, we'd really like to enable the following code on the first =
packet (assuming you have an alignment-friendly architecture):
>=20
> tcp_control_bits =3D ntohl((uint16_t *)(tcp_hdr_base + 12)) & 0x0FFF;
>=20
> and the following on subsequent packets:
>=20
> tcp_control_bits |=3D ntohl((uint16_t *)(tcp_hdr_base + 12)) & 0x0FFF

I understand. But a more relaxed definition of the bit values, e.g. not =
defining them, would still give you the possibility to do this.

>> (And shouldn't this be a MUST if this really should be zero?).=20
>=20
> This section doesn't use 2119 language because it's meant to be =
inserted into the registry, where, IIRC, 2119 isn't explicitly in =
effect.

Ok.

>> We could, at some point in the future, decide to use those four bits =
for something else.
>=20
> I'm not sure how you'd get such a proposal past the IE doctors :). The =
other header-field-like IEs in the information model are clearly taken =
from a portion of the packet, so an IE that used the top four bits for =
something else would break that precedent.
>=20
>> This happened for example with the CWR and ECE bits of the previous =
definition that had a requirement to be zero. Later on, it turned out =
that those bits had to be used for encoding something that the original =
definition hadn't thought about.=20
>=20
> Right, but in that case, the bits were reserved for future use in TCP, =
not in IPFIX. The mistake we made in the 5101 revision of this IE is =
referencing 793 only, and not the updates to it. (This is why there's a =
difference between Zero and Future Use in this IE definition).

Point.=20

>> I understand that these four bits are not likely to be used in the =
TCP header length to encode any useful information for flow data, but we =
might decide to use those four bits for encoding other information, e.g. =
some more information about the TCP connection state (or whatever else =
we might think about).=20
>=20
> I'm a big fan of "each IE means one thing", even at the expense of =
efficiency, especially as these IEs are beginning to see use outside =
IPFIX. But it's entirely possible if unlikely that at some point in the =
future we'll reuse these four bits for something else, at which point =
the solution is a matter for the people writing the redefinition, and =
will probably look a lot like what we did for the ECN flag bits.

I can absolutely understand your point. The only thing I'm saying is =
that there is no need to define the value of those four bits. I have no =
plans for using the four bits, but someday there might be someone with =
compelling reasons that convince IE doctors.=20

And if the definition of the IE is then changed again, we need to think =
about whether the change would break existing collectors. An vendor =
could for example decide to implement sanity-checks on the flow records. =
And he could decide to throw away data that does not explicitly comply =
with the definition, e.g. does not set the four bits to zero.

It might be simpler to assign a new meaning to the four bits if there is =
good use for them if they are considered reserved. And there is still =
the IE doctors process to make sure that these bits are not abused =
without good reasons ;)

However, I do not have any plans to use the four bits and therefore no =
strong opinion on the topic. If there is a consensus that the definition =
should discourage the use of the four bits right away, then I'm not =
going to object. =20

>> What I would like to have would be some text that sets the bits to =
reserved and says something like:
>>=20
>> "Bits 0x1000 through 0x.8000 are reserved for future use. A collector =
must not assume to receive information about the TCP header length; the =
field tcpHeaderLength Information Element should be used to encode this =
value."
>>=20
>> What do you think?
>=20
> Again, I'm not sure that I'd want to explicitly encourage such reuse.
>=20
>>=20
>>>     Each of the three future use bits (0x800, 0x400, and 0x200) =
should
>>>     be exported as one if the corresponding bit is observed in the =
TCP
>>>     headers of the packets of this Flow, as they may be subsequent =
to
>>>     a future update of [RFC0793].
>>=20
>> What does "as one" in "exported AS ONE if" mean? Does this mean that =
these bits must be exported as seen in the packet headers?

Can you give me a pointer on this question? (this was the initial reason =
for my previous mail :))


>>>     If exported as a single octet with reduced length encoding,
>>=20
>> Nit: RFC 5101 calls it reduced size encoding (at least most of the =
time ;))
>=20
> Yeah, it turns out I'm the only one who calls it reduced-length. Will =
fix, thanks.
>=20
>>> this
>>>     Information Element covers the low-order octet of this field =
(i.e,
>>>     bits 0x80 to 0x01), omitting the ECN Nonce Sum and the three
>>>     Future Use bits.  A collector receiving this Information Element
>>>     with reduced length encoding must not assume anything about the
>>>     content of these four bits.
>>=20
>> I just wanted to raise this point (without objecting). This would =
clearly be an exception to what I would expect from reduced size =
encoding in RFC 5101bis:
>>=20
>>  The reduction in size can be to any number of
>>  octets smaller than the original type if the data value still fits,
>>  i.e., so that only leading zeroes are dropped.
>>=20
>> Whenever I see reduced size encoding, I assume that there is no =
further information in the field and that all leading bits are zero =
because of this text. But I would assume this is not a hard requirement =
from RFC 5101(bis), and it is probably ok if the data type has an =
explicit definition that states that the first bits are not zero.
>=20
> Well, it could mean two things: the top bits are zero because the =
Nonce Sum bit was never set on any packet in the flow (which, given =
studies on the usage of ECN, and anecdotes about ECN Nonce deployment, I =
would say is the case 99.99...% of the time), or because it was not =
observed (since nobody uses ECN nonce, nobody measures it, either).
>=20
> Perhaps we should state that unsigned16 encoding should ONLY be used =
by EPs connected to MPs which actually know how to measure at least one =
of the bits, so that 0s here won't be interpreted as actual assertions =
of no flag present.


+1=20

- Lothar

--
Lothar Braun
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universit=E4t M=FCnchen
Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany
Phone:  +49 89 289-18010       Fax: +49 89 289-18033
E-mail: braun@net.in.tum.de=20







From wwwrun@rfc-editor.org  Sat Sep 21 13:26:57 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC3C21F9B21 for ; Sat, 21 Sep 2013 13:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.298
X-Spam-Level: 
X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4UMqzoEFJit for ; Sat, 21 Sep 2013 13:26:53 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1D08421F9B08 for ; Sat, 21 Sep 2013 13:26:53 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 9F556B1E00B; Sat, 21 Sep 2013 13:20:13 -0700 (PDT)
To: bclaise@cisco.com, trammell@tik.ee.ethz.ch, paitken@cisco.com, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu
From: RFC Errata System 
Message-Id: <20130921202013.9F556B1E00B@rfc-editor.org>
Date: Sat, 21 Sep 2013 13:20:13 -0700 (PDT)
Cc: bortzmeyer@nic.fr, ipfix@ietf.org, rfc-editor@rfc-editor.org
Subject: [IPFIX] [Editorial Errata Reported] RFC7011 (3732)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 20:26:57 -0000

The following errata report has been submitted for RFC7011,
"Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7011&eid=3732

--------------------------------------
Type: Editorial
Reported by: Stéphane Bortzmeyer 

Section: 1.1

Original Text
-------------
A new Section 5.2 has been added to address wraparound of these
     timestamp data types after they overflow in the years 2032-2038.


Corrected Text
--------------
A new Section 5.2 has been added to address wraparound of these
     timestamp data types after they overflow in the year 2106

Notes
-----
Since dateTimeSeconds is encoded in an _unsigned_ integer, it will wraparound in 2106 (as written correctly in section 5.2), not 2038.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7011 (draft-ietf-ipfix-protocol-rfc5101bis-10)
--------------------------------------
Title               : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information
Publication Date    : September 2013
Author(s)           : B. Claise, Ed., B. Trammell, Ed., P. Aitken
Category            : INTERNET STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

From n.brownlee@auckland.ac.nz  Wed Sep 25 19:44:40 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC34E21F9C37 for ; Wed, 25 Sep 2013 19:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZnuxeTB-ekQ for ; Wed, 25 Sep 2013 19:44:36 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE0511E80FE for ; Wed, 25 Sep 2013 19:44:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380163476; x=1411699476; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=PcausLt0evBO1Fwpe7iPI/NpyotnHTNxcQvLvyZc/34=; b=A5rY7nYs7/H9xlQVbeHlWLKEtHcJCjTZlR/RL06VG/PQ7IFWH7SRNk08 NvotEFSN6jBdBsp1E2/pljEm+HraKUHzf9A+nHSJ6WFkJIwmh5kk3/O7x Xcsz8bSaDJll8lpW1z7DPAd+8xCojFLsiigkQzxWJcNZaWDXU2DpIVgEJ I=;
X-IronPort-AV: E=Sophos;i="4.90,982,1371038400"; d="scan'208";a="214259199"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL
Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 26 Sep 2013 14:44:31 +1200
Message-ID: <52439F8E.8010303@auckland.ac.nz>
Date: Thu, 26 Sep 2013 14:44:30 +1200
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: IPFIX Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] draft-trammell-ipfix-tcpcontrolbits-revision-03.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 02:44:41 -0000

Hi all:

Brian Trammell and Paul Aitken have developed this draft, which will
redefine Information Element 6, tcpControlBits.  Since that was
initially define in RFC 5102, a proposed standard, and change to it
needs IETF consensus.

Benoit Claise has agreed to support this draft as an AD-sponsored
submission to IESG.  I will be it's document shepherd.

Shortly I'll send its write-up to the list, and to IESG.

Cheers, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

From n.brownlee@auckland.ac.nz  Wed Sep 25 20:32:49 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E475721E805D for ; Wed, 25 Sep 2013 20:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdYgGvx2hR0s for ; Wed, 25 Sep 2013 20:32:45 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 14E4021F9C40 for ; Wed, 25 Sep 2013 20:32:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380166362; x=1411702362; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=R2dQpdko+Vgo/xUNDoDgNHo+9MadZdRVAhMUSNdOuaA=; b=KNVq2h0dmBUNPFcJfFVgMh2b39lAo5jBjAv391HPSNeKWGMeIEzSVRkZ ZbwD0Ki2dMuruTdJzY6HVUraGgVXodjoxJtPZBy2kY0WB5S6aodWgwl4f 1hMxeCuYDzY/9AafZUMLXMy5csm7jAMaH9ir9EFzqcmUBqyNzwyvSCwWk M=;
X-IronPort-AV: E=Sophos;i="4.90,982,1371038400"; d="scan'208";a="214271210"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL
Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 26 Sep 2013 15:32:30 +1200
Message-ID: <5243AACD.4050702@auckland.ac.nz>
Date: Thu, 26 Sep 2013 15:32:29 +1200
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Benoit Claise 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Joel Jaeggli , IPFIX Working Group 
Subject: [IPFIX] Write-up for draft-trammell-ipfix-tcpcontrolbits-revision-03.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 03:32:50 -0000

Hi Benoit:

Thanks for agreeing to sponsor the tcpControlBits-revision draft;
here's my write-up for it:

Write-up for:
   draft-trammell-ipfix-tcpcontrolbits-revision-03.txt
   Revision of the tcpControlBits IPFIX Information Element

=== 1. Summary ===

Document shepherd: Nevil Brownlee
Responsible Area Director: Benoit Claise

This document revises the tcpControlBits IPFIX Information Element
defined in RFC 5102 to reflect changes to the TCP Flags header field
since RFC 793.  Since RFC 5102 is a Proposed Standard RFC, a change to
one of its Information Elements requires IETF consensus.

The document is Informational; it provides information to IPFIX
developers who wish to use TCP's ECN-related flag bits.

=== 2. Review and Consensus ===

This draft was written by Brian Trammell and Paul Aitken, both of whom
are IE-Doctors and active IPFIX developers.  Andrew Feren and Lothar
Braun made further contributions to the discussion; in particular
noting that backward compatibility with existing IPFIX collectors must
be maintained.

The draft has been discussed on the IPFIX list since early September;
there is clear consensus for it within the WG.

Brian acknowledges that this work on this is partially supported by
the mPlane project, implying that there is strong interest in it
within mPlane.

=== 3. Intellectual Property ===

There are no IPR disclosures for this draft.  Since it's simply
updating an Information Element to match current - i.e. later than
RFC 793 - Internet Standards, I can't believe anyone could claim
IPR on it!

=== 4. Other Points ===

This document does not have any downward references.

Its IANA Considerations simply ask IANA to change the tcpControlBits
Information Element (IE) in the IE Registry, following the process
described in RFC 7012.  This is a simple, clearly-defined change.

The ID-nits checker complains that some of its references are drafts
that have been published as RFCs; the RFC Editor will fix those.

Overall, I believe that this draft is ready for publication as
an RFC.

Cheers, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

From andrewf@plixer.com  Thu Sep 26 08:29:47 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E6F21F9A49; Thu, 26 Sep 2013 08:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, J_CHICKENPOX_37=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGaMOGwxBA95; Thu, 26 Sep 2013 08:29:33 -0700 (PDT)
Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id 364D621F8319; Thu, 26 Sep 2013 08:29:25 -0700 (PDT)
Received: from [10.8.1.2] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Sep 2013 11:29:19 -0400
Message-ID: <524452C7.3080100@plixer.com>
Date: Thu, 26 Sep 2013 11:29:11 -0400
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: IPFIX Working Group , 
References: 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [IPFIX] NAT logging using IPFIX - Requesting review
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 15:29:47 -0000

Hi Senthil,

On 08/01/2013 09:37 AM, Senthil Sivakumar (ssenthil) wrote:
> I would like the IPFIX WG to review this draft that uses IPFIX to log NAT
> events. 
>
> http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging

I'm a little slow off the blocks on this one, but here is my review of
draft-ietf-behave-ipfix-nat-logging-01.txt.

In Table of Contents "de-allocate" should be "deallocate"
"Acknowledgements" should be "Acknowledgments"

Throughout the draft:  "IE's" is used instead of "IEs"

3.  Scope

 "as stated earlier, this document is not defining IPFIX or NetFlow
v9".  This is the only reference to NetFlow v9 (none earlier or later). 
I would either remove the "or NetFlow v9" or add some more about to the
intended compatibility with NetFlow v9.  Nothing jumped out at me as nto
NetFlow v9 compatible, but there are differences.

I'm not sure that this text...

  "This would mean
   that the NAT device will specify the template that it is going to use
   for each of the events.  The templates can be of varying length and
   there could be multiple templates that a NAT device could use to log
   the events."

belongs in the Scope.  In fact there are various bits of IPFIX specific
advice scattered through the draft.  I would prefer to see this draft
focus exclusively on the IEs needed and example templates.  I would change

   "The implementation details of the collector application is beyond the
   scope of this document."

to something like

   "The implementation details of the collector application and exporter
function is beyond the scope of this document."


5.  Event based logging

I would delete this text

" A NAT device MAY log these events to multiple collectors
   if redundancy is required.  The network administrator will specify
   the collectors to which the log records are to be sent."

and this text

   "Prior to logging any events, the NAT device MUST send the template of
   the record to the collector to advertise the format of the data
   record that it is using to send the events.  The templates can be
   exchanged as frequently as required given the reliability of the
   connection.  There SHOULD be a configurable timer for controlling the
   template refresh.  NAT device SHOULD combine as many events as
   possible in a single packet to effectively utilize the network
   bandwidth."

The above seem out of scope for specifying IEs and templates.


5.2.  Information Elements

timeStamp is used in several places and specified as IE 323.  There
isn't a single IPFIX timeStamp IE, but several depending on your
granularity requirements.  IE 323 is named
"observationTimeMilliseconds".  Also available are:

322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds

I would remove the columns for "Size (bits)" and maybe "Description" and
refer people to
http://www.iana.org/assignments/ipfix.
If you feel you need to keep size it would be more consistent with other
IPFIX documents to specify dataType (eg unsigned64 vs 64 and ipv6Address
vs 128).

If you keep the Description "occured" in the timeStamp Description
should be "occurred"

The IE name for "vlanID" is actually "vlanId"

sourceIPv6Address has the IE in the bits column and bits in the IE column

postNATSourceIPv6Address "addresss" should be "address"

5.3.  Definition of NAT Events

Is this the definition for natEvent(230)?  This doesn't match my
understanding of what is currently defined.

Currently
1 - Create event.
2 - Delete event.
3 - Pool exhausted.

None of these specify NAT44.  My understanding was that these events are
equally applicable to NAT other than just NAT44 and the collector would
infer the type of NAT from the type of addresses being sent.  For
example If the template includes a v6 source and a v4 destination the
Create event is probably for a 64 NAT.

So it isn't clear to me that you need

                   |   NAT64 Session create   |      4 |
                   |   NAT64 Session delete   |      5 |

Also I think

                   |     NAT44 BIB create     |      6 |
                   |     NAT44 BIB delete     |      7 |
                   |     NAT64 BIB create     |      8 |
                   |     NAT64 BIB delete     |      9 |

Can be collapsed to just

4 - BIB create.
5  - BIB BIB create.

The last event, "Port block de-allocation", should be "Port block
deallocation"


5.4.  Quota exceeded - Sub Event types

Maybe I missed something, but I don't see an IE defined to send this
information.


5.5.  Templates for NAT Events

I would drop the size column from the tables in this section too.


5.5.2.  NAT64 create and delete session event

"This event will be generated when a NAT64 session is created.  The
   following is a template of the event."

Should be

   "This event will be generated when a NAT64 session is created or
   deleted.  The template will be the same, the natEvent will indicate
   whether it is a create or a delete event.  The following is a
   template of the event."

I wonder if it is really necessary to duplicate everything between 5.5.1
and 5.5.2 when the only real difference is the address types.  Same
comment for 5.5.3 and 5.5.4.

5.5.3.  NAT44 BIB create and delete event

"This event will be generated when a NAT44 Bind entry is created." 
Needs an "or deleted".


5.5.4.  NAT64 BIB create and delete event

"This event will be generated when a NAT64 Bind entry is created."
Needs an "or deleted".

5.5.5.  Addresses Exhausted event

"wont" should be "won't" in "NAT device wont be able to create"

5.5.6.  Ports Exhausted event

I'm not a NAT/IPv6 expert so I could easily be missing something here,
but is this really only an IPv4 event?


7.  Acknowledgements
should be
7.  Acknowledgments


8.  IANA Considerations

   Currently "There are no IANA considerations for this document."

Should include update of natEvent with additional values and creation of
Quota exceeded - Sub Event.

-Andrew

>
> This is a behave working group draft. Your feedback is greatly appreciated.
>
> Thanks
> Senthil
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From internet-drafts@ietf.org  Mon Sep 30 09:53:28 2013
Return-Path: 
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B861E21F9B65; Mon, 30 Sep 2013 09:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVpwTWxZnogz; Mon, 30 Sep 2013 09:53:28 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F0B21F8E70; Mon, 30 Sep 2013 09:53:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.72
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20130930165328.31558.79351.idtracker@ietfa.amsl.com>
Date: Mon, 30 Sep 2013 09:53:28 -0700
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-04.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Sep 2013 16:53:29 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the IP Flow Information Export Working Group =
of the IETF.

	Title           : Information Elements for Data Link Layer Traffic Measure=
ment
	Author(s)       : Shingo Kashima
                          Atsushi Kobayashi
                          Paul Aitken
	Filename        : draft-ietf-ipfix-data-link-layer-monitoring-04.txt
	Pages           : 33
	Date            : 2013-09-29

Abstract:
   This document describes Information Elements related to data link
   layer.  They are used by the IP Flow Information Export (IPFIX)
   protocol for encoding measured data link layer traffic information.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-data-link-layer-monitor=
ing-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/