From nobody Wed Apr 5 11:17:12 2017 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 7341612941D for ; Wed, 5 Apr 2017 11:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk3WSzTmoB7a for ; Wed, 5 Apr 2017 11:17:06 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E1712940E for ; Wed, 5 Apr 2017 11:17:03 -0700 (PDT) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v35I1sAw023230; Wed, 5 Apr 2017 11:16:51 -0700 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 29jbkyrp95-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 05 Apr 2017 11:16:51 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Apr 2017 12:16:48 -0600 Received: from [10.252.49.3] (10.252.49.3) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Apr 2017 20:16:42 +0200 To: RFC Errata System , , , , , , , , References: <20170330124555.41C72B81373@rfc-editor.org> CC: From: PJ Aitken Message-ID: <8e179988-db1d-3419-3be4-b120ff6eb329@brocade.com> Date: Wed, 5 Apr 2017 19:16:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170330124555.41C72B81373@rfc-editor.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.252.49.3] X-ClientProxiedBy: hq1wp-excas14.corp.brocade.com (10.70.38.103) To EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-05_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704050149 Archived-At: Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 18:17:09 -0000 I should point out that although RFC 5102 has been obsoleted by RFC 7012, 7012 doesn't actually contain any Information Element definitions; it simply points to IANA's IPFIX registry as the normative reference for Element definitions. So the issue doesn't arise in 7012, and I suspect it's not possible to raise an errata against the registry. P. On 30/03/17 13:45, RFC Errata System wrote: > The following errata report has been submitted for RFC5102, > "Information Model for IP Flow Information Export". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata_search.php?rfc=5102&eid=4984 > > -------------------------------------- > Type: Technical > Reported by: Paul Aitken > > Section: 5.2.10, appA > > Original Text > ------------- > Each bit represents an Information Element in the Data Record > with the n-th bit > representing the n-th Information Element. > > Corrected Text > -------------- > Each bit represents an Information Element in the Data Record, > with the n-th least significant bit > representing the n-th Information Element. > > Notes > ----- > A misunderstand arose as to whether bits were assigned in host order or network order - so clarify that the bits are assigned from the least significant to the most significant, ie right-to-left rather than left-to-right. > > Moreover, this clarification applies to IANA's IPFIX registry. > > NB RFC 8038 re-uses this definition for mibIndexIndicator. Consistency between the definitions is desirable. > > Instructions: > ------------- > This erratum 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 > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5102 (draft-ietf-ipfix-info-15) > -------------------------------------- > Title : Information Model for IP Flow Information Export > Publication Date : January 2008 > Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org From nobody Wed Apr 5 12:47:17 2017 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 B78EE129490 for ; Wed, 5 Apr 2017 12:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTvI2ngwQHCY for ; Wed, 5 Apr 2017 12:47:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9591294A5 for ; Wed, 5 Apr 2017 12:47:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 6000) id 08AC5B80E08; Wed, 5 Apr 2017 12:46:46 -0700 (PDT) Date: Wed, 5 Apr 2017 12:46:46 -0700 From: RFC Editor To: IANA , PJ Aitken Cc: quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu, ipfix@ietf.org, RFC Editor Message-ID: <20170405194645.GA8548@rfc-editor.org> References: <20170330124555.41C72B81373@rfc-editor.org> <8e179988-db1d-3419-3be4-b120ff6eb329@brocade.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8e179988-db1d-3419-3be4-b120ff6eb329@brocade.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [IPFIX] potential IANA action - Re: [Technical Errata Reported] RFC5102 (4984) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 19:47:16 -0000 Greetings, Note that we have added IANA to this thread so they are aware of the discussion taking place. Thanks, RFC Editor/sg On Wed, Apr 05, 2017 at 07:16:33PM +0100, PJ Aitken wrote: > I should point out that although RFC 5102 has been obsoleted by RFC 7012, > 7012 doesn't actually contain any Information Element definitions; it simply > points to IANA's IPFIX registry as the normative reference for Element > definitions. > > So the issue doesn't arise in 7012, and I suspect it's not possible to raise > an errata against the registry. > > P. > > > On 30/03/17 13:45, RFC Errata System wrote: > >The following errata report has been submitted for RFC5102, > >"Information Model for IP Flow Information Export". > > > >-------------------------------------- > >You may review the report below and at: > >https://www.rfc-editor.org/errata_search.php?rfc=5102&eid=4984 > > > >-------------------------------------- > >Type: Technical > >Reported by: Paul Aitken > > > >Section: 5.2.10, appA > > > >Original Text > >------------- > >Each bit represents an Information Element in the Data Record > >with the n-th bit > >representing the n-th Information Element. > > > >Corrected Text > >-------------- > >Each bit represents an Information Element in the Data Record, > >with the n-th least significant bit > >representing the n-th Information Element. > > > >Notes > >----- > >A misunderstand arose as to whether bits were assigned in host order or network order - so clarify that the bits are assigned from the least significant to the most significant, ie right-to-left rather than left-to-right. > > > >Moreover, this clarification applies to IANA's IPFIX registry. > > > >NB RFC 8038 re-uses this definition for mibIndexIndicator. Consistency between the definitions is desirable. > > > >Instructions: > >------------- > >This erratum 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 > >can log in to change the status and edit the report, if necessary. > > > >-------------------------------------- > >RFC5102 (draft-ietf-ipfix-info-15) > >-------------------------------------- > >Title : Information Model for IP Flow Information Export > >Publication Date : January 2008 > >Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer > >Category : PROPOSED STANDARD > >Source : IP Flow Information Export > >Area : Operations and Management > >Stream : IETF > >Verifying Party : IESG > > > >_______________________________________________ > >IPFIX mailing list > >IPFIX@ietf.org From nobody Thu Apr 6 02:29:21 2017 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 4DCDB1241FC for ; Thu, 6 Apr 2017 02:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyLZXFGfn5tD for ; Thu, 6 Apr 2017 02:29:18 -0700 (PDT) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F391243FE for ; Thu, 6 Apr 2017 02:29:17 -0700 (PDT) Received: by mail-wr0-x243.google.com with SMTP id u18so1544163wrc.1 for ; Thu, 06 Apr 2017 02:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=3m3EYqwwagW5daCaJXtpRIkGE/rtka/taq9wOUnDwqk=; b=de2MDnrfT4ofVj+rza1tj0AaUSE6pWSsPm+VEacvD1TKr5LmNs8n7mH8XXUrOZN7vH L7b+0bD/uko45dxd443q9pKfuh4VBJb5/j261t3JGHzH4YF9hqgvdzHmMa0acibbHY48 7S/2Ki/NfHsZlUpnL1YQukw6lG7ROf9d3f6L+6mgZdCxRuSEA26Uf2ctXb6ONisS/8+N T9m5TOJ/KJ0Vmwx/I/RHr83SOdqtNpb4ObqT2gGmsWgA8GWKWMkA/s+HQQWCAmZV0pny Gz8lF0wJTIBIGCiacSBhu7rlwoj4PS6dzDM3v7FXR8fTYDD8KYlj48nNkT3Q2ZJ90Tnd csUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3m3EYqwwagW5daCaJXtpRIkGE/rtka/taq9wOUnDwqk=; b=AFIvCvKOmAubwGycztQ17VWr0SKhNy4KDZhNwHiVUv6C6aBy6pc2uWUyr/yH/rqnFc 8LZ8RnsYZ/G8VSQ1WTMQhBVqSXmM8jgP3pcVxjsOMmdWrgTJzwbeDBkMd4eAB50Z5fbM hgL1UkgkbjKVU4OKMUysBXTqJKR2gH2iam9ecWtcqM9ZOn4qp7DT/VPzGeC/GndLUuS9 xTMvl6z9vCxrM+HhPJo9mHK9C6NDhnrJ8jjUmBs6AafyulProcwxUVBkIBoOh5H9pPSu 30CQZnYznx6Lrot4qi0SOE4uYov2PZop4Sc7Slbf+sZmkFeHrHBBzaVZ1X+qaTHfSjS+ v1Pw== X-Gm-Message-State: AFeK/H3SDU2AItztm8d/6O3qj+C8OVyCLE1IzneS/2xd21cBdr5OnadX 1dG5vOAg1QRaaA== X-Received: by 10.28.217.142 with SMTP id q136mr22899454wmg.48.1491470956321; Thu, 06 Apr 2017 02:29:16 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id u63sm1667030wmu.22.2017.04.06.02.29.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 02:29:15 -0700 (PDT) To: PJ Aitken , quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu References: <20170330124555.41C72B81373@rfc-editor.org> <8e179988-db1d-3419-3be4-b120ff6eb329@brocade.com> Cc: ipfix@ietf.org From: Stewart Bryant Message-ID: <481e0cd9-530a-d9ab-d8f3-e02f99f65821@gmail.com> Date: Thu, 6 Apr 2017 10:29:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8e179988-db1d-3419-3be4-b120ff6eb329@brocade.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 09:29:20 -0000 Paul If necessary you could write a one page RFC asking IANA to add a note to the registry. Stewart On 05/04/2017 19:16, PJ Aitken wrote: > I should point out that although RFC 5102 has been obsoleted by RFC > 7012, 7012 doesn't actually contain any Information Element > definitions; it simply points to IANA's IPFIX registry as the > normative reference for Element definitions. > > So the issue doesn't arise in 7012, and I suspect it's not possible to > raise an errata against the registry. > > P. > > > On 30/03/17 13:45, RFC Errata System wrote: >> The following errata report has been submitted for RFC5102, >> "Information Model for IP Flow Information Export". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata_search.php?rfc=5102&eid=4984 >> >> -------------------------------------- >> Type: Technical >> Reported by: Paul Aitken >> >> Section: 5.2.10, appA >> >> Original Text >> ------------- >> Each bit represents an Information Element in the Data Record >> with the n-th bit >> representing the n-th Information Element. >> >> Corrected Text >> -------------- >> Each bit represents an Information Element in the Data Record, >> with the n-th least significant bit >> representing the n-th Information Element. >> >> Notes >> ----- >> A misunderstand arose as to whether bits were assigned in host order >> or network order - so clarify that the bits are assigned from the >> least significant to the most significant, ie right-to-left rather >> than left-to-right. >> >> Moreover, this clarification applies to IANA's IPFIX registry. >> >> NB RFC 8038 re-uses this definition for mibIndexIndicator. >> Consistency between the definitions is desirable. >> >> Instructions: >> ------------- >> This erratum 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 >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5102 (draft-ietf-ipfix-info-15) >> -------------------------------------- >> Title : Information Model for IP Flow Information Export >> Publication Date : January 2008 >> Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. >> Meyer >> Category : PROPOSED STANDARD >> Source : IP Flow Information Export >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Thu Apr 6 02:37:50 2017 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 17A0A1200FC for ; Thu, 6 Apr 2017 02:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTfXGHAEyoyE for ; Thu, 6 Apr 2017 02:37:47 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F1C1201FA for ; Thu, 6 Apr 2017 02:37:47 -0700 (PDT) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v369Yv3A029196; Thu, 6 Apr 2017 02:37:33 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 29ndvs0yqq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 02:37:33 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 03:37:31 -0600 Received: from [10.252.49.3] (10.252.49.3) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 11:37:24 +0200 To: Stewart Bryant , , , , , , , , References: <20170330124555.41C72B81373@rfc-editor.org> <8e179988-db1d-3419-3be4-b120ff6eb329@brocade.com> <481e0cd9-530a-d9ab-d8f3-e02f99f65821@gmail.com> CC: From: PJ Aitken Message-ID: Date: Thu, 6 Apr 2017 10:37:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <481e0cd9-530a-d9ab-d8f3-e02f99f65821@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.252.49.3] X-ClientProxiedBy: hq1wp-excas13.corp.brocade.com (10.70.36.103) To EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-06_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704060075 Archived-At: Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 09:37:49 -0000 That would be possible, though it seems like a lot of effort for the addition of two clarifying words, "least significant" ? P. On 06/04/17 10:29, Stewart Bryant wrote: > Paul > > If necessary you could write a one page RFC asking IANA to add a note > to the registry. > > Stewart > > > On 05/04/2017 19:16, PJ Aitken wrote: >> I should point out that although RFC 5102 has been obsoleted by RFC >> 7012, 7012 doesn't actually contain any Information Element >> definitions; it simply points to IANA's IPFIX registry as the >> normative reference for Element definitions. >> >> So the issue doesn't arise in 7012, and I suspect it's not possible >> to raise an errata against the registry. >> >> P. >> >> >> On 30/03/17 13:45, RFC Errata System wrote: >>> The following errata report has been submitted for RFC5102, >>> "Information Model for IP Flow Information Export". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_errata-5Fsearch.php-3Frfc-3D5102-26eid-3D4984&d=DwIC-g&c=IL_XqQWOjubgfqINi2jTzg&r=l3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU&m=lbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL-6zIIFo8oMo&s=qFdcGTGJe09BgcdUjB6EszW7hMzekalZnfj8wx5JlNw&e= >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Paul Aitken >>> >>> Section: 5.2.10, appA >>> >>> Original Text >>> ------------- >>> Each bit represents an Information Element in the Data Record >>> with the n-th bit >>> representing the n-th Information Element. >>> >>> Corrected Text >>> -------------- >>> Each bit represents an Information Element in the Data Record, >>> with the n-th least significant bit >>> representing the n-th Information Element. >>> >>> Notes >>> ----- >>> A misunderstand arose as to whether bits were assigned in host order >>> or network order - so clarify that the bits are assigned from the >>> least significant to the most significant, ie right-to-left rather >>> than left-to-right. >>> >>> Moreover, this clarification applies to IANA's IPFIX registry. >>> >>> NB RFC 8038 re-uses this definition for mibIndexIndicator. >>> Consistency between the definitions is desirable. >>> >>> Instructions: >>> ------------- >>> This erratum 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 >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC5102 (draft-ietf-ipfix-info-15) >>> -------------------------------------- >>> Title : Information Model for IP Flow Information Export >>> Publication Date : January 2008 >>> Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, >>> J. Meyer >>> Category : PROPOSED STANDARD >>> Source : IP Flow Information Export >>> Area : Operations and Management >>> Stream : IETF >>> Verifying Party : IESG >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIC-g&c=IL_XqQWOjubgfqINi2jTzg&r=l3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU&m=lbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL-6zIIFo8oMo&s=2CAUPZ9aGFiHyUVUtn2cZFp3fcwj4DUALHp38x4XnC8&e= > > From nobody Thu Apr 6 06:23:44 2017 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 177F7129501 for ; Thu, 6 Apr 2017 06:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZjxeVvxChQg for ; Thu, 6 Apr 2017 06:23:37 -0700 (PDT) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731DB1294FE for ; Thu, 6 Apr 2017 06:23:21 -0700 (PDT) Received: from PLXRDC01.plxr.local ([::1]) by PLXRDC01.plxr.local ([::1]) with mapi id 14.03.0301.000; Thu, 6 Apr 2017 09:23:19 -0400 From: Andrew Feren To: PJ Aitken , Stewart Bryant , "quittek@netlab.nec.de" , "stbryant@cisco.com" , "bclaise@cisco.com" , "paitken@cisco.com" , "jemeyer@paypal.com" , "joelja@bogus.com" , "n.brownlee@auckland.ac.nz" , "quittek@neclab.eu" CC: "ipfix@ietf.org" Thread-Topic: [IPFIX] [Technical Errata Reported] RFC5102 (4984) Thread-Index: AQHSqVOjrO3TKoJg50SVG4vGPkynTaG3YemAgAD+/4CAAAJCAP//+WAb Date: Thu, 6 Apr 2017 13:23:19 +0000 Message-ID: <8E7542283B89BB4DB672EB49CEE5AAB7BEC809A1@PLXRDC01.plxr.local> References: <20170330124555.41C72B81373@rfc-editor.org> <8e179988-db1d-3419-3be4-b120ff6eb329@brocade.com> <481e0cd9-530a-d9ab-d8f3-e02f99f65821@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.140.243.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 13:23:43 -0000 What about an errata on 5102 with a note that that the definitions have mov= ed to the registry? Seems like an odd end run, but if it solves the proble= m...=0A= =0A= -Andrew=0A= =0A= ________________________________________=0A= From: IPFIX [ipfix-bounces@ietf.org] on behalf of PJ Aitken [pjaitken@broca= de.com]=0A= Sent: Thursday, April 06, 2017 5:37 AM=0A= To: Stewart Bryant; quittek@netlab.nec.de; stbryant@cisco.com; bclaise@cisc= o.com; paitken@cisco.com; jemeyer@paypal.com; joelja@bogus.com; n.brownlee@= auckland.ac.nz; quittek@neclab.eu=0A= Cc: ipfix@ietf.org=0A= Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984)=0A= =0A= That would be possible, though it seems like a lot of effort for the=0A= addition of two clarifying words, "least significant" ?=0A= =0A= P.=0A= =0A= =0A= On 06/04/17 10:29, Stewart Bryant wrote:=0A= > Paul=0A= >=0A= > If necessary you could write a one page RFC asking IANA to add a note=0A= > to the registry.=0A= >=0A= > Stewart=0A= >=0A= >=0A= > On 05/04/2017 19:16, PJ Aitken wrote:=0A= >> I should point out that although RFC 5102 has been obsoleted by RFC=0A= >> 7012, 7012 doesn't actually contain any Information Element=0A= >> definitions; it simply points to IANA's IPFIX registry as the=0A= >> normative reference for Element definitions.=0A= >>=0A= >> So the issue doesn't arise in 7012, and I suspect it's not possible=0A= >> to raise an errata against the registry.=0A= >>=0A= >> P.=0A= >>=0A= >>=0A= >> On 30/03/17 13:45, RFC Errata System wrote:=0A= >>> The following errata report has been submitted for RFC5102,=0A= >>> "Information Model for IP Flow Information Export".=0A= >>>=0A= >>> --------------------------------------=0A= >>> You may review the report below and at:=0A= >>> https://linkprotect.cudasvc.com/url?a=3Dhttps://urldefense.proofpoint.c= om/v2/url%3fu%3dhttps-3A__www.rfc-2Deditor.org_errata-5Fsearch.php-3Frfc-3D= 5102-26eid-3D4984%26d%3dDwIC-g%26c%3dIL_XqQWOjubgfqINi2jTzg%26r%3dl3qN-NVkU= TPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU%26m%3dlbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL-6= zIIFo8oMo%26s%3dqFdcGTGJe09BgcdUjB6EszW7hMzekalZnfj8wx5JlNw%26e%3d&c=3DE,1,= POSFjbIcmfzya-gNUP5rX4D4UfQQg4AwYC59vms0nF1wQWLNUVnaAiF5ob6Uae9OGK7KJmApL2_= YmgpwUhW4gYwEcADORoaJSQoTSL3CL1vf&typo=3D1=0A= >>>=0A= >>> --------------------------------------=0A= >>> Type: Technical=0A= >>> Reported by: Paul Aitken =0A= >>>=0A= >>> Section: 5.2.10, appA=0A= >>>=0A= >>> Original Text=0A= >>> -------------=0A= >>> Each bit represents an Information Element in the Data Record=0A= >>> with the n-th bit=0A= >>> representing the n-th Information Element.=0A= >>>=0A= >>> Corrected Text=0A= >>> --------------=0A= >>> Each bit represents an Information Element in the Data Record,=0A= >>> with the n-th least significant bit=0A= >>> representing the n-th Information Element.=0A= >>>=0A= >>> Notes=0A= >>> -----=0A= >>> A misunderstand arose as to whether bits were assigned in host order=0A= >>> or network order - so clarify that the bits are assigned from the=0A= >>> least significant to the most significant, ie right-to-left rather=0A= >>> than left-to-right.=0A= >>>=0A= >>> Moreover, this clarification applies to IANA's IPFIX registry.=0A= >>>=0A= >>> NB RFC 8038 re-uses this definition for mibIndexIndicator.=0A= >>> Consistency between the definitions is desirable.=0A= >>>=0A= >>> Instructions:=0A= >>> -------------=0A= >>> This erratum is currently posted as "Reported". If necessary, please=0A= >>> use "Reply All" to discuss whether it should be verified or=0A= >>> rejected. When a decision is reached, the verifying party=0A= >>> can log in to change the status and edit the report, if necessary.=0A= >>>=0A= >>> --------------------------------------=0A= >>> RFC5102 (draft-ietf-ipfix-info-15)=0A= >>> --------------------------------------=0A= >>> Title : Information Model for IP Flow Information Export= =0A= >>> Publication Date : January 2008=0A= >>> Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken,=0A= >>> J. Meyer=0A= >>> Category : PROPOSED STANDARD=0A= >>> Source : IP Flow Information Export=0A= >>> Area : Operations and Management=0A= >>> Stream : IETF=0A= >>> Verifying Party : IESG=0A= >>>=0A= >>> _______________________________________________=0A= >>> IPFIX mailing list=0A= >>> IPFIX@ietf.org=0A= >>=0A= >> _______________________________________________=0A= >> IPFIX mailing list=0A= >> IPFIX@ietf.org=0A= >> https://linkprotect.cudasvc.com/url?a=3Dhttps://urldefense.proofpoint.co= m/v2/url%3fu%3dhttps-3A__www.ietf.org_mailman_listinfo_ipfix%26d%3dDwIC-g%2= 6c%3dIL_XqQWOjubgfqINi2jTzg%26r%3dl3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7J= YU%26m%3dlbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL-6zIIFo8oMo%26s%3d2CAUPZ9aGFiHyUVU= tn2cZFp3fcwj4DUALHp38x4XnC8%26e%3d&c=3DE,1,pcYrfKgiAK5NJHIqb30BLQrXBHi8Lo8-= mgP6pHj3ho1uiEqr0t_tIoUPPm2W5esu67hb-exkoIxDnLvptn6Fk1XN_eXkMZbhZslQnOteFYg= ZtZG7_ZC0ruA,&typo=3D1=0A= >=0A= >=0A= =0A= _______________________________________________=0A= IPFIX mailing list=0A= IPFIX@ietf.org=0A= https://linkprotect.cudasvc.com/url?a=3Dhttps://www.ietf.org/mailman/listin= fo/ipfix&c=3DE,1,usIqknq8V3E9Vc_Br3gQ45teOaNlF3LfzLHNrQfB4rcp1FD80k14Pk3JVl= _c5gVkoOA2yrwp8SRtE_kUr0YLtIlWtEs33OppFfZ7Xp_6PNt-XItuFw,,&typo=3D1=0A= From nobody Thu Apr 6 06:45:14 2017 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 9250D1294FB for ; Thu, 6 Apr 2017 06:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofG4LzjqgNyM for ; Thu, 6 Apr 2017 06:45:09 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180391294F5 for ; Thu, 6 Apr 2017 06:45:09 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id t20so11557919wra.2 for ; Thu, 06 Apr 2017 06:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=+/bBxWgoijxrmW0454YNH0Hgks5LJQ1X2YMGZZI/7XQ=; b=EWoWRdOvk9knUc6/QZy1LgYnXvI09PFwRbUd4Ave4sfhULyLGZ92MC85q20w2d1Lkb SQYhSBd/uDFOkDPFecz1FaTqVUXVvfl0lZaaUz2ebF4JWrUfWTR0Yx7mTalcFgZYPXM5 uVcdNVcMWN3Df1IIKad7cnzvse2pk2F9fE7lxjgfuvHgMaBgNshdhAkS1mBuq6PGejZy nFkbkYfMDoczsf//WEgu+lapt6k5DZb6CeqhMHoRvAc2T50/FVd4yWd0mzpW88yVXQ4s lAzJzK055PlK0jCEZ18MIZDMfV27zP8alN3xylYKFJCrJlRscsKQTpKEWzaV4OjvM7P8 A0RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+/bBxWgoijxrmW0454YNH0Hgks5LJQ1X2YMGZZI/7XQ=; b=cdAPDxCYwNdZeR9Skv+rFKHqm1K0YDesrdzcuCbAzZtNAFyB35HCVXK4lT7i8G/snk Z+jwa8zTxNT9WHkrudpeGxTKC9H1EYxaXzgROm/+v4naihMoXkTi4m3VdBIDF4wjfu1E yUzURQDW9w5CLJaAnQOfbSGe6qs9r8Fs8vqV2Ugs1ox7L5jO+QOfTN6mYJGeSLEZpbTM IwAYrN980xrG/aEUx/MCBTwvX2N40MJkS+jajl0qWa+xPAgTquC8OVJLlPriXmWyCuxq rp3ZesbiwbdyEOEXSjc/nPed/VfeGO+zNHodR/z67Rrw5paTUDFvHqXjgCNO3cqY0yrX MPaw== X-Gm-Message-State: AFeK/H3cg1L3QrtNpyT4onsAM1wJSlE0xuI6OMgopGPgjY7kIDHwTUWhavHWe5VasBvzog== X-Received: by 10.28.232.14 with SMTP id f14mr14556407wmh.106.1491486306771; Thu, 06 Apr 2017 06:45:06 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 32sm2220002wrq.25.2017.04.06.06.45.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 06:45:06 -0700 (PDT) To: Andrew Feren , PJ Aitken , "quittek@netlab.nec.de" , "stbryant@cisco.com" , "bclaise@cisco.com" , "paitken@cisco.com" , "jemeyer@paypal.com" , "joelja@bogus.com" , "n.brownlee@auckland.ac.nz" , "quittek@neclab.eu" References: <20170330124555.41C72B81373@rfc-editor.org> <8e179988-db1d-3419-3be4-b120ff6eb329@brocade.com> <481e0cd9-530a-d9ab-d8f3-e02f99f65821@gmail.com> <8E7542283B89BB4DB672EB49CEE5AAB7BEC809A1@PLXRDC01.plxr.local> Cc: "ipfix@ietf.org" From: Stewart Bryant Message-ID: <2c308d8c-a6b8-69da-2385-34cdaae46f1d@gmail.com> Date: Thu, 6 Apr 2017 14:45:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8E7542283B89BB4DB672EB49CEE5AAB7BEC809A1@PLXRDC01.plxr.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 13:45:13 -0000 It depends on what IANA think, but it's only about an hour to write and the reviews will all go though on the nod. Of course as an AD Benoit may just be able to direct that that this obvious correction happens. Stewart On 06/04/2017 14:23, Andrew Feren wrote: > What about an errata on 5102 with a note that that the definitions have moved to the registry? Seems like an odd end run, but if it solves the problem... > > -Andrew > > ________________________________________ > From: IPFIX [ipfix-bounces@ietf.org] on behalf of PJ Aitken [pjaitken@brocade.com] > Sent: Thursday, April 06, 2017 5:37 AM > To: Stewart Bryant; quittek@netlab.nec.de; stbryant@cisco.com; bclaise@cisco.com; paitken@cisco.com; jemeyer@paypal.com; joelja@bogus.com; n.brownlee@auckland.ac.nz; quittek@neclab.eu > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) > > That would be possible, though it seems like a lot of effort for the > addition of two clarifying words, "least significant" ? > > P. > > > On 06/04/17 10:29, Stewart Bryant wrote: >> Paul >> >> If necessary you could write a one page RFC asking IANA to add a note >> to the registry. >> >> Stewart >> >> >> On 05/04/2017 19:16, PJ Aitken wrote: >>> I should point out that although RFC 5102 has been obsoleted by RFC >>> 7012, 7012 doesn't actually contain any Information Element >>> definitions; it simply points to IANA's IPFIX registry as the >>> normative reference for Element definitions. >>> >>> So the issue doesn't arise in 7012, and I suspect it's not possible >>> to raise an errata against the registry. >>> >>> P. >>> >>> >>> On 30/03/17 13:45, RFC Errata System wrote: >>>> The following errata report has been submitted for RFC5102, >>>> "Information Model for IP Flow Information Export". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> https://linkprotect.cudasvc.com/url?a=https://urldefense.proofpoint.com/v2/url%3fu%3dhttps-3A__www.rfc-2Deditor.org_errata-5Fsearch.php-3Frfc-3D5102-26eid-3D4984%26d%3dDwIC-g%26c%3dIL_XqQWOjubgfqINi2jTzg%26r%3dl3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU%26m%3dlbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL-6zIIFo8oMo%26s%3dqFdcGTGJe09BgcdUjB6EszW7hMzekalZnfj8wx5JlNw%26e%3d&c=E,1,POSFjbIcmfzya-gNUP5rX4D4UfQQg4AwYC59vms0nF1wQWLNUVnaAiF5ob6Uae9OGK7KJmApL2_YmgpwUhW4gYwEcADORoaJSQoTSL3CL1vf&typo=1 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Paul Aitken >>>> >>>> Section: 5.2.10, appA >>>> >>>> Original Text >>>> ------------- >>>> Each bit represents an Information Element in the Data Record >>>> with the n-th bit >>>> representing the n-th Information Element. >>>> >>>> Corrected Text >>>> -------------- >>>> Each bit represents an Information Element in the Data Record, >>>> with the n-th least significant bit >>>> representing the n-th Information Element. >>>> >>>> Notes >>>> ----- >>>> A misunderstand arose as to whether bits were assigned in host order >>>> or network order - so clarify that the bits are assigned from the >>>> least significant to the most significant, ie right-to-left rather >>>> than left-to-right. >>>> >>>> Moreover, this clarification applies to IANA's IPFIX registry. >>>> >>>> NB RFC 8038 re-uses this definition for mibIndexIndicator. >>>> Consistency between the definitions is desirable. >>>> >>>> Instructions: >>>> ------------- >>>> This erratum 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 >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC5102 (draft-ietf-ipfix-info-15) >>>> -------------------------------------- >>>> Title : Information Model for IP Flow Information Export >>>> Publication Date : January 2008 >>>> Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, >>>> J. Meyer >>>> Category : PROPOSED STANDARD >>>> Source : IP Flow Information Export >>>> Area : Operations and Management >>>> Stream : IETF >>>> Verifying Party : IESG >>>> >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://linkprotect.cudasvc.com/url?a=https://urldefense.proofpoint.com/v2/url%3fu%3dhttps-3A__www.ietf.org_mailman_listinfo_ipfix%26d%3dDwIC-g%26c%3dIL_XqQWOjubgfqINi2jTzg%26r%3dl3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU%26m%3dlbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL-6zIIFo8oMo%26s%3d2CAUPZ9aGFiHyUVUtn2cZFp3fcwj4DUALHp38x4XnC8%26e%3d&c=E,1,pcYrfKgiAK5NJHIqb30BLQrXBHi8Lo8-mgP6pHj3ho1uiEqr0t_tIoUPPm2W5esu67hb-exkoIxDnLvptn6Fk1XN_eXkMZbhZslQnOteFYgZtZG7_ZC0ruA,&typo=1 >> > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://linkprotect.cudasvc.com/url?a=https://www.ietf.org/mailman/listinfo/ipfix&c=E,1,usIqknq8V3E9Vc_Br3gQ45teOaNlF3LfzLHNrQfB4rcp1FD80k14Pk3JVl_c5gVkoOA2yrwp8SRtE_kUr0YLtIlWtEs33OppFfZ7Xp_6PNt-XItuFw,,&typo=1 From nobody Tue Apr 18 08:02:12 2017 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 BC7DA12EC4D for ; Tue, 18 Apr 2017 08:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dXc6uvOYpO5 for ; Tue, 18 Apr 2017 08:02:03 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4B212EABC for ; Tue, 18 Apr 2017 08:02:01 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 73E72340EBA; Tue, 18 Apr 2017 17:02:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.15741); Tue, 18 Apr 2017 17:01:57 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Tue, 18 Apr 2017 17:01:57 +0200 (CEST) Received: from [195.176.111.18] (account ietf@trammell.ch HELO public-docking-cx-1617.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 14859754; Tue, 18 Apr 2017 17:01:57 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E19A3EF6-02C4-4ECD-B6CF-17CCA49DFE3D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: <2c308d8c-a6b8-69da-2385-34cdaae46f1d@gmail.com> Date: Tue, 18 Apr 2017 17:01:56 +0200 Cc: Andrew Feren , PJ Aitken , "quittek@netlab.nec.de" , "stbryant@cisco.com" , Benoit Claise , "paitken@cisco.com" , "jemeyer@paypal.com" , "joelja@bogus.com" , Nevil Brownlee , "quittek@neclab.eu" , "ipfix@ietf.org" Message-Id: <8C5CFB60-F33B-4346-94EF-B8D5F33E6A96@trammell.ch> References: <20170330124555.41C72B81373@rfc-editor.org> <8e179988-db1d-3419-3be4-b120ff6eb329@brocade.com> <481e0cd9-530a-d9ab-d8f3-e02f99f65821@gmail.com> <8E7542283B89BB4DB672EB49CEE5AAB7BEC809A1@PLXRDC01.plxr.local> <2c308d8c-a6b8-69da-2385-34cdaae46f1d@gmail.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:02:11 -0000 --Apple-Mail=_E19A3EF6-02C4-4ECD-B6CF-17CCA49DFE3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, all, You can't raise an erratum against the registry, but 7013 provides for = interoperable revisions to Information Elements to correct errors = (section 5.2 criterion 2 holds). Cheers, Brian > On 06 Apr 2017, at 15:45, Stewart Bryant = wrote: >=20 > It depends on what IANA think, but it's only about an hour to write = and the reviews will all go though on the nod. >=20 > Of course as an AD Benoit may just be able to direct that that this = obvious correction happens. >=20 > Stewart >=20 >=20 > On 06/04/2017 14:23, Andrew Feren wrote: >> What about an errata on 5102 with a note that that the definitions = have moved to the registry? Seems like an odd end run, but if it solves = the problem... >>=20 >> -Andrew >>=20 >> ________________________________________ >> From: IPFIX [ipfix-bounces@ietf.org] on behalf of PJ Aitken = [pjaitken@brocade.com] >> Sent: Thursday, April 06, 2017 5:37 AM >> To: Stewart Bryant; quittek@netlab.nec.de; stbryant@cisco.com; = bclaise@cisco.com; paitken@cisco.com; jemeyer@paypal.com; = joelja@bogus.com; n.brownlee@auckland.ac.nz; quittek@neclab.eu >> Cc: ipfix@ietf.org >> Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) >>=20 >> That would be possible, though it seems like a lot of effort for the >> addition of two clarifying words, "least significant" ? >>=20 >> P. >>=20 >>=20 >> On 06/04/17 10:29, Stewart Bryant wrote: >>> Paul >>>=20 >>> If necessary you could write a one page RFC asking IANA to add a = note >>> to the registry. >>>=20 >>> Stewart >>>=20 >>>=20 >>> On 05/04/2017 19:16, PJ Aitken wrote: >>>> I should point out that although RFC 5102 has been obsoleted by RFC >>>> 7012, 7012 doesn't actually contain any Information Element >>>> definitions; it simply points to IANA's IPFIX registry as the >>>> normative reference for Element definitions. >>>>=20 >>>> So the issue doesn't arise in 7012, and I suspect it's not possible >>>> to raise an errata against the registry. >>>>=20 >>>> P. >>>>=20 >>>>=20 >>>> On 30/03/17 13:45, RFC Errata System wrote: >>>>> The following errata report has been submitted for RFC5102, >>>>> "Information Model for IP Flow Information Export". >>>>>=20 >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> = https://linkprotect.cudasvc.com/url?a=3Dhttps://urldefense.proofpoint.com/= v2/url%3fu%3dhttps-3A__www.rfc-2Deditor.org_errata-5Fsearch.php-3Frfc-3D51= 02-26eid-3D4984%26d%3dDwIC-g%26c%3dIL_XqQWOjubgfqINi2jTzg%26r%3dl3qN-NVkUT= PhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU%26m%3dlbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL-6= zIIFo8oMo%26s%3dqFdcGTGJe09BgcdUjB6EszW7hMzekalZnfj8wx5JlNw%26e%3d&c=3DE,1= ,POSFjbIcmfzya-gNUP5rX4D4UfQQg4AwYC59vms0nF1wQWLNUVnaAiF5ob6Uae9OGK7KJmApL= 2_YmgpwUhW4gYwEcADORoaJSQoTSL3CL1vf&typo=3D1 >>>>>=20 >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: Paul Aitken >>>>>=20 >>>>> Section: 5.2.10, appA >>>>>=20 >>>>> Original Text >>>>> ------------- >>>>> Each bit represents an Information Element in the Data Record >>>>> with the n-th bit >>>>> representing the n-th Information Element. >>>>>=20 >>>>> Corrected Text >>>>> -------------- >>>>> Each bit represents an Information Element in the Data Record, >>>>> with the n-th least significant bit >>>>> representing the n-th Information Element. >>>>>=20 >>>>> Notes >>>>> ----- >>>>> A misunderstand arose as to whether bits were assigned in host = order >>>>> or network order - so clarify that the bits are assigned from the >>>>> least significant to the most significant, ie right-to-left rather >>>>> than left-to-right. >>>>>=20 >>>>> Moreover, this clarification applies to IANA's IPFIX registry. >>>>>=20 >>>>> NB RFC 8038 re-uses this definition for mibIndexIndicator. >>>>> Consistency between the definitions is desirable. >>>>>=20 >>>>> Instructions: >>>>> ------------- >>>>> This erratum 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 >>>>> can log in to change the status and edit the report, if necessary. >>>>>=20 >>>>> -------------------------------------- >>>>> RFC5102 (draft-ietf-ipfix-info-15) >>>>> -------------------------------------- >>>>> Title : Information Model for IP Flow Information = Export >>>>> Publication Date : January 2008 >>>>> Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, >>>>> J. Meyer >>>>> Category : PROPOSED STANDARD >>>>> Source : IP Flow Information Export >>>>> Area : Operations and Management >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>>>=20 >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> = https://linkprotect.cudasvc.com/url?a=3Dhttps://urldefense.proofpoint.com/= v2/url%3fu%3dhttps-3A__www.ietf.org_mailman_listinfo_ipfix%26d%3dDwIC-g%26= c%3dIL_XqQWOjubgfqINi2jTzg%26r%3dl3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7J= YU%26m%3dlbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL-6zIIFo8oMo%26s%3d2CAUPZ9aGFiHyUV= Utn2cZFp3fcwj4DUALHp38x4XnC8%26e%3d&c=3DE,1,pcYrfKgiAK5NJHIqb30BLQrXBHi8Lo= 8-mgP6pHj3ho1uiEqr0t_tIoUPPm2W5esu67hb-exkoIxDnLvptn6Fk1XN_eXkMZbhZslQnOte= FYgZtZG7_ZC0ruA,&typo=3D1 >>>=20 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> = https://linkprotect.cudasvc.com/url?a=3Dhttps://www.ietf.org/mailman/listi= nfo/ipfix&c=3DE,1,usIqknq8V3E9Vc_Br3gQ45teOaNlF3LfzLHNrQfB4rcp1FD80k14Pk3J= Vl_c5gVkoOA2yrwp8SRtE_kUr0YLtIlWtEs33OppFfZ7Xp_6PNt-XItuFw,,&typo=3D1 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_E19A3EF6-02C4-4ECD-B6CF-17CCA49DFE3D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9ipkAAoJEIoSt78L6kaj+sQQAL1uHKSnypHiclkJ8NQm94lx dSVAC/cp9Vl+AmXFJl8JsKQw4826ysMoEG+xLSLF5+0iaPfLd4Yn+Ggh1Zmig7dS HzfGwW8jWZzKGJYyoXef04D/n0xQhzbU1/ss9lO/J8AkgqfNHmkOsBFO++5UKGXu hoN9Zt2ad+4JrTM70u9G2XbJkg6vMqjQRhjDRmHo/2WqkDThBfhxWatrW1EC4mt5 zWLYRiPPhvr62OkX/k8HohFS2zQvHFizLxpo8JcQ5qnqOj4H6rIVSv2DrQa/WMJs duw+f9HZWEIOyvSzc0KiXf1nS9DIC7p00jF5KWh27K2NwtBYeUiyRfOX/IZ/xzbm 4/ZRDB3zS7+ZwED8O1nItiRu3DcuAoP9KuqDQ5q3DHHdH6mhPL9FNDqpanJ5QAzV QkbWZG5lkEo+W6UzrPqUuN5ZG1G0zXhp5RY5XOZrQY2Q8WqmOgPmGGxKpuXL6FUl g31J4hwctbStv5Sv1MQeboDhY+tOy3alWavW8lJKPo5fLibzK3UhPjRj/VMYo/9g xs3Td960GtfswJgFDsUo3bUm9E6wSlWF7C+stdbp7g0NWx2/TsD7Y/7/+uI8dTfG 3fpV3jfL4XKIGZJRxwzDFQErfUgOcK7u+PMbNaPlNjRtVc9xkUMaVvR//J+b/THw mvbBcTbgqRg+Y8cTYzFW =uSUs -----END PGP SIGNATURE----- --Apple-Mail=_E19A3EF6-02C4-4ECD-B6CF-17CCA49DFE3D-- From nobody Wed Apr 19 07:55:38 2017 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 59DC5129AE5 for ; Wed, 19 Apr 2017 07:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tHTXNp1Eyky for ; Wed, 19 Apr 2017 07:55:35 -0700 (PDT) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01245129AD3 for ; Wed, 19 Apr 2017 07:55:29 -0700 (PDT) Received: from PLXRDC01.plxr.local ([::1]) by PLXRDC01.plxr.local ([::1]) with mapi id 14.03.0301.000; Wed, 19 Apr 2017 10:55:28 -0400 From: Andrew Feren To: "Brian Trammell (IETF)" , Stewart Bryant CC: PJ Aitken , "quittek@netlab.nec.de" , "stbryant@cisco.com" , "Benoit Claise" , "paitken@cisco.com" , "jemeyer@paypal.com" , "joelja@bogus.com" , Nevil Brownlee , "quittek@neclab.eu" , "ipfix@ietf.org" Thread-Topic: [IPFIX] [Technical Errata Reported] RFC5102 (4984) Thread-Index: AQHSqVOjrO3TKoJg50SVG4vGPkynTaG3YemAgAD+/4CAAAJCAP//+WAbgABL2gCAEvFzAIABSruc Date: Wed, 19 Apr 2017 14:55:27 +0000 Message-ID: <8E7542283B89BB4DB672EB49CEE5AAB7BEC89758@PLXRDC01.plxr.local> References: <20170330124555.41C72B81373@rfc-editor.org> <8e179988-db1d-3419-3be4-b120ff6eb329@brocade.com> <481e0cd9-530a-d9ab-d8f3-e02f99f65821@gmail.com> <8E7542283B89BB4DB672EB49CEE5AAB7BEC809A1@PLXRDC01.plxr.local> <2c308d8c-a6b8-69da-2385-34cdaae46f1d@gmail.com>, <8C5CFB60-F33B-4346-94EF-B8D5F33E6A96@trammell.ch> In-Reply-To: <8C5CFB60-F33B-4346-94EF-B8D5F33E6A96@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.140.243.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 14:55:37 -0000 So we've established that the change can be be made with or with out the er= rata. =0A= =0A= I'm in favor of making the clarifying change to the registry as proposed in= the errata.=0A= =0A= I don't have a strong opinion on the approval or not of the errata on 5102,= but it it probably doesn't hurt to approve it if only as documentation of = what was changed and why.=0A= =0A= -Andrew=0A= =0A= ________________________________________=0A= From: Brian Trammell (IETF) [ietf@trammell.ch]=0A= Sent: Tuesday, April 18, 2017 11:01 AM=0A= To: Stewart Bryant=0A= Cc: Andrew Feren; PJ Aitken; quittek@netlab.nec.de; stbryant@cisco.com; Ben= oit Claise; paitken@cisco.com; jemeyer@paypal.com; joelja@bogus.com; Nevil = Brownlee; quittek@neclab.eu; ipfix@ietf.org=0A= Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984)=0A= =0A= Hi, all,=0A= =0A= You can't raise an erratum against the registry, but 7013 provides for inte= roperable revisions to Information Elements to correct errors (section 5.2 = criterion 2 holds).=0A= =0A= Cheers,=0A= =0A= Brian=0A= =0A= =0A= > On 06 Apr 2017, at 15:45, Stewart Bryant wrote= :=0A= >=0A= > It depends on what IANA think, but it's only about an hour to write and t= he reviews will all go though on the nod.=0A= >=0A= > Of course as an AD Benoit may just be able to direct that that this obvio= us correction happens.=0A= >=0A= > Stewart=0A= >=0A= >=0A= > On 06/04/2017 14:23, Andrew Feren wrote:=0A= >> What about an errata on 5102 with a note that that the definitions have = moved to the registry? Seems like an odd end run, but if it solves the pro= blem...=0A= >>=0A= >> -Andrew=0A= >>=0A= >> ________________________________________=0A= >> From: IPFIX [ipfix-bounces@ietf.org] on behalf of PJ Aitken [pjaitken@br= ocade.com]=0A= >> Sent: Thursday, April 06, 2017 5:37 AM=0A= >> To: Stewart Bryant; quittek@netlab.nec.de; stbryant@cisco.com; bclaise@c= isco.com; paitken@cisco.com; jemeyer@paypal.com; joelja@bogus.com; n.brownl= ee@auckland.ac.nz; quittek@neclab.eu=0A= >> Cc: ipfix@ietf.org=0A= >> Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984)=0A= >>=0A= >> That would be possible, though it seems like a lot of effort for the=0A= >> addition of two clarifying words, "least significant" ?=0A= >>=0A= >> P.=0A= >>=0A= >>=0A= >> On 06/04/17 10:29, Stewart Bryant wrote:=0A= >>> Paul=0A= >>>=0A= >>> If necessary you could write a one page RFC asking IANA to add a note= =0A= >>> to the registry.=0A= >>>=0A= >>> Stewart=0A= >>>=0A= >>>=0A= >>> On 05/04/2017 19:16, PJ Aitken wrote:=0A= >>>> I should point out that although RFC 5102 has been obsoleted by RFC=0A= >>>> 7012, 7012 doesn't actually contain any Information Element=0A= >>>> definitions; it simply points to IANA's IPFIX registry as the=0A= >>>> normative reference for Element definitions.=0A= >>>>=0A= >>>> So the issue doesn't arise in 7012, and I suspect it's not possible=0A= >>>> to raise an errata against the registry.=0A= >>>>=0A= >>>> P.=0A= >>>>=0A= >>>>=0A= >>>> On 30/03/17 13:45, RFC Errata System wrote:=0A= >>>>> The following errata report has been submitted for RFC5102,=0A= >>>>> "Information Model for IP Flow Information Export".=0A= >>>>>=0A= >>>>> --------------------------------------=0A= >>>>> You may review the report below and at:=0A= >>>>> https://linkprotect.cudasvc.com/url?a=3Dhttps://urldefense.proofpoint= .com/v2/url%3fu%3dhttps-3A__www.rfc-2Deditor.org_errata-5Fsearch.php-3Frfc-= 3D5102-26eid-3D4984%26d%3dDwIC-g%26c%3dIL_XqQWOjubgfqINi2jTzg%26r%3dl3qN-NV= kUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU%26m%3dlbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL= -6zIIFo8oMo%26s%3dqFdcGTGJe09BgcdUjB6EszW7hMzekalZnfj8wx5JlNw%26e%3d&c=3DE,= 1,POSFjbIcmfzya-gNUP5rX4D4UfQQg4AwYC59vms0nF1wQWLNUVnaAiF5ob6Uae9OGK7KJmApL= 2_YmgpwUhW4gYwEcADORoaJSQoTSL3CL1vf&typo=3D1=0A= >>>>>=0A= >>>>> --------------------------------------=0A= >>>>> Type: Technical=0A= >>>>> Reported by: Paul Aitken =0A= >>>>>=0A= >>>>> Section: 5.2.10, appA=0A= >>>>>=0A= >>>>> Original Text=0A= >>>>> -------------=0A= >>>>> Each bit represents an Information Element in the Data Record=0A= >>>>> with the n-th bit=0A= >>>>> representing the n-th Information Element.=0A= >>>>>=0A= >>>>> Corrected Text=0A= >>>>> --------------=0A= >>>>> Each bit represents an Information Element in the Data Record,=0A= >>>>> with the n-th least significant bit=0A= >>>>> representing the n-th Information Element.=0A= >>>>>=0A= >>>>> Notes=0A= >>>>> -----=0A= >>>>> A misunderstand arose as to whether bits were assigned in host order= =0A= >>>>> or network order - so clarify that the bits are assigned from the=0A= >>>>> least significant to the most significant, ie right-to-left rather=0A= >>>>> than left-to-right.=0A= >>>>>=0A= >>>>> Moreover, this clarification applies to IANA's IPFIX registry.=0A= >>>>>=0A= >>>>> NB RFC 8038 re-uses this definition for mibIndexIndicator.=0A= >>>>> Consistency between the definitions is desirable.=0A= >>>>>=0A= >>>>> Instructions:=0A= >>>>> -------------=0A= >>>>> This erratum is currently posted as "Reported". If necessary, please= =0A= >>>>> use "Reply All" to discuss whether it should be verified or=0A= >>>>> rejected. When a decision is reached, the verifying party=0A= >>>>> can log in to change the status and edit the report, if necessary.=0A= >>>>>=0A= >>>>> --------------------------------------=0A= >>>>> RFC5102 (draft-ietf-ipfix-info-15)=0A= >>>>> --------------------------------------=0A= >>>>> Title : Information Model for IP Flow Information Expor= t=0A= >>>>> Publication Date : January 2008=0A= >>>>> Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken,=0A= >>>>> J. Meyer=0A= >>>>> Category : PROPOSED STANDARD=0A= >>>>> Source : IP Flow Information Export=0A= >>>>> Area : Operations and Management=0A= >>>>> Stream : IETF=0A= >>>>> Verifying Party : IESG=0A= >>>>>=0A= >>>>> _______________________________________________=0A= >>>>> IPFIX mailing list=0A= >>>>> IPFIX@ietf.org=0A= >>>> _______________________________________________=0A= >>>> IPFIX mailing list=0A= >>>> IPFIX@ietf.org=0A= >>>> https://linkprotect.cudasvc.com/url?a=3Dhttps://urldefense.proofpoint.= com/v2/url%3fu%3dhttps-3A__www.ietf.org_mailman_listinfo_ipfix%26d%3dDwIC-g= %26c%3dIL_XqQWOjubgfqINi2jTzg%26r%3dl3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E= 7JYU%26m%3dlbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL-6zIIFo8oMo%26s%3d2CAUPZ9aGFiHyU= VUtn2cZFp3fcwj4DUALHp38x4XnC8%26e%3d&c=3DE,1,pcYrfKgiAK5NJHIqb30BLQrXBHi8Lo= 8-mgP6pHj3ho1uiEqr0t_tIoUPPm2W5esu67hb-exkoIxDnLvptn6Fk1XN_eXkMZbhZslQnOteF= YgZtZG7_ZC0ruA,&typo=3D1=0A= >>>=0A= >> _______________________________________________=0A= >> IPFIX mailing list=0A= >> IPFIX@ietf.org=0A= >> https://linkprotect.cudasvc.com/url?a=3Dhttps://www.ietf.org/mailman/lis= tinfo/ipfix&c=3DE,1,usIqknq8V3E9Vc_Br3gQ45teOaNlF3LfzLHNrQfB4rcp1FD80k14Pk3= JVl_c5gVkoOA2yrwp8SRtE_kUr0YLtIlWtEs33OppFfZ7Xp_6PNt-XItuFw,,&typo=3D1=0A= >=0A= > _______________________________________________=0A= > IPFIX mailing list=0A= > IPFIX@ietf.org=0A= > https://linkprotect.cudasvc.com/url?a=3Dhttps://www.ietf.org/mailman/list= info/ipfix&c=3DE,1,IYiyIN8296ZqBksTqvPeG0yzfRibAepQVoWtFsOwyWr9lG1Dbwrx1zu9= eNVR7xKSQTQDqLnNQ7pTuXebyClfH884sMP3JzeBw-pbvsSnSedE0uaUlu0H&typo=3D1=0A= =0A= From nobody Wed Apr 19 08:51:47 2017 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 CED62129B10 for ; Wed, 19 Apr 2017 08:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.532 X-Spam-Level: X-Spam-Status: No, score=-12.532 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P70FOFWCFDX for ; Wed, 19 Apr 2017 08:51:41 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F268129B1B for ; Wed, 19 Apr 2017 08:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24146; q=dns/txt; s=iport; t=1492617097; x=1493826697; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=BMZwZWKr9SeORtR7zeGJgGAFsyYIqFOwHyNg9NGX3QI=; b=eNI0tDq5AJF35O0NGH2ehPPLTbDM+jAZuUzDLvF5VfSBL7BIS5NXDGGp /gJGGQNoCA0p4IxLBasB/2tKRzjeYerOKZB/Sa1bA9U6ToI2mPtW7sEe2 vTc/mTJgdXpqRo4wIc8qGKJSMa2fPOiaIC9A19MzGq0iIf6Ewc26yrzn8 c=; X-IronPort-AV: E=Sophos;i="5.37,221,1488844800"; d="scan'208,217";a="651260153" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 15:51:35 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3JFpYdx026902; Wed, 19 Apr 2017 15:51:34 GMT To: Andrew Feren , "Brian Trammell (IETF)" , Stewart Bryant References: <20170330124555.41C72B81373@rfc-editor.org> <8e179988-db1d-3419-3be4-b120ff6eb329@brocade.com> <481e0cd9-530a-d9ab-d8f3-e02f99f65821@gmail.com> <8E7542283B89BB4DB672EB49CEE5AAB7BEC809A1@PLXRDC01.plxr.local> <2c308d8c-a6b8-69da-2385-34cdaae46f1d@gmail.com> <8C5CFB60-F33B-4346-94EF-B8D5F33E6A96@trammell.ch> <8E7542283B89BB4DB672EB49CEE5AAB7BEC89758@PLXRDC01.plxr.local> Cc: PJ Aitken , "quittek@netlab.nec.de" , "stbryant@cisco.com" , "paitken@cisco.com" , "jemeyer@paypal.com" , "joelja@bogus.com" , Nevil Brownlee , "quittek@neclab.eu" , "ipfix@ietf.org" From: Benoit Claise Message-ID: <085717f3-cd4b-3b51-9de9-46b84766a044@cisco.com> Date: Wed, 19 Apr 2017 17:51:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8E7542283B89BB4DB672EB49CEE5AAB7BEC89758@PLXRDC01.plxr.local> Content-Type: multipart/alternative; boundary="------------E15AAC92AFCF5DDCF370D406" Archived-At: Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 15:51:44 -0000 This is a multi-part message in MIME format. --------------E15AAC92AFCF5DDCF370D406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, As Brian mentioned, RFC 7013 section 5.2 applies here: 2. it corrects an ambiguity in the Information Element's definition, which itself leads to non-interoperability severe enough to prevent the Information Element's usage as originally defined (e.g., a prior change to ipv6ExtensionHeaders); or Paul, as errata 4984 owner, can you please drop a note to IANA with the new definition. Let's not forgot to bump the revision number by one, as mentioned in RFC7013 section 5.2. Once done, even if it's not necessary, I'll accept the errata 4984. There is no harm and it would be easier for a RFC 5102 reader, assuming someone would read this obsolete RFC (instead of the RFC 7102 that points to IANA) Regards, Benoit > So we've established that the change can be be made with or with out the errata. > > I'm in favor of making the clarifying change to the registry as proposed in the errata. > > I don't have a strong opinion on the approval or not of the errata on 5102, but it it probably doesn't hurt to approve it if only as documentation of what was changed and why. > > -Andrew > > ________________________________________ > From: Brian Trammell (IETF) [ietf@trammell.ch] > Sent: Tuesday, April 18, 2017 11:01 AM > To: Stewart Bryant > Cc: Andrew Feren; PJ Aitken; quittek@netlab.nec.de; stbryant@cisco.com; Benoit Claise; paitken@cisco.com; jemeyer@paypal.com; joelja@bogus.com; Nevil Brownlee; quittek@neclab.eu; ipfix@ietf.org > Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) > > Hi, all, > > You can't raise an erratum against the registry, but 7013 provides for interoperable revisions to Information Elements to correct errors (section 5.2 criterion 2 holds). > > Cheers, > > Brian > > >> On 06 Apr 2017, at 15:45, Stewart Bryant wrote: >> >> It depends on what IANA think, but it's only about an hour to write and the reviews will all go though on the nod. >> >> Of course as an AD Benoit may just be able to direct that that this obvious correction happens. >> >> Stewart >> >> >> On 06/04/2017 14:23, Andrew Feren wrote: >>> What about an errata on 5102 with a note that that the definitions have moved to the registry? Seems like an odd end run, but if it solves the problem... >>> >>> -Andrew >>> >>> ________________________________________ >>> From: IPFIX [ipfix-bounces@ietf.org] on behalf of PJ Aitken [pjaitken@brocade.com] >>> Sent: Thursday, April 06, 2017 5:37 AM >>> To: Stewart Bryant; quittek@netlab.nec.de; stbryant@cisco.com; bclaise@cisco.com; paitken@cisco.com; jemeyer@paypal.com; joelja@bogus.com; n.brownlee@auckland.ac.nz; quittek@neclab.eu >>> Cc: ipfix@ietf.org >>> Subject: Re: [IPFIX] [Technical Errata Reported] RFC5102 (4984) >>> >>> That would be possible, though it seems like a lot of effort for the >>> addition of two clarifying words, "least significant" ? >>> >>> P. >>> >>> >>> On 06/04/17 10:29, Stewart Bryant wrote: >>>> Paul >>>> >>>> If necessary you could write a one page RFC asking IANA to add a note >>>> to the registry. >>>> >>>> Stewart >>>> >>>> >>>> On 05/04/2017 19:16, PJ Aitken wrote: >>>>> I should point out that although RFC 5102 has been obsoleted by RFC >>>>> 7012, 7012 doesn't actually contain any Information Element >>>>> definitions; it simply points to IANA's IPFIX registry as the >>>>> normative reference for Element definitions. >>>>> >>>>> So the issue doesn't arise in 7012, and I suspect it's not possible >>>>> to raise an errata against the registry. >>>>> >>>>> P. >>>>> >>>>> >>>>> On 30/03/17 13:45, RFC Errata System wrote: >>>>>> The following errata report has been submitted for RFC5102, >>>>>> "Information Model for IP Flow Information Export". >>>>>> >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> https://linkprotect.cudasvc.com/url?a=https://urldefense.proofpoint.com/v2/url%3fu%3dhttps-3A__www.rfc-2Deditor.org_errata-5Fsearch.php-3Frfc-3D5102-26eid-3D4984%26d%3dDwIC-g%26c%3dIL_XqQWOjubgfqINi2jTzg%26r%3dl3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU%26m%3dlbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL-6zIIFo8oMo%26s%3dqFdcGTGJe09BgcdUjB6EszW7hMzekalZnfj8wx5JlNw%26e%3d&c=E,1,POSFjbIcmfzya-gNUP5rX4D4UfQQg4AwYC59vms0nF1wQWLNUVnaAiF5ob6Uae9OGK7KJmApL2_YmgpwUhW4gYwEcADORoaJSQoTSL3CL1vf&typo=1 >>>>>> >>>>>> -------------------------------------- >>>>>> Type: Technical >>>>>> Reported by: Paul Aitken >>>>>> >>>>>> Section: 5.2.10, appA >>>>>> >>>>>> Original Text >>>>>> ------------- >>>>>> Each bit represents an Information Element in the Data Record >>>>>> with the n-th bit >>>>>> representing the n-th Information Element. >>>>>> >>>>>> Corrected Text >>>>>> -------------- >>>>>> Each bit represents an Information Element in the Data Record, >>>>>> with the n-th least significant bit >>>>>> representing the n-th Information Element. >>>>>> >>>>>> Notes >>>>>> ----- >>>>>> A misunderstand arose as to whether bits were assigned in host order >>>>>> or network order - so clarify that the bits are assigned from the >>>>>> least significant to the most significant, ie right-to-left rather >>>>>> than left-to-right. >>>>>> >>>>>> Moreover, this clarification applies to IANA's IPFIX registry. >>>>>> >>>>>> NB RFC 8038 re-uses this definition for mibIndexIndicator. >>>>>> Consistency between the definitions is desirable. >>>>>> >>>>>> Instructions: >>>>>> ------------- >>>>>> This erratum 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 >>>>>> can log in to change the status and edit the report, if necessary. >>>>>> >>>>>> -------------------------------------- >>>>>> RFC5102 (draft-ietf-ipfix-info-15) >>>>>> -------------------------------------- >>>>>> Title : Information Model for IP Flow Information Export >>>>>> Publication Date : January 2008 >>>>>> Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, >>>>>> J. Meyer >>>>>> Category : PROPOSED STANDARD >>>>>> Source : IP Flow Information Export >>>>>> Area : Operations and Management >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >>>>>> >>>>>> _______________________________________________ >>>>>> IPFIX mailing list >>>>>> IPFIX@ietf.org >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://linkprotect.cudasvc.com/url?a=https://urldefense.proofpoint.com/v2/url%3fu%3dhttps-3A__www.ietf.org_mailman_listinfo_ipfix%26d%3dDwIC-g%26c%3dIL_XqQWOjubgfqINi2jTzg%26r%3dl3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU%26m%3dlbHlVRM8W9dbZUz-UVd1z1hzVa3rIiNL-6zIIFo8oMo%26s%3d2CAUPZ9aGFiHyUVUtn2cZFp3fcwj4DUALHp38x4XnC8%26e%3d&c=E,1,pcYrfKgiAK5NJHIqb30BLQrXBHi8Lo8-mgP6pHj3ho1uiEqr0t_tIoUPPm2W5esu67hb-exkoIxDnLvptn6Fk1XN_eXkMZbhZslQnOteFYgZtZG7_ZC0ruA,&typo=1 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://linkprotect.cudasvc.com/url?a=https://www.ietf.org/mailman/listinfo/ipfix&c=E,1,usIqknq8V3E9Vc_Br3gQ45teOaNlF3LfzLHNrQfB4rcp1FD80k14Pk3JVl_c5gVkoOA2yrwp8SRtE_kUr0YLtIlWtEs33OppFfZ7Xp_6PNt-XItuFw,,&typo=1 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://linkprotect.cudasvc.com/url?a=https://www.ietf.org/mailman/listinfo/ipfix&c=E,1,IYiyIN8296ZqBksTqvPeG0yzfRibAepQVoWtFsOwyWr9lG1Dbwrx1zu9eNVR7xKSQTQDqLnNQ7pTuXebyClfH884sMP3JzeBw-pbvsSnSedE0uaUlu0H&typo=1 > . > --------------E15AAC92AFCF5DDCF370D406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD13aW5kb3dzLTEyNTIiDQogICAgICBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KICA8 L2hlYWQ+DQogIDxib2R5IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPg0KICAg IDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+RGVhciBhbGwsPGJyPg0KICAgICAgPGJy Pg0KICAgICAgQXMgQnJpYW4gbWVudGlvbmVkLCBSRkMgNzAxMyBzZWN0aW9uIDUuMiBhcHBs aWVzIGhlcmU6PGJyPg0KICAgICAgPHByZSBjbGFzcz0ibmV3cGFnZSI+ICAgMi4gIGl0IGNv cnJlY3RzIGFuIGFtYmlndWl0eSBpbiB0aGUgSW5mb3JtYXRpb24gRWxlbWVudCdzIGRlZmlu aXRpb24sDQogICAgICAgd2hpY2ggaXRzZWxmIGxlYWRzIHRvIG5vbi1pbnRlcm9wZXJhYmls aXR5IHNldmVyZSBlbm91Z2ggdG8NCiAgICAgICBwcmV2ZW50IHRoZSBJbmZvcm1hdGlvbiBF bGVtZW50J3MgdXNhZ2UgYXMgb3JpZ2luYWxseSBkZWZpbmVkDQogICAgICAgKGUuZy4sIGEg cHJpb3IgY2hhbmdlIHRvIGlwdjZFeHRlbnNpb25IZWFkZXJzKTsgb3I8L3ByZT4NCiAgICAg IDxicj4NCiAgICAgIFBhdWwsIGFzIGVycmF0YSA0OTg0IG93bmVyLCBjYW4geW91IHBsZWFz ZSBkcm9wIGEgbm90ZSB0byBJQU5BDQogICAgICB3aXRoIHRoZSBuZXcgZGVmaW5pdGlvbi48 YnI+DQogICAgICBMZXQncyBub3QgZm9yZ290IHRvIGJ1bXAgdGhlIHJldmlzaW9uIG51bWJl ciBieSBvbmUsIGFzIG1lbnRpb25lZA0KICAgICAgaW4gUkZDNzAxMyBzZWN0aW9uIDUuMi48 YnI+DQogICAgICA8YnI+DQogICAgICBPbmNlIGRvbmUsIGV2ZW4gaWYgaXQncyBub3QgbmVj ZXNzYXJ5LCBJJ2xsIGFjY2VwdCB0aGUgZXJyYXRhDQogICAgICA0OTg0Ljxicj4NCiAgICAg IFRoZXJlIGlzIG5vIGhhcm0gYW5kIGl0IHdvdWxkIGJlIGVhc2llciBmb3IgYSBSRkMgNTEw MiByZWFkZXIsDQogICAgICBhc3N1bWluZyBzb21lb25lIHdvdWxkIHJlYWQgdGhpcyBvYnNv bGV0ZSBSRkMgKGluc3RlYWQgb2YgdGhlIFJGQw0KICAgICAgNzEwMiB0aGF0IHBvaW50cyB0 byBJQU5BKSA8YnI+DQogICAgICA8YnI+DQogICAgICBSZWdhcmRzLCBCZW5vaXQ8YnI+DQog ICAgICA8YnI+DQogICAgPC9kaXY+DQogICAgPGJsb2NrcXVvdGUNCiAgICAgIGNpdGU9Im1p ZDo4RTc1NDIyODNCODlCQjREQjY3MkVCNDlDRUU1QUFCN0JFQzg5NzU4QFBMWFJEQzAxLnBs eHIubG9jYWwiDQogICAgICB0eXBlPSJjaXRlIj4NCiAgICAgIDxwcmUgd3JhcD0iIj5TbyB3 ZSd2ZSBlc3RhYmxpc2hlZCB0aGF0IHRoZSBjaGFuZ2UgY2FuIGJlIGJlIG1hZGUgd2l0aCBv ciB3aXRoIG91dCB0aGUgZXJyYXRhLiAgDQoNCkknbSBpbiBmYXZvciBvZiBtYWtpbmcgdGhl IGNsYXJpZnlpbmcgY2hhbmdlIHRvIHRoZSByZWdpc3RyeSBhcyBwcm9wb3NlZCBpbiB0aGUg ZXJyYXRhLg0KDQpJIGRvbid0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBvbiB0aGUgYXBwcm92 YWwgb3Igbm90IG9mIHRoZSBlcnJhdGEgb24gNTEwMiwgYnV0IGl0IGl0IHByb2JhYmx5IGRv ZXNuJ3QgaHVydCB0byBhcHByb3ZlIGl0IGlmIG9ubHkgYXMgZG9jdW1lbnRhdGlvbiBvZiB3 aGF0IHdhcyBjaGFuZ2VkIGFuZCB3aHkuDQoNCi1BbmRyZXcNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogQnJpYW4gVHJhbW1lbGwgKElFVEYp IFs8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86aWV0 ZkB0cmFtbWVsbC5jaCI+aWV0ZkB0cmFtbWVsbC5jaDwvYT5dDQpTZW50OiBUdWVzZGF5LCBB cHJpbCAxOCwgMjAxNyAxMTowMSBBTQ0KVG86IFN0ZXdhcnQgQnJ5YW50DQpDYzogQW5kcmV3 IEZlcmVuOyBQSiBBaXRrZW47IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQi IGhyZWY9Im1haWx0bzpxdWl0dGVrQG5ldGxhYi5uZWMuZGUiPnF1aXR0ZWtAbmV0bGFiLm5l Yy5kZTwvYT47IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1h aWx0bzpzdGJyeWFudEBjaXNjby5jb20iPnN0YnJ5YW50QGNpc2NvLmNvbTwvYT47IEJlbm9p dCBDbGFpc2U7IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1h aWx0bzpwYWl0a2VuQGNpc2NvLmNvbSI+cGFpdGtlbkBjaXNjby5jb208L2E+OyA8YSBjbGFz cz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86amVtZXllckBwYXlw YWwuY29tIj5qZW1leWVyQHBheXBhbC5jb208L2E+OyA8YSBjbGFzcz0ibW96LXR4dC1saW5r LWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86am9lbGphQGJvZ3VzLmNvbSI+am9lbGphQGJv Z3VzLmNvbTwvYT47IE5ldmlsIEJyb3dubGVlOyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFi YnJldmlhdGVkIiBocmVmPSJtYWlsdG86cXVpdHRla0BuZWNsYWIuZXUiPnF1aXR0ZWtAbmVj bGFiLmV1PC9hPjsgPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0i bWFpbHRvOmlwZml4QGlldGYub3JnIj5pcGZpeEBpZXRmLm9yZzwvYT4NClN1YmplY3Q6IFJl OiBbSVBGSVhdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM1MTAyICg0OTg0KQ0K DQpIaSwgYWxsLA0KDQpZb3UgY2FuJ3QgcmFpc2UgYW4gZXJyYXR1bSBhZ2FpbnN0IHRoZSBy ZWdpc3RyeSwgYnV0IDcwMTMgcHJvdmlkZXMgZm9yIGludGVyb3BlcmFibGUgcmV2aXNpb25z IHRvIEluZm9ybWF0aW9uIEVsZW1lbnRzIHRvIGNvcnJlY3QgZXJyb3JzIChzZWN0aW9uIDUu MiBjcml0ZXJpb24gMiBob2xkcykuDQoNCkNoZWVycywNCg0KQnJpYW4NCg0KDQo8L3ByZT4N CiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICA8cHJlIHdyYXA9IiI+ T24gMDYgQXByIDIwMTcsIGF0IDE1OjQ1LCBTdGV3YXJ0IEJyeWFudCA8YSBjbGFzcz0ibW96 LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwu Y29tIj4mbHQ7c3Rld2FydC5icnlhbnRAZ21haWwuY29tJmd0OzwvYT4gd3JvdGU6DQoNCkl0 IGRlcGVuZHMgb24gd2hhdCBJQU5BIHRoaW5rLCBidXQgaXQncyBvbmx5IGFib3V0IGFuIGhv dXIgdG8gd3JpdGUgYW5kIHRoZSByZXZpZXdzIHdpbGwgYWxsIGdvIHRob3VnaCBvbiB0aGUg bm9kLg0KDQpPZiBjb3Vyc2UgYXMgYW4gQUQgQmVub2l0IG1heSBqdXN0IGJlIGFibGUgdG8g ZGlyZWN0IHRoYXQgdGhhdCB0aGlzIG9idmlvdXMgY29ycmVjdGlvbiBoYXBwZW5zLg0KDQpT dGV3YXJ0DQoNCg0KT24gMDYvMDQvMjAxNyAxNDoyMywgQW5kcmV3IEZlcmVuIHdyb3RlOg0K PC9wcmU+DQogICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgIDxw cmUgd3JhcD0iIj5XaGF0IGFib3V0IGFuIGVycmF0YSBvbiA1MTAyIHdpdGggYSBub3RlIHRo YXQgdGhhdCB0aGUgZGVmaW5pdGlvbnMgaGF2ZSBtb3ZlZCB0byB0aGUgcmVnaXN0cnk/ICBT ZWVtcyBsaWtlIGFuIG9kZCBlbmQgcnVuLCBidXQgaWYgaXQgc29sdmVzIHRoZSBwcm9ibGVt Li4uDQoNCi1BbmRyZXcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogSVBGSVggWzxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQi IGhyZWY9Im1haWx0bzppcGZpeC1ib3VuY2VzQGlldGYub3JnIj5pcGZpeC1ib3VuY2VzQGll dGYub3JnPC9hPl0gb24gYmVoYWxmIG9mIFBKIEFpdGtlbiBbPGEgY2xhc3M9Im1vei10eHQt bGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOnBqYWl0a2VuQGJyb2NhZGUuY29tIj5w amFpdGtlbkBicm9jYWRlLmNvbTwvYT5dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDYsIDIw MTcgNTozNyBBTQ0KVG86IFN0ZXdhcnQgQnJ5YW50OyA8YSBjbGFzcz0ibW96LXR4dC1saW5r LWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86cXVpdHRla0BuZXRsYWIubmVjLmRlIj5xdWl0 dGVrQG5ldGxhYi5uZWMuZGU8L2E+OyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlh dGVkIiBocmVmPSJtYWlsdG86c3RicnlhbnRAY2lzY28uY29tIj5zdGJyeWFudEBjaXNjby5j b208L2E+OyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWls dG86YmNsYWlzZUBjaXNjby5jb20iPmJjbGFpc2VAY2lzY28uY29tPC9hPjsgPGEgY2xhc3M9 Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOnBhaXRrZW5AY2lzY28u Y29tIj5wYWl0a2VuQGNpc2NvLmNvbTwvYT47IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJi cmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpqZW1leWVyQHBheXBhbC5jb20iPmplbWV5ZXJAcGF5 cGFsLmNvbTwvYT47IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9 Im1haWx0bzpqb2VsamFAYm9ndXMuY29tIj5qb2VsamFAYm9ndXMuY29tPC9hPjsgPGEgY2xh c3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm4uYnJvd25sZWVA YXVja2xhbmQuYWMubnoiPm4uYnJvd25sZWVAYXVja2xhbmQuYWMubno8L2E+OyA8YSBjbGFz cz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86cXVpdHRla0BuZWNs YWIuZXUiPnF1aXR0ZWtAbmVjbGFiLmV1PC9hPg0KQ2M6IDxhIGNsYXNzPSJtb3otdHh0LWxp bmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzppcGZpeEBpZXRmLm9yZyI+aXBmaXhAaWV0 Zi5vcmc8L2E+DQpTdWJqZWN0OiBSZTogW0lQRklYXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBv cnRlZF0gUkZDNTEwMiAoNDk4NCkNCg0KVGhhdCB3b3VsZCBiZSBwb3NzaWJsZSwgdGhvdWdo IGl0IHNlZW1zIGxpa2UgYSBsb3Qgb2YgZWZmb3J0IGZvciB0aGUNCmFkZGl0aW9uIG9mIHR3 byBjbGFyaWZ5aW5nIHdvcmRzLCAibGVhc3Qgc2lnbmlmaWNhbnQiID8NCg0KUC4NCg0KDQpP biAwNi8wNC8xNyAxMDoyOSwgU3Rld2FydCBCcnlhbnQgd3JvdGU6DQo8L3ByZT4NCiAgICAg ICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgIDxwcmUgd3JhcD0i Ij5QYXVsDQoNCklmIG5lY2Vzc2FyeSB5b3UgY291bGQgd3JpdGUgYSBvbmUgcGFnZSBSRkMg YXNraW5nIElBTkEgdG8gYWRkIGEgbm90ZQ0KdG8gdGhlIHJlZ2lzdHJ5Lg0KDQpTdGV3YXJ0 DQoNCg0KT24gMDUvMDQvMjAxNyAxOToxNiwgUEogQWl0a2VuIHdyb3RlOg0KPC9wcmU+DQog ICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgPHBy ZSB3cmFwPSIiPkkgc2hvdWxkIHBvaW50IG91dCB0aGF0IGFsdGhvdWdoIFJGQyA1MTAyIGhh cyBiZWVuIG9ic29sZXRlZCBieSBSRkMNCjcwMTIsIDcwMTIgZG9lc24ndCBhY3R1YWxseSBj b250YWluIGFueSBJbmZvcm1hdGlvbiBFbGVtZW50DQpkZWZpbml0aW9uczsgaXQgc2ltcGx5 IHBvaW50cyB0byBJQU5BJ3MgSVBGSVggcmVnaXN0cnkgYXMgdGhlDQpub3JtYXRpdmUgcmVm ZXJlbmNlIGZvciBFbGVtZW50IGRlZmluaXRpb25zLg0KDQpTbyB0aGUgaXNzdWUgZG9lc24n dCBhcmlzZSBpbiA3MDEyLCBhbmQgSSBzdXNwZWN0IGl0J3Mgbm90IHBvc3NpYmxlDQp0byBy YWlzZSBhbiBlcnJhdGEgYWdhaW5zdCB0aGUgcmVnaXN0cnkuDQoNClAuDQoNCg0KT24gMzAv MDMvMTcgMTM6NDUsIFJGQyBFcnJhdGEgU3lzdGVtIHdyb3RlOg0KPC9wcmU+DQogICAgICAg ICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgICAgIDxwcmUg d3JhcD0iIj5UaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVk IGZvciBSRkM1MTAyLA0KIkluZm9ybWF0aW9uIE1vZGVsIGZvciBJUCBGbG93IEluZm9ybWF0 aW9uIEV4cG9ydCIuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCjxhIGNsYXNzPSJt b3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vbGlua3Byb3RlY3QuY3VkYXN2 Yy5jb20vdXJsP2E9aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybCUz ZnUlM2RodHRwcy0zQV9fd3d3LnJmYy0yRGVkaXRvci5vcmdfZXJyYXRhLTVGc2VhcmNoLnBo cC0zRnJmYy0zRDUxMDItMjZlaWQtM0Q0OTg0JTI2ZCUzZER3SUMtZyUyNmMlM2RJTF9YcVFX T2p1YmdmcUlOaTJqVHpnJTI2ciUzZGwzcU4tTlZrVVRQaGhSeEtWcEZYUkRqckczV05jal82 YUdxWEI5RTdKWVUlMjZtJTNkbGJIbFZSTThXOWRiWlV6LVVWZDF6MWh6VmEzcklpTkwtNnpJ SUZvOG9NbyUyNnMlM2RxRmRjR1RHSmUwOUJnY2RVakI2RXN6VzdoTXpla2FsWm5majh3eDVK bE53JTI2ZSUzZCZhbXA7Yz1FLDEsUE9TRmpiSWNtZnp5YS1nTlVQNXJYNEQ0VWZRUWc0QXdZ QzU5dm1zMG5GMXdRV0xOVVZuYUFpRjVvYjZVYWU5T0dLN0tKbUFwTDJfWW1ncHdVaFc0Z1l3 RWNBRE9Sb2FKU1FvVFNMM0NMMXZmJmFtcDt0eXBvPTEiPmh0dHBzOi8vbGlua3Byb3RlY3Qu Y3VkYXN2Yy5jb20vdXJsP2E9aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybCUzZnUlM2RodHRwcy0zQV9fd3d3LnJmYy0yRGVkaXRvci5vcmdfZXJyYXRhLTVGc2Vh cmNoLnBocC0zRnJmYy0zRDUxMDItMjZlaWQtM0Q0OTg0JTI2ZCUzZER3SUMtZyUyNmMlM2RJ TF9YcVFXT2p1YmdmcUlOaTJqVHpnJTI2ciUzZGwzcU4tTlZrVVRQaGhSeEtWcEZYUkRqckcz V05jal82YUdxWEI5RTdKWVUlMjZtJTNkbGJIbFZSTThXOWRiWlV6LVVWZDF6MWh6VmEzcklp TkwtNnpJSUZvOG9NbyUyNnMlM2RxRmRjR1RHSmUwOUJnY2RVakI2RXN6VzdoTXpla2FsWm5m ajh3eDVKbE53JTI2ZSUzZCZhbXA7Yz1FLDEsUE9TRmpiSWNtZnp5YS1nTlVQNXJYNEQ0VWZR UWc0QXdZQzU5dm1zMG5GMXdRV0xOVVZuYUFpRjVvYjZVYWU5T0dLN0tKbUFwTDJfWW1ncHdV aFc0Z1l3RWNBRE9Sb2FKU1FvVFNMM0NMMXZmJmFtcDt0eXBvPTE8L2E+DQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUeXBlOiBUZWNobmljYWwNClJlcG9y dGVkIGJ5OiBQYXVsIEFpdGtlbiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBo cmVmPSJtYWlsdG86cGphaXRrZW5AYnJvY2FkZS5jb20iPiZsdDtwamFpdGtlbkBicm9jYWRl LmNvbSZndDs8L2E+DQoNClNlY3Rpb246IDUuMi4xMCwgYXBwQQ0KDQpPcmlnaW5hbCBUZXh0 DQotLS0tLS0tLS0tLS0tDQpFYWNoIGJpdCByZXByZXNlbnRzIGFuIEluZm9ybWF0aW9uIEVs ZW1lbnQgaW4gdGhlIERhdGEgUmVjb3JkDQp3aXRoIHRoZSBuLXRoIGJpdA0KcmVwcmVzZW50 aW5nIHRoZSBuLXRoIEluZm9ybWF0aW9uIEVsZW1lbnQuDQoNCkNvcnJlY3RlZCBUZXh0DQot LS0tLS0tLS0tLS0tLQ0KRWFjaCBiaXQgcmVwcmVzZW50cyBhbiBJbmZvcm1hdGlvbiBFbGVt ZW50IGluIHRoZSBEYXRhIFJlY29yZCwNCndpdGggdGhlIG4tdGggbGVhc3Qgc2lnbmlmaWNh bnQgYml0DQpyZXByZXNlbnRpbmcgdGhlIG4tdGggSW5mb3JtYXRpb24gRWxlbWVudC4NCg0K Tm90ZXMNCi0tLS0tDQpBIG1pc3VuZGVyc3RhbmQgYXJvc2UgYXMgdG8gd2hldGhlciBiaXRz IHdlcmUgYXNzaWduZWQgaW4gaG9zdCBvcmRlcg0Kb3IgbmV0d29yayBvcmRlciAtIHNvIGNs YXJpZnkgdGhhdCB0aGUgYml0cyBhcmUgYXNzaWduZWQgZnJvbSB0aGUNCmxlYXN0IHNpZ25p ZmljYW50IHRvIHRoZSBtb3N0IHNpZ25pZmljYW50LCBpZSByaWdodC10by1sZWZ0IHJhdGhl cg0KdGhhbiBsZWZ0LXRvLXJpZ2h0Lg0KDQpNb3Jlb3ZlciwgdGhpcyBjbGFyaWZpY2F0aW9u IGFwcGxpZXMgdG8gSUFOQSdzIElQRklYIHJlZ2lzdHJ5Lg0KDQpOQiBSRkMgODAzOCByZS11 c2VzIHRoaXMgZGVmaW5pdGlvbiBmb3IgbWliSW5kZXhJbmRpY2F0b3IuDQpDb25zaXN0ZW5j eSBiZXR3ZWVuIHRoZSBkZWZpbml0aW9ucyBpcyBkZXNpcmFibGUuDQoNCkluc3RydWN0aW9u czoNCi0tLS0tLS0tLS0tLS0NClRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFz ICJSZXBvcnRlZCIuIElmIG5lY2Vzc2FyeSwgcGxlYXNlDQp1c2UgIlJlcGx5IEFsbCIgdG8g ZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KcmVqZWN0ZWQuIFdo ZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5DQpjYW4gbG9n IGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vz c2FyeS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJGQzUx MDIgKGRyYWZ0LWlldGYtaXBmaXgtaW5mby0xNSkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpUaXRsZSAgICAgICAgICAgICAgIDogSW5mb3JtYXRpb24gTW9k ZWwgZm9yIElQIEZsb3cgSW5mb3JtYXRpb24gRXhwb3J0DQpQdWJsaWNhdGlvbiBEYXRlICAg IDogSmFudWFyeSAyMDA4DQpBdXRob3IocykgICAgICAgICAgIDogSi4gUXVpdHRlaywgUy4g QnJ5YW50LCBCLiBDbGFpc2UsIFAuIEFpdGtlbiwNCkouIE1leWVyDQpDYXRlZ29yeSAgICAg ICAgICAgIDogUFJPUE9TRUQgU1RBTkRBUkQNClNvdXJjZSAgICAgICAgICAgICAgOiBJUCBG bG93IEluZm9ybWF0aW9uIEV4cG9ydA0KQXJlYSAgICAgICAgICAgICAgICA6IE9wZXJhdGlv bnMgYW5kIE1hbmFnZW1lbnQNClN0cmVhbSAgICAgICAgICAgICAgOiBJRVRGDQpWZXJpZnlp bmcgUGFydHkgICAgIDogSUVTRw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KSVBGSVggbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4 dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86SVBGSVhAaWV0Zi5vcmciPklQRklY QGlldGYub3JnPC9hPg0KPC9wcmU+DQogICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAg ICAgICAgICAgICAgPHByZSB3cmFwPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpJUEZJWCBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3ot dHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpJUEZJWEBpZXRmLm9yZyI+SVBG SVhAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVm PSJodHRwczovL2xpbmtwcm90ZWN0LmN1ZGFzdmMuY29tL3VybD9hPWh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmwlM2Z1JTNkaHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX2lwZml4JTI2ZCUzZER3SUMtZyUyNmMlM2RJTF9YcVFXT2p1 YmdmcUlOaTJqVHpnJTI2ciUzZGwzcU4tTlZrVVRQaGhSeEtWcEZYUkRqckczV05jal82YUdx WEI5RTdKWVUlMjZtJTNkbGJIbFZSTThXOWRiWlV6LVVWZDF6MWh6VmEzcklpTkwtNnpJSUZv OG9NbyUyNnMlM2QyQ0FVUFo5YUdGaUh5VVZVdG4yY1pGcDNmY3dqNERVQUxIcDM4eDRYbkM4 JTI2ZSUzZCZhbXA7Yz1FLDEscGNZcmZLZ2lBSzVOSkhJcWIzMEJMUXJYQkhpOExvOC1tZ1A2 cEhqM2hvMXVpRXFyMHRfdElvVVBQbTJXNWVzdTY3aGItZXhrb0l4RG5MdnB0bjZGazFYTl9l WGtNWmJoWnNsUW5PdGVGWWdadFpHN19aQzBydUEsJmFtcDt0eXBvPTEiPmh0dHBzOi8vbGlu a3Byb3RlY3QuY3VkYXN2Yy5jb20vdXJsP2E9aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybCUzZnUlM2RodHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9faXBmaXglMjZkJTNkRHdJQy1nJTI2YyUzZElMX1hxUVdPanViZ2ZxSU5pMmpUemcl MjZyJTNkbDNxTi1OVmtVVFBoaFJ4S1ZwRlhSRGpyRzNXTmNqXzZhR3FYQjlFN0pZVSUyNm0l M2RsYkhsVlJNOFc5ZGJaVXotVVZkMXoxaHpWYTNySWlOTC02eklJRm84b01vJTI2cyUzZDJD QVVQWjlhR0ZpSHlVVlV0bjJjWkZwM2Zjd2o0RFVBTEhwMzh4NFhuQzglMjZlJTNkJmFtcDtj PUUsMSxwY1lyZktnaUFLNU5KSElxYjMwQkxRclhCSGk4TG84LW1nUDZwSGozaG8xdWlFcXIw dF90SW9VUFBtMlc1ZXN1NjdoYi1leGtvSXhEbkx2cHRuNkZrMVhOX2VYa01aYmhac2xRbk90 ZUZZZ1p0Wkc3X1pDMHJ1QSwmYW1wO3R5cG89MTwvYT4NCjwvcHJlPg0KICAgICAgICAgICAg PC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgPHByZSB3cmFwPSIiPg0KPC9wcmU+DQogICAg ICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgIDxwcmUgd3JhcD0iIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSVBGSVggbWFpbGluZyBs aXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86 SVBGSVhAaWV0Zi5vcmciPklQRklYQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQt bGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly9saW5rcHJvdGVjdC5jdWRhc3ZjLmNvbS91 cmw/YT1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwZml4JmFtcDtj PUUsMSx1c0lxa25xOFYzRTlWY19CcjNnUTQ1dGVPYU5sRjNMZnpMSE5yUWZCNHJjcDFGRDgw azE0UGszSlZsX2M1Z1Zrb09BMnlyd3A4U1J0RV9rVXIwWUx0SWxXdEVzMzNPcHBGZlo3WHBf NlBOdC1YSXR1RncsLCZhbXA7dHlwbz0xIj5odHRwczovL2xpbmtwcm90ZWN0LmN1ZGFzdmMu Y29tL3VybD9hPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBmaXgm YW1wO2M9RSwxLHVzSXFrbnE4VjNFOVZjX0JyM2dRNDV0ZU9hTmxGM0xmekxITnJRZkI0cmNw MUZEODBrMTRQazNKVmxfYzVnVmtvT0EyeXJ3cDhTUnRFX2tVcjBZTHRJbFd0RXMzM09wcEZm WjdYcF82UE50LVhJdHVGdywsJmFtcDt0eXBvPTE8L2E+DQo8L3ByZT4NCiAgICAgICAgPC9i bG9ja3F1b3RlPg0KICAgICAgICA8cHJlIHdyYXA9IiI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSVBGSVggbWFpbGluZyBsaXN0DQo8YSBj bGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86SVBGSVhAaWV0 Zi5vcmciPklQRklYQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVl dGV4dCIgaHJlZj0iaHR0cHM6Ly9saW5rcHJvdGVjdC5jdWRhc3ZjLmNvbS91cmw/YT1odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwZml4JmFtcDtjPUUsMSxJWWl5 SU44Mjk2WnFCa3NUcXZQZUcweXpmUmliQWVwUVZvV3RGc093eVdyOWxHMURid3J4MXp1OWVO VlI3eEtTUVRRRHFMbk5RN3BUdVhlYnlDbGZIODg0c01QM0p6ZUJ3LXBidnNTblNlZEUwdWFV bHUwSCZhbXA7dHlwbz0xIj5odHRwczovL2xpbmtwcm90ZWN0LmN1ZGFzdmMuY29tL3VybD9h PWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBmaXgmYW1wO2M9RSwx LElZaXlJTjgyOTZacUJrc1RxdlBlRzB5emZSaWJBZXBRVm9XdEZzT3d5V3I5bEcxRGJ3cngx enU5ZU5WUjd4S1NRVFFEcUxuTlE3cFR1WGVieUNsZkg4ODRzTVAzSnplQnctcGJ2c1NuU2Vk RTB1YVVsdTBIJmFtcDt0eXBvPTE8L2E+DQo8L3ByZT4NCiAgICAgIDwvYmxvY2txdW90ZT4N CiAgICAgIDxwcmUgd3JhcD0iIj4NCi4NCg0KPC9wcmU+DQogICAgPC9ibG9ja3F1b3RlPg0K ICAgIDxicj4NCiAgPC9ib2R5Pg0KPC9odG1sPg0K --------------E15AAC92AFCF5DDCF370D406--