From suresh.krishnan@ericsson.com Tue Feb 28 17:47:23 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633CD21F8753 for ; Tue, 28 Feb 2012 17:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.196 X-Spam-Level: X-Spam-Status: No, score=-106.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 KhezfHBKbDzb for ; Tue, 28 Feb 2012 17:47:22 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id BE3E421F874A for ; Tue, 28 Feb 2012 17:47:22 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q1T1lEeI030328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Feb 2012 19:47:14 -0600 Received: from [142.133.10.98] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 28 Feb 2012 20:47:13 -0500 Message-ID: <4F4D83A1.8040103@ericsson.com> Date: Tue, 28 Feb 2012 20:47:13 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Mar 2012 23:50:03 -0800 Cc: "rtg-dir@ietf.org" , "draft-ietf-netext-pmip-lr.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netext-pmip-lr-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 01:47:23 -0000 Hi Les, Thanks for the review. Please find responses inline. On 02/27/2012 02:28 AM, Les Ginsberg (ginsberg) wrote: > (Resending w corrected draft address) > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review. The purpose > of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-netext-pmip-lr-08 > Reviewer: Les Ginsberg > Review Date: 26 February 2012 > IETF LC End Date: ??? > Intended Status: Standards Track > > Summary: > I have some minor concerns about this document that I think should be > resolved before publication. > > Comments: > This document is clearly written and easy to understand. > This is the first PMIP document I have reviewed, so I went back and read > some of the previous RFCs. Despite that it may mean that some of my > comments/questions are naive. Please indulge me. > > Major Issues: > No major issues found. > > Minor Issues: > > Why are you not using the "MN-CN" terminology from RFC 6279? The fact > that you use "MN-MN" makes me think that you are only addressing cases > where both endpoints are MNs. Is this the case? If so, this should be > explicitly stated. If not, it would seem to be better to use the RFC > 6279 terminology. Your understanding is correct. I will add a statement to that effect. > > Section 5 > > I assume the lack of requirement for synchronization works because the > LMA will always forward packets regardless of whether it has sent an > LRI/received an LRA? This implies that MNs and MAGs may receive > duplicate packets at times - which presumably should be no problem. I am > wondering if it would be useful to discuss these points? In the handover case, the MAG2 will continue sending packets to MAG1 until the LMA establishes new LR state towards nMAG1, and these packets will be lost. I will add text to this section to make this clear. > > Similarly, in Section 6.1 it is assumed that LMAs always forward > inter-MN packets regardless of the state of LR? There will be no inter-LMA forwarding in this case during handover. The wg decided not to handle this case (A22) because there is no defined inter-LMA communication mechanism in PMIPv6. > > Nits: > A number of acronyms are used without definition. For example, in > Section 4 page 7 "HNP" "BUL" "BCE" are all undefined. This does not > represent a complete list. Can you please scrub the document for all > such occurences? These are inherited from the base PMIP RFC (RFC5213). Would you still like me to add the expansions here? Thanks Suresh From suresh.krishnan@ericsson.com Mon Mar 5 15:14:51 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6737421F85F9 for ; Mon, 5 Mar 2012 15:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.218 X-Spam-Level: X-Spam-Status: No, score=-106.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 XnsBvhPEYsFx for ; Mon, 5 Mar 2012 15:14:50 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA6421F85EF for ; Mon, 5 Mar 2012 15:14:50 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q25NEhHj018922; Mon, 5 Mar 2012 17:14:45 -0600 Received: from [142.133.10.98] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 5 Mar 2012 18:14:44 -0500 Message-ID: <4F5548E4.9090605@ericsson.com> Date: Mon, 5 Mar 2012 18:14:44 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" References: <4F4D83A1.8040103@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 08 Mar 2012 09:49:26 -0800 Cc: "rtg-dir@ietf.org" , "draft-ietf-netext-pmip-lr.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netext-pmip-lr-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:14:51 -0000 Hi Les, Addressing 2 open items from your review. Les Ginsberg (ginsberg) wrote: > Suresh - > > Replies inline. > >> -----Original Message----- >> From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] >> Sent: Tuesday, February 28, 2012 5:47 PM >> To: Les Ginsberg (ginsberg) >> Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-netext-pmip- >> lr.all@tools.ietf.org >> Subject: Re: RtgDir review: draft-ietf-netext-pmip-lr-08.txt >> >> Hi Les, >> Thanks for the review. Please find responses inline. >> >> On 02/27/2012 02:28 AM, Les Ginsberg (ginsberg) wrote: >>> (Resending w corrected draft address) >>> >>> Hello, >>> >>> I have been selected as the Routing Directorate reviewer for this >> draft. >>> The Routing Directorate seeks to review all routing or routing- >> related >>> drafts as they pass through IETF last call and IESG review. The >> purpose >>> of the review is to provide assistance to the Routing ADs. For more >>> information about the Routing Directorate, please see >>> http://www.ietf.org/iesg/directorate/routing.html >>> >>> Although these comments are primarily for the use of the Routing > ADs, >> it >>> would be helpful if you could consider them along with any other > IETF >>> Last Call comments that you receive, and strive to resolve them >> through >>> discussion or by updating the draft. >>> >>> Document: draft-ietf-netext-pmip-lr-08 >>> Reviewer: Les Ginsberg >>> Review Date: 26 February 2012 >>> IETF LC End Date: ??? >>> Intended Status: Standards Track >>> >>> Summary: >>> I have some minor concerns about this document that I think should > be >>> resolved before publication. >>> >>> Comments: >>> This document is clearly written and easy to understand. >>> This is the first PMIP document I have reviewed, so I went back and >> read >>> some of the previous RFCs. Despite that it may mean that some of my >>> comments/questions are naive. Please indulge me. >>> >>> Major Issues: >>> No major issues found. >>> >>> Minor Issues: >>> >>> Why are you not using the "MN-CN" terminology from RFC 6279? The > fact >>> that you use "MN-MN" makes me think that you are only addressing >> cases >>> where both endpoints are MNs. Is this the case? If so, this should > be >>> explicitly stated. If not, it would seem to be better to use the RFC >>> 6279 terminology. >> >> Your understanding is correct. I will add a statement to that effect. > > Could you also explain why the solutions defined do not work unless both > nodes are Mobile? > And, since you say that MN-CN is not addressed, is this something which > is planned for a future document? RFC 6279 seems to clearly include both > MN-MN and MN-nonMN (my terminology invention :-)) in the problem space > to be solved. RFC6279 only addresses MN-MN communications even though it refers to a CN. It claims to use RFC3775 terminology for the CN, but it does not. It assumes that the CN has a MAG and is anchored at an LMA. That makes it an MN. > >> >>> >>> Section 5 >>> >>> I assume the lack of requirement for synchronization works because >> the >>> LMA will always forward packets regardless of whether it has sent an >>> LRI/received an LRA? This implies that MNs and MAGs may receive >>> duplicate packets at times - which presumably should be no problem. > I >> am >>> wondering if it would be useful to discuss these points? >> >> In the handover case, the MAG2 will continue sending packets to MAG1 >> until the LMA establishes new LR state towards nMAG1, and these > packets >> will be lost. I will add text to this section to make this clear. > > This is not what I was commenting on - though additional clarity in this > case would be helpful as well. > I was commenting on the initial setup of LR. I was commenting on the > statement > > " The protocol does not require any synchronization between the MAGs > before local forwarding begins." > > This occurs at the end of Section 5 BEFORE the discussion of handoff in > Section 5.1. > Please respond to this comment. No synchronization between MAGs is required because each MAG initiates LR in one direction. After the LMA instructs MAG1 to initiate LR, packets from MN1 to MN2 will take the path MN1->MAG1->MAG2->MN2 while those from MN2 to MN1 will take the path MN2->MAG2->LMA->MAG1->MN1 until LMA instructs MAG2 to do so as well. At any instant a MAG will forward a packet either towards another MAG or its LMA. So there should be no duplicate packets. > >> >>> >>> Similarly, in Section 6.1 it is assumed that LMAs always forward >>> inter-MN packets regardless of the state of LR? >> >> There will be no inter-LMA forwarding in this case during handover. > The >> wg decided not to handle this case (A22) because there is no defined >> inter-LMA communication mechanism in PMIPv6. > > I am not commenting on A22 - which is discussed in Section 7. My comment > is regarding what happens during the handover discussed in Section 6.1. > My concern is regarding what prevents packets from being lost during the > handover. I assume that no packets are lost because the LMA will always > forward packets to an MN registered with it even if it currently > believes that LR is active/enabled - but wanted to confirm and also > suggest that mention of that point (if correct) might be clarifying. You are right. I will add some text clarifying this. Thanks Suresh From adrian@olddog.co.uk Fri Mar 9 13:49:49 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D852D21E80AB; Fri, 9 Mar 2012 13:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=-1.480, BAYES_50=0.001, RCVD_IN_SORBS_WEB=0.619] 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 1gn0IsbhTydl; Fri, 9 Mar 2012 13:49:49 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 234B421E8047; Fri, 9 Mar 2012 13:49:48 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q29LnlPp013794; Fri, 9 Mar 2012 21:49:47 GMT Received: from 950129200 ([90.84.144.160]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q29LnVZ4013725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Mar 2012 21:49:41 GMT From: "Adrian Farrel" To: , , Date: Fri, 9 Mar 2012 21:49:21 -0000 Message-ID: <008a01ccfe3e$8be8d0a0$a3ba71e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acz+PhL5YOsj7IROSBunE4hPO8ZS0g== Content-Language: en-gb Cc: rtg-ads@tools.ietf.org Subject: [RTG-DIR] Routing ADs Open Office X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:49:50 -0000 Hi, As usual, we have blocked off the "IESG breakout room" from 14.00 to 16.00 on IETF Sunday. However, in a slight break with tradition, we have scheduled specific appointments for the first hour. So, unless we have given you a timeslot, please don't show up until 15.00 when we shall be happy to entertain you with pithy repartee and listen to you on a first-come first-served loudest-voice-first principle. Thanks, Adrian From adrian@olddog.co.uk Tue Mar 20 14:55:41 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045A321E8015; Tue, 20 Mar 2012 14:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_20=-0.74] 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 hjHH2+L6HYQD; Tue, 20 Mar 2012 14:55:39 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 64D9B21E800F; Tue, 20 Mar 2012 14:55:39 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2KLtbAW024696; Tue, 20 Mar 2012 21:55:37 GMT Received: from 950129200 ([90.84.146.212]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2KLtM6g024663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Mar 2012 21:55:30 GMT From: "Adrian Farrel" To: Date: Tue, 20 Mar 2012 21:55:11 -0000 Message-ID: <02a601cd06e4$2d910000$88b30000$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0G45gmrD5CiGTFQuC09pL6S8maVQ== Content-Language: en-gb Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: [RTG-DIR] Routing Area Meeting in Paris X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 21:55:41 -0000 Hi, In addition to the usual round-the-houses of the working groups, we are planning a series of short talks on "routing in other areas" to see what routing concepts are being applied in other IETF Areas that might not be well known to the people who hang out in the Routing Area. Main objective is education with the strong hope that people will find the problems being addressed interesting and share their routing clue in other working groups (rather than in this meeting directly). Adrian From danfrost@cisco.com Wed Mar 21 08:57:44 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E0E21E800E for ; Wed, 21 Mar 2012 08:57:44 -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 29cpk5Jw8Xgs for ; Wed, 21 Mar 2012 08:57:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5962E21E8012 for ; Wed, 21 Mar 2012 08:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=3072; q=dns/txt; s=iport; t=1332345463; x=1333555063; h=from:to:cc:subject:date:message-id:mime-version; bh=4yrvDFfnRe0z5kO59Y/SNCIWLgGUTnjyy6v7FM6wHyk=; b=WHiclaQh85ZBE2GvR6+eyj7iqK8sseeltQF66vV8GiMqxsRKT9dCd4yF vZ+IVhT48iXLYGIz4+r6kxPuJElRwOkgeSD/lkQTaxYuQA4eoEdt7ctPr 1g81sCJVEpnehLvU5ikOsVabAPuD+1jgQ9GdwPEtAc99eEagfCEp/KtCe o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACD6aU+tJV2d/2dsb2JhbABDtwaBB4IiARkOPy8NNAEEZRmHaAufKZcqkQEElV+OP4Fogmc X-IronPort-AV: E=Sophos;i="4.73,623,1325462400"; d="scan'208";a="68255568" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 21 Mar 2012 15:57:43 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [10.83.106.70]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2LFvgX2024353; Wed, 21 Mar 2012 15:57:42 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id q2LFvghf015713; Wed, 21 Mar 2012 11:57:42 -0400 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id q2LFvgsh015712; Wed, 21 Mar 2012 15:57:42 GMT X-Authentication-Warning: isolaria.cisco.com: danfrost set sender to danfrost@cisco.com using -f From: Dan Frost To: rtg-ads@tools.ietf.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Date: Wed, 21 Mar 2012 15:57:42 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: rtg-dir@ietf.org, draft-ietf-ippm-rt-loss.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-ippm-rt-loss-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:57:44 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ippm-rt-loss-03.txt Reviewer: Dan Frost Review Date: 21 March 2012 IETF LC End Date: 19 March 2012 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This document supplies a definition for round-trip packet loss in terms of the IP Performance Metrics framework. It is straightforward and clearly written. General observation: It's not clear to me what the IPPM WG strategy is for security considerations sections in metric definition documents. For example, the security section of this document more or less repeats the one in (for example) RFC 2681, which itself duplicates verbatim the one in RFC 2680, and the issues discussed are general ones with measurement protocols rather than specific ones with the metric that is the subject of the document. There's probably a better way to organize this. Major Issues: No major issues found. Minor Issues: 1. Although it's probably obvious to most readers, it would be helpful to provide a brief informal definition of "round-trip loss" early in the introduction. A mention of the venerable "ping" procedure would also not be amiss. 2. Most of the text seems to assume an "active" or test-based measurement approach, but Section 9.2 refers to passive measurement. It would be helpful to discuss the applicability of the latter approach. 3. Section 9.3 mentions the use of cryptographic hashing "to discourage the kind of interference mentioned above"; while this would mitigate the second form of interference, it wouldn't help with the first. Nits: 1. The phrase "as immediately as possible" that appears a couple of times in the text (and that seems to originate in RFC 5357) is a bit unfortunate. "Immediately" or "as quickly as possible" are better. 2. Section 5.4, second paragraph: s/affects/effects/ 3. Section 8, second paragraph: s/Two key features ... is described/Two key features ... are described/ 4. Section 9.3, first paragraph: OLD it is possible to change the processing of the packets (e.g. increasing or decreasing delay) that may distort the measured performance. NEW it is possible to change the processing of the packets (e.g. increasing or decreasing delay) in a way that may distort the measured performance. END Cheers, -d From db3546@att.com Wed Mar 21 10:41:10 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9532821E8040; Wed, 21 Mar 2012 10:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-1.999, 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 ccy6afyo5C9P; Wed, 21 Mar 2012 10:41:10 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id C061E21E8026; Wed, 21 Mar 2012 10:41:09 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 5b21a6f4.0.1029595.00-273.2828556.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 21 Mar 2012 17:41:09 +0000 (UTC) X-MXL-Hash: 4f6a12b5333cef75-aa22e301ba054fc7b4052a7c759b1539e48f7dc7 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2LHfewo027664; Wed, 21 Mar 2012 13:41:40 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2LHfZHH027608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2012 13:41:36 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint01.pst.cso.att.com (RSA Interceptor); Wed, 21 Mar 2012 13:40:51 -0400 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.153]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0355.002; Wed, 21 Mar 2012 13:40:50 -0400 From: "BRUNGARD, DEBORAH A" To: "adrian@olddog.co.uk" , "routing-discussion@ietf.org" Thread-Topic: Routing Area Meeting in Paris Thread-Index: Ac0G45gmrD5CiGTFQuC09pL6S8maVQApgp4A Date: Wed, 21 Mar 2012 17:40:50 +0000 Message-ID: References: <02a601cd06e4$2d910000$88b30000$@olddog.co.uk> In-Reply-To: <02a601cd06e4$2d910000$88b30000$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.26.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=9rNEmMrW-rIA:10 a=L55XatgGI34A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=dQAnMdUIizHq-9kDJCAA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Meeting in Paris X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 17:41:10 -0000 Here's the agenda: http://www.ietf.org/proceedings/83/agenda/agenda-83-rtgarea.txt -----Original Message----- From: routing-discussion-bounces@ietf.org [mailto:routing-discussion-bounce= s@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, March 20, 2012 5:55 PM To: routing-discussion@ietf.org Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Routing Area Meeting in Paris Hi, In addition to the usual round-the-houses of the working groups, we are pla= nning a series of short talks on "routing in other areas" to see what routing con= cepts are being applied in other IETF Areas that might not be well known to the p= eople who hang out in the Routing Area. Main objective is education with the strong hope that people will find the problems being addressed interesting and share their routing clue in other working groups (rather than in this meeting directly). Adrian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From thomas.morin@orange.com Fri Mar 23 04:03:45 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABC521F846F for ; Fri, 23 Mar 2012 04:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 0XmF+-9JK4Oc for ; Fri, 23 Mar 2012 04:03:41 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6482F21F846C for ; Fri, 23 Mar 2012 04:03:40 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 252E24110B7; Fri, 23 Mar 2012 12:03:39 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 193AB41109A; Fri, 23 Mar 2012 12:03:39 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 12:03:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.193.21.179 ([10.193.21.179]) by ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) via Exchange Front-End Server owa.rd.francetelecom.fr ([10.192.128.53]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Mar 2012 11:03:38 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD08E4.995CEA7C" Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 Content-class: urn:content-classes:message Date: Fri, 23 Mar 2012 12:04:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-netmod-routing-cfg Thread-Index: Ac0I5JlflUXJIU0CST6qQ/i+1c/wJQ== From: To: X-OriginalArrivalTime: 23 Mar 2012 11:03:38.0790 (UTC) FILETIME=[99B42C60:01CD08E4] Cc: draft-ietf-netmod-routing-cfg.all@tools.ietf.org, rtg-dir@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-netmod-routing-cfg X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 11:03:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD08E4.995CEA7C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sIA0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyBSb3V0aW5nIERpcmVjdG9yYXRlIHJl dmlld2VyIGZvciBhbiBlYXJseSByZXZpZXcgb2YgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGly ZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBk cmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3 LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhpcyBwYXJ0aWN1bGFyIGNhc2Ug aXMgYW4gZWFybHkgcmV2aWV3IHJlcXVlc3RlZCBieSBSb3V0aW5nIEFEcywgd2l0aCB0aGUgZ29h bCBvZiBhc3Nlc3NpbmcgdGhlIHJlbGV2YW5jZSBvZiB0aGUgd29yayBhbmQgZXZlbnR1YWxseSBw cm92aWRlIGd1aWRhbmNlLg0KDQoNCkFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJp bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCBjYW4gYmUgaGVscGZ1bCBpZiB5 b3UgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBjb21tZW50cyB0aGF0IHlvdSBy ZWNlaXZlLg0KDQpGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3Rv cmF0ZSwgcGxlYXNlIHNlZSBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3JhdGUvcm91 dGluZy5odG1sIA0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMDIN ClJldmlld2VyOiBUaG9tYXMgTW9yaW4NClJldmlldyBEYXRlOiAyMDEyLTAzLTIyDQpJbnRlbmRl ZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KDQoNClN1bW1hcnk6IA0KDQpNeSBvdmVyYWxsIGlt cHJlc3Npb24gb2YgdGhpcyBkb2N1bWVudCBpcyByYXRoZXIgcG9zaXRpdmUsIGl0IHNlZW0gdG8g bWUgYXMgcHJvdmlkaW5nIGEgZ29vZCBzdGFydGluZyBwb2ludCBmb3IgY292ZXJpbmcgcm91dGlu ZyB0YWJsZXMgYW5kIHJvdXRpbmcgcHJvdG9jb2xzIGluIG5ldG1vZC4gDQoNCkhvd2V2ZXIsIEkg dGhpbmsgdGhlcmUgaXMgcG9zc2libHkgc29tZSByb29tIGZvciBpbXByb3ZlbWVudCBmb3IgbWFr aW5nIHRoaXMgYmFzZSBZYW5nIHJvdXRpbmcgbW9kdWxlIGdlbmVyaWMgZW5vdWdoIHRvIHJlYWxs eSBiZSBhcHBsaWNhYmxlIHRvIGFsbCByb3V0aW5nIHByb3RvY29scyBhbmQgdXNlIGNhc2VzLiAg U2VlICBiZWxvdyBmb3IgbW9yZSBzcGVjaWZpYyBxdWVzdGlvbnMvc3VnZ2VzdGlvbnMsIGdlbmVy aWMgb3IgcmVsYXRlZCB0byBzcGVjaWZpYyBwcm90b2NvbHMgb3IgdXNlIGNhc2VzIChFQ01QIHN1 cHBvcnQsIG11bHRpY2FzdCwgTVBMUy9CR1AgVlBOcywgZXRjLikuDQoNCg0KSXQgaXMgYWxzbyBp bXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZSB1c2VmdWxuZXNzIG9mIHRoZXNlIHNwZWNzIGlzIGNv bmRpdGlvbmVkIChhKSBieSB0aGUgZGV2ZWxvcG1lbnQgb2YgWWFuZyBtb2R1bGVzIGZvciBlYWNo IHJlbGV2YW50IHJvdXRpbmcgcHJvdG9jb2wgKHdoaWNoIHNob3VsZCBiZSBmYWlybHkgZG9hYmxl IGFzc3VtaW5nIHRoaXMgYmFzZSBtb2R1bGUgaXMgZ2VuZXJpYyBlbm91Z2gpIGFuZCAoYikgY29u ZGl0aW9uZWQgYnkgdGhlIGRldmVsb3BtZW50IG9mIGFkZGl0aW9uYWwgWWFuZyBtb2R1bGVzIGFs bG93aW5nIHRoZSBkZXNjcmlwdGlvbiBvZiBub24tdHJpdmlhbCBpbXBvcnQvZXhwb3J0IGZpbHRl cnMgYmV0d2VlbiByb3V0aW5nIHByb3RvY29scyBhbmQgcm91dGluZyB0YWJsZXMgKHRoaXMgcGFy dCBiZWluZyBwb3NzaWJseSBoYXJkZXIgdG8gYWNoaWV2ZSwgc2luY2UgaXQgbWVhbnMgZmluZGlu ZyBhIGNvbW1vbiBsYW5ndWFnZSBhYmxlIHRvIGV4cHJlc3MgdGhlIHZhcmlldHkgb2YgQUNMcy9w b2xpY2llcyB0aGF0IGNhbiBiZSBleHByZXNzZWQgb24gZGlmZmVyZW50IHJvdXRlciBPU2VzIHRv ZGF5KS4NCg0KDQpDb21tZW50czoNCg0KLS0tIE5vdGUgV2VsbCAuLi4NCg0KSSdtIGhvcGluZyB0 aGlzIHJldmlldyB3aWxsIGJlIHJlbGV2YW50IGFuZCB1c2VmdWwuIEJ1dCwga2VlcGluZyBpbiBt aW5kIHRoYXQgZG9pbmcgdGhpcyByZXZpZXcgd2FzIG15IGZpcnN0IGV4cG9zdXJlIGF0IFlhbmcs IHNvbWUgY29tbWVudHMgSSdtIG1ha2luZyBjb3VsZCBwb3NzaWJseSBiZSBjb21wbGV0ZWx5IG9m ZiB0cmFjaywgYW5kIHdoYXQgSSB0aGluayBJIHVuZGVyc3Rvb2QgY291bGQgYXMgd2VsbCBiZSwg cGFydGx5IG9yIGZ1bGx5LCB3cm9uZy4gSWYvd2hlbiB0aGlzIGhhcHBlbnMgdG8gYmUgdGhlIGNh c2UsIEkgYXBvbG9naXplOyBqdXN0IGJlIGZyYW5rIGFuZCBob25lc3QgYW5kIGV2ZW50dWFsbHkg dGVsbCBtZSB0byBnbyBiYWNrIGhvbWUgYW5kIHJlYWQgYSBmZXcgb3RoZXIgc3BlY3MgYmVmb3Jl IEkgY29tZSBiYWNrLi4uIDstKQ0KDQpUaGVyZSB3YXMgb25lIHNwZWNpZmljIGRpZmZpY3VsdHkg Zm9yIGRvaW5nIHRoaXMgcmV2aWV3OiBmb3Igc29tZW9uZSBsYWNraW5nIFhQYXRoIGZsdWVuY3ks IGl0IGlzIGhhcmQgdG8gdW5kZXJzdGFuZCBzb21lIGRldGFpbHMgb2YgdGhlIFlhbmQgbW9kdWxl cy4gRm9yIGluc3RhbmNlLCB0aGVyZSBpcyBhIGNvbXBsZXggY29uZGl0aW9uIGZvciByb3V0aW5n LXByb3RvY29sL2Nvbm5lY3RlZC1yb3V0aW5nLXRhYmxlcywgYW5kIGl0IHdvdWxkIGhhdmUgcmVt YWluZWQgdG90YWxseSBvYnNjdXJlIHRvIG1lIHdpdGhvdXQgdGhlIGVycm9yLW1lc3NhZ2UgdGhh dCBpcyBhbHNvIHByb3ZpZGVkIDsgdGhlIGNvcnJlc3BvbmRpbmcgY29uc3RyYWludCB3YXMgYWxz byBleHBsYWluZWQgaW4gdGhlIEludHJvIG9mIHNlY3Rpb24gNCwgc28gdGhpcyBwYXJ0aWN1bGFy IGNhc2Ugd2FzIG9rIChzZWUgbW9yZSBwcmVjaXNlIGNvbW1lbnQgYmVsb3cpLiBCZXlvbmQgdGhp cyBleGFtcGxlLCB0aGUgcmVhbCBpc3N1ZSBpcyB0aGF0IEkgY2FuJ3Qga25vdyBpZiB0aGVyZSBp cyBhbnkgb3RoZXIgc2ltaWxhciBYUGF0aCBjb25zdHJhaW50IG9yIG90aGVyIGRldGFpbCB0aGF0 IEkgbWlnaHQgaGF2ZSBtaXNzZWQuDQoNCg0KLS0gRG9jdW1lbnQgb3JnYW5pemF0aW9uDQoNClRo ZSBpbnRlcmZhY2UgcGFyYW1ldGVycyBmb3IgSVB2NiBOZWlnaGJvciBEaXNjb3Zlcnkgd291bGQg SSB0aGluayBkZXNlcnZlIGJlaW5nIG1vdmVkIGluIGEgY29tcGFuaW9uIFlhbmcgbW9kdWxlLCB1 bmxlc3MgdGhlcmUgaXMgYSBzdHJvbmcgcmVhc29uIChzdWNoIGFzIGEgZGVwZW5kZW5jeSkgd2h5 IGl0IHdvdWxkIGJlIG5lZWRlZCB0byBiZSBrZXB0IGhlcmUuDQoNCg0KLS0tIEV4dGVuc2liaWxp dHkNCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGVzZSBzcGVjcyB3aGVyZSB3cml0dGVuIHdpdGgg ZXh0ZW5zaWJpbGl0eSBpbiBtaW5kLCB3aGljaCBpcyBhIHZlcnkgcG9zaXRpdmUgcG9pbnQuIE9u ZSByb3V0aW5nIHByb3RvY29sIGV4YW1wbGUgaXMgZ2l2ZW4gKFJJUCksIGJ1dCB0aGUgc3RydWN0 dXJlIGlzIHN1cHBvc2VkbHkgYXBwbGljYWJsZSB0byBvdGhlciByb3V0aW5nIHByb3RvY29scy4g WW91IHdpbGwgZmluZCBiZWxvdyBhIGZldyBxdWVzdGlvbnMgcmVsYXRlZCB0byB0aGUgZ2VuZXJp Y25lc3MsIGluIGZhY3QgbW9zdGx5IGNhc2VzIHRoYXQgbWF5IHNob3cgdGhhdCB0aGUgY3VycmVu dCBzcGVjcyBtYXkgbm90IGJlIGdlbmVyaWMgZW5vdWdoIHdpdGggc3VnZ2VzdGlvbnMgb24gcG9z c2libGUgZml4ZXMuDQoNCg0KLS0tIENvbXBsZXRlbmVzcw0KDQpPbmUgcXVlc3Rpb24gaXMgaG93 IHRoZXNlIFlhbmcgbW9kdWxlcyBjYW4gYmUgdXNlZCB0b2RheS4gSXQgaXMgY2xlYXIgdGhhdCB3 aXRob3V0IGNvbXBhbmlvbiBzcGVjcyBmb3Igc3BlY2lmaWMgcHJvdG9jb2xzIGFuZCBmaWx0ZXJz LCBub3QgdmVyeSBtdWNoIGNhbiBiZSBkb25lIHdpdGggaXQgKG1lcmVseSBzdGF0aWMgcm91dGlu ZyB3aXRoIG9ubHkgdHJpdmlhbCBhY2NlcHQtYWxsIC8gZGVueS1hbGwgZmlsdGVycykuIEl0IGlz IHBlcmZlY3RseSBhY2tub3dsZWRnZWQgaW4gdGhlIGRvY3VtZW50LiAgT25lIHBhcnQgdGhhdCBt YXkgcHJvdmUgaGFyZCB0byBhY2hpZXZlIGlzIHRoZSB1bmlmaWNhdGlvbiBvZiB0aGUgdmFyaWV0 eSBvZiBBQ0wvcG9saWNpZXMgZXhpc3Rpbmcgb24gZGlmZmVyZW50IHJvdXRpbmcgZXF1aXBtZW50 IHZlbmRvcnMgT1NlcywgaW50byBvbmUgY29tbW9uIFlhbmcgbGFuZ3VhZ2UgZm9yIHJvdXRpbmcg ZmlsdGVycy4NCg0KDQotLS0gIEluZm9ybWF0aW9uIG9uIHJvdXRlcw0KDQpUaGUgWWFuZyBtb2R1 bGUgbGV0J3MgdGhlIG9wZXJhdG9yIHJlYWQgdGhlIHJvdXRpbmcgdGFibGVzLiBJdCBsb29rcyBs aWtlIGEgdmVyeSB2YWxpZCBhbmQgdXNlZnVsIHRoaW5nIChhbmQgbm90IG5ldywgc2VlIFJGQzEy MTMgTUlCKS4gDQoNCkhvd2V2ZXIsIEknbSB3b25kZXJpbmcgYWJvdXQgdGhlIGZvbGxvd2luZyBw b2ludHM6DQoNCi0gdXN1YWxseSwgYSByb3V0aW5nIHRhYmxlIG1heSBoYXZlIG11bHRpcGxlIHJv dXRlcyBmb3IgYSBzYWlkIGRlc3RpbmF0aW9uIGFkZHJlc3MsIHNvbWUgYmVpbmcgcG9zc2libHkg bGVzcyBzcGVjaWZpYyB0aGFuIG90aGVycywgb3IgaW5hY3RpdmUgZHVlIHRvIHZhcmlvdXMgcmVh c29ucyA6IGl0IGRpZCBub3QgaWRlbnRpZnkgaG93IHRoZXNlIHNwZWNpZmljYXRpb24gYWxsb3cg dGhlIG9wZXJhdG9yIHRvIHNlZSBhbGwgcm91dGVzIG9mIGEgcm91dGluZyB0YWJsZSBmb3IgYSBz YWlkIHByZWZpeCwgb3IgYWxsIHRoZSBtb3N0IHNwZWNpZmljIHJvdXRlcyBpbmNsdWRpbmcgdGhl IGluYWN0aXZlIG9uZXMsIG9yIGFsbCB0aGUgbW9zdCBzcGVjaWZpYyBhY3RpdmVzIHJvdXRlcyB3 aGVuIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgKHJlcXVpcmVkIEkgdGhpbmsgZm9yIEVDTVAgc3Vw cG9ydCksIGV0Yy4gPyBpdCBzZWVtcyBpdCB3b3VsZCBiZSB3b3J0aCB0byBleHRlbmQgdGhlIGdl dC1yb3V0ZSBSUEMgdG8gYWxsb3cgZXhwcmVzc2luZyBhbGwgdGhlc2Uga2luZCBvZiBxdWVzdGlv bnMNCg0KLSB3aGVuIGR1bXBpbmcgYSBmdWxsIHJvdXRpbmcgdGFibGUsIHdpbGwgdGhpcyBiZSBl ZmZpY2llbnQgPyB3b3VsZG4ndCBpdCBiZSBtb3JlIGVmZmljaWVudCB0byByZWx5IG9uIG90aGVy IGRlZGljYXRlZCBtZWNoYW5pc20gYWxyZWFkeSB1c2VkIHRvZGF5IHRvIGdldCBrbm93bGVkZ2Ug b2YgYSByb3V0aW5nIHByb3RvY29sIChlLmcuIEJDUCBvciBSb3V0ZSBSZWZsZWN0aW9uIGZvciBC R1AsIG9yIElHUCB0YXBwaW5nIHRlY2huaXF1ZXMgZm9yIElHUHMpIA0KDQotIGFzc3VtaW5nIHRo YXQgaW4gc29tZSBjYXNlcyBkdW1waW5nIHdob2xlIHJvdXRpbmcgdGFibGVzIHdvdWxkIG5vdCBi ZSBlZmZpY2llbnQsIHdpbGwgdGhlcmUgYmUgYW4gZWZmaWNpZW50IHdheSB0byBnZXQgYWdncmVn YXRlIGluZm9ybWF0aW9uIG9uIGEgcm91dGluZyB0YWJsZSA7IHN1Y2ggYXMgImhvdyBtYW55IHJv dXRlcyBpbiB0aGUgcm91dGluZyB0YWJsZSIgPyBvciAiaG93IG1hbnkgaW5hY3RpdmUgcm91dGVz IGluIHRoZSByb3V0aW5nIHRhYmxlIiA/ICAiaG93IG1hbnkgcm91dGVzIGZvciBwcmVmaXggeC55 LnoiID8NCg0KLSB0aGUgdGVybSAiZGVzdGluYXRpb24tYWRkcmVzcyIgY2hvc2VuIHRvIGRlc2ln bmF0ZSB0aGUgcGllY2Ugb2YgaW5mb3JtYXRpb24gYmFzZWQgb24gd2hpY2ggdGhlIGdldC1yb3V0 ZSBSUEMgd29ya3MsIGlzIHBvc3NpYmx5IG5vdCBzdWl0YWJsZSBmb3IgYWxsIHJvdXRpbmcgcHJv dG9jb2xzLiBUaGUgZXhhbXBsZXMgdGhhdCBJIHdvdWxkIHNlZSBhcmUgKGEpIE1QLUJHUCwgd2hl cmUgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gKE5MUkkpIGNhbiBiZSBtb3N0bHkgYW55dGhpbmcg KGRlcGVuZHMgb24gdGhlIFNBRkkpLCBhbmQgKGIpIG11bHRpY2FzdCwgd2hlcmUgdGhlIHJvdXRp bmcgaW5mb3JtYXRpb24gb24gd2hpY2ggdGhlIFBJTSBwcm90b2NvbHMgd29yayBjYW4gYmUgYSAo c291cmNlLGdyb3VwKSB0dXBsZSwgcG9zc2libHkgYXVnbWVudGVkIHdpdGggZmxhZ3MNCg0KLSAo cmVsYXRlZCB0byB0aGUgcHJldmlvdXMgcG9pbnQ6KSA6IEknbSB1bmNsZWFyIGlmIHRoZXNlIHNw ZWNzIGFsbG93IGEgZ2V0LXJvdXRlIHRvIG1hdGNoIG9uIGRpZmZlcmVudCBwb3J0aW9ucyBvciBh dHRyaWJ1dGVzIG9mIGEgcm91dGVzICAoZWcuIGdldCByb3V0ZSBmb3IgcHJlZml4IFggYWR2ZXJ0 aXNlZCBieSBwZWVyIFgsIG9yIGhhdmluZyBiZWVuIHJlYWR2ZXJ0aXNlZCBieSBBUyBZLi4uKS4u LiBBcyBJIHVuZGVyc3RhbmQsIHRoZXJlIGNhbiBiZSBzb21lIEFGTi9TQUZJIHNwZWNpZmljIGV4 dGVuc2lvbnMsIGJ1dCBubyBwZXItcHJvdG9jb2wgZXh0ZW5zaW9ucy4gSXMgdGhpcyBhIGNvcnJl Y3QgdW5kZXJzdGFuZGluZyA/IElmIG5vdCwgd291bGRuJ3QgaXQgbWFrZSBzZW5zZSB0byBtYWtl IGl0IG1vcmUgZXh0ZW5zaWJsZSA/DQoNCi0gd2h5IHJlc3RyaWN0IHRoZSBnZXQtcm91dGUgUlBD IHRvIG9ubHkgcXVlcnkgdGhlIHNwZWNpYWwvZGVmYXVsdCAiRklCIiByb3V0aW5nIHRhYmxlID8g aXQgd291bGQgc2VlbSB1c2VmdWwgdG8gYmUgYWJsZSB0byBxdWVyeSBhbnkgcm91dGluZyB0YWJs ZS4NCg0KDQoNCi0tLSBSZWRpc3RyaWJ1dGluZyByb3V0ZXMgZGlyZWN0bHkgYmV0d2VlbiByb3V0 aW5nIHByb3RvY29scw0KDQpUaGVzZSBzcGVjaWZpY2F0aW9ucyBvbmx5IGFsbG93IHRoZSBleGNo YW5nZSBvZiByb3V0ZXMgZnJvbSBhIHJvdXRpbmcgcHJvdG9jb2wgb3Igcm91dGluZyB0YWJsZSB0 byBhIHJvdXRpbmcgdGFibGUsIGJ1dCBub3QgZnJvbSBhIHJvdXRpbmcgcHJvdG9jb2wgdG8gYW5v dGhlciByb3V0aW5nIHByb3RvY29scy4gSG93ZXZlciwgdGhlIGxhdHRlciBpcyBzb21ldGhpbmcg dXNlZCBhIGxvdCBpbiBwcmFjdGljZSAoZS5nLiBjb250cm9sbGluZyByZWRpc3RyaWJ1dGlvbiBi ZXR3ZWVuIHR3byBJR1AgYXJlYXMpLiBPZiBjb3Vyc2UsIGJ5IHVzaW5nIGFuIGludGVybWVkaWF0 ZSByb3V0aW5nIHRhYmxlIHlvdSBjb3VsZCBhY2hpZXZlIHRoZSBzYW1lIHJlc3VsdCwgYnV0IGRv ZXNuJ3QgaXQgbG9vayBsaWtlIGV4dHJhIG92ZXJoZWFkID8NCg0KDQotLS0gTW9kaWZ5IHJvdXRl cyBiZWluZyByZWRpc3RyaWJ1dGVkDQoNClRoZXJlIGRvZXMgbm90IHNlZW0gdG8gYmUgYW55IHdh eSB0aHJvdWdoIHdoaWNoIGEgcm91dGUgbWF5IGJlIG1vZGlmaWVkL2F1Z21lbnRlZCBieSBhIGZp bHRlciB3aGVuIGV4cG9ydGVkIGZyb20gYSByb3V0aW5nIHRhYmxlIG9yIHByb3RvY29sIHRvIGFu b3RoZXIuIEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhpcyBpcyBzb21ldGhpbmcgdGhhdCBpcyB1c2Vk IGEgbG90IGluIHByYWN0aWNlLg0KDQoNCi0tLSBNdWx0aXBsZSByb3V0aW5nIGluc3RhbmNlcw0K DQpUaGUgc3BlY3MgYXJlIHdyaXR0ZW4gc28gYXMgdG8gYWxsb3cgbXVsdGlwbGUgInJvdXRlcnMi IHRvIGNvLWV4aXN0IG9uIGFuIGVxdWlwbWVudCBpbiBpc29sYXRpb24sIHdoaWNoIGxvb2tzIHZl cnkgdXNlZnVsLiAgSG93ZXZlciwgSSdtIHdvbmRlcmluZyBpZiBzdWNoIGFuIGFiaWxpdHkgaXMg c3BlY2lmaWMgdG8gInJvdXRpbmciLCBvciBpZiBpdCBzaG91bGRuJ3QgYmUgcGFydCBvZiBhIG1v cmUgZ2VuZXJpYyBZYW5nIG1vZHVsZSwgc28gYXMgdG8gcmV1c2UgdGhlIHNhbWUgc3ViLXJvdXRl ciBoaWVyYXJjaHkgZm9yIHJvdXRpbmcgYW5kIG90aGVyIFlhbmcgbW9kdWxlcy4NCg0KDQotLS0g IEFwcGxpY2FiaWxpdHkgdG8gUkZDNDM2NA0KDQpBbGxvd2luZyBtdWx0aXBsZSAicm91dGVycyIg aXMgYSBnb29kIHN0YXJ0aW5nIHBvaW50IGZvciB1c2luZyB0aGVzZSBzcGVjcyBpbiB0aGUgY29u dGV4dCBvZiBSRkM0MzY0IChNUExTL0JHUCBJUCBWUE5zKS4gSG93ZXZlciwgaWYgSSB1bmRlcnN0 YW5kIGNvcnJlY3RseSBZYW5nIHN5bnRheCwgdGhlIHdheSB0aGUgZmlsdGVycyBhcmUgZGVmaW5l ZCB3b3VsZCBub3Qgd29yayBpbiB0aGUgY29udGV4dCBvZiBSRkM0MzY0LCB3aGVyZSBhIEJHUCBy b3V0aW5nIGluc3RhbmNlIGluIHRoZSBtYXN0ZXIgInJvdXRlciIgZXhwb3J0cyBzZWxlY3RlZCBy b3V0ZXMgaW4gZWFjaCBvZiB0aGUgcm91dGluZyB0YWJsZSBvZiBlYWNoIFZQTiAoVlJGKS4gIFRo ZSBWUkYgYWxzbyBleHBvcnQgcm91dGVzIHRvIHRoZSBtYXN0ZXIgaW5zdGFuY2UuDQoNClRoZSB0 d28gb2JzdGFjbGVzIEkgd291bGQgc2VlIChJIG1pZ2h0IGJlIHdyb25nKSBhcmUgdGhlIGZvbGxv d2luZzoNCi0gbm8gd2F5IHRvIG1vZGlmeSByb3V0ZXMgd2hpbGUgdGhleSBhcmUgaW1wb3J0ZWQv ZXhwb3J0ZWQgOiB0aGUgUkZDNDM2NCB1c2UtY2FzZSB3b3VsZCByZXF1aXJlIHRoZSBhYmlsaXR5 IHRvIChhdCBsZWFzdCkgYWRkL3N0cmlwIGF0dHJpYnV0ZXMgdG8vZnJvbSB0aGUgcm91dGVzDQot IG5vIHdheSB0byByZWRpc3RyaWJ1dGUgcm91dGVzIGJldHdlZW4gcm91dGluZyB0YWJsZXMgb2Yg ZGlmZmVyZW50ICJyb3V0ZXJzIiAod2hhdCBsZXQgbWUgdGhpbmsgdGhpcyBjb25zdHJhaW50IGV4 aXN0cyBpcyAoYSkgdGhlIGluYWJpbGl0eSB0byBuYW1lIGEgcm91dGVyIHdoZW4gZGVzaWduYXRp bmcgYSByb3V0aW5nLXRhYmxlIHRvIGltcG9ydC9leHBvcnQgZnJvbS90bywgYW5kIChiKSB0aGUg WFBhdGhzIGZvciBjb25uZWN0ZWQtcm91dGluZy10YWJsZXMvcm91dGluZy10YWJsZS9uYW1lIGFu ZCByZWNpcGllbnQtcm91dGluZy10YWJsZXMgcmVjaXBpZW50LW5hbWUsIHdoaWNoIHNlZW1zIHRv IG5vdCBiZSBhYmxlIHRvIHBvaW50IGhpZ2hlciBpbiB0aGUgaGllcmFyY2h5IHRoYW4gdGhlICdy b3V0ZXInIG9uIHdoaWNoIHRoZXkgYXJlIGRlZmluZWQgKQ0KLSB0aGUgY29uc3RyYWludCB0aGF0 IGZvciBhIHNhaWQgcm91dGluZyBwcm90b2NvbHMgIkZvciBlYWNoIEFGTi9TQUZJIHBhaXIgdGhl cmUgbWF5IGJlIGF0IG1vc3Qgb25lIGNvbm5lY3RlZCByb3V0aW5nIHRhYmxlLiIgLiBJbiB0aGUg UkZDNDM2NCBjYXNlLCB0aGUgZ2xvYmFsIEJHUCByb3V0aW5nIHByb2Nlc3Mgd291bGQgcHVzaCBy b3V0ZXMgdG8gbXVsdGlwbGUgVlJGcy4NCg0KDQotLS0gRW5hYmxpbmcvZGlzYWJsaW5nIGFuIGlu dGVyZmFjZQ0KDQpTb21ldGhpbmcgZG9uZSB2ZXJ5IG9mdGVuIG9uIGEgcm91dGVyIGNvbnNpc3Rz IGluIHB1dHRpbmcgYW4gaW50ZXJmYWNlICJzaHV0ZG93biIgb3IgImluYWN0aXZlIiwgcHJlc2Vy dmluZyBpdHMgY29uZmlndXJhdGlvbiBidXQgbWFraW5nIGl0IGlnbm9yZWQgYnkgdGhlIHJvdXRl ciBhbmQga2VlcGluZyB0aGUgbGluayBkb3duLiAgVGhlc2Ugc3BlY2lmaWNhdGlvbnMgZG9uJ3Qg c2VlbSB0byBwcm92aWRlIHRoaXMuICBJcyB0aGlzIHNvbWV0aGluZyBhbHJlYWR5LCBvciBleHBl Y3RlZCB0byBiZSwgcHJvdmlkZWQgYnkgYW5vdGhlciBZYW5nIGV4dGVuc2lvbiA/IA0KDQpJZiBz bywgaG93IHdvdWxkIHRoZSB0d28gaW50ZXJhY3QsIGlmIGZvciBpbnN0YW5jZSwgYW4gaW50ZXJm YWNlIGlzIHNodXRkb3duIGluIHRoaXMgb3RoZXIgbW9kdWxlIGJ1dCB1c2VkIGluIHRoZSByb3V0 aW5nIG1vZHVsZSA/DQoNCg0KLS0tIEVuYWJsaW5nL0Rpc2FibGluZyBhIHByb3RvY29sIG9uIGFu IGludGVyZmFjZSwgb3IgbW9kaWZ5aW5nIHByb3RvY29sIHBlci1pbnRlcmZhY2UgcGFyYW1ldGVy cw0KDQpTb21ldGhpbmcgZG9uZSB2ZXJ5IG9mdGVuIG9uIGEgcm91dGVyIGNvbnNpc3RzIGluIGVu YWJsaW5nL2Rpc2FibGluZyBhIHNhaWQgcHJvdG9jb2wgb24gYSBzYWlkIGludGVyZmFjZSwgb3Ig bW9yZSBnZW5lcmFsbHkgbW9kaWZ5aW5nIHBhcmFtZXRlcnMgZm9yIGEgc2FpZCBwcm90b2NvbCBv biBhIHNhaWQgaW50ZXJmYWNlICh0eXBpY2FsIGV4YW1wbGUgYmVpbmcgdGhlIG1ldHJpYykuICBB cyBJIHVuZGVyc3RhbmQgdGhpcyB3b3VsZCBiZSBhbGxvd2VkIGJ5IHRoZXNlIHNwZWNzIGJ5IGhh dmluZyBhIG1vZHVsZSBleHRlbmRpbmcgcHJvdG9jb2wgWCBhdWdtZW50IHJvdXRpbmcvcm91dGVy L2ludGVyZmFjZSB3aXRoIGl0cyBvd24gcGFyYW1ldGVycy4gIEhvd2V2ZXIsIEknbSB3b25kZXJp bmcgaWYgdGhlc2UgcGVyLXByb3RvY29sIHBlci1pbnRlcmZhY2UgcGFyYW1ldGVycyB3b3VsZG4n dCBiZSBiZXR0ZXIgcGxhY2VkIHVuZGVyIGVhY2ggcm91dGluZy9yb3V0ZXIvcm91dGluZy1wcm90 b2NvbFtYXS4gDQoNClRoZSByZWFzb25zIEkgc2VlIGFyZSB0aGUgZm9sbG93aW5nOg0KKiBpbiBz b21lIGNhc2VzIGEgc2FpZCByb3V0ZXIgbWF5IHJ1biBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgYSBz YWlkIHByb3RvY29sIHR5cGUsIGluIHBhcmFsbGVsLCBhbmQgeW91IG1heSBuZWVkIHRvIGhhdmUg YSB3YXkgdG8gZGlmZmVyZW50aWF0ZSBlbmFibGluZyBpbnN0YW5jZSBBIG9mIHByb3RvY29sIFgg ZnJvbSBpbnN0YW5jZSBCIG9mIHByb3RvY29sIFgNCiogeW91IGNvdWxkIGV2ZW4gZmluZCB1c2Ug Y2FzZXMgd2hlcmUgYSBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgYSBzYWlkIHByb3RvY29sIHR5cGUg cnVuIGluIHBhcmFsbGVsIG9uIGEgc2FpZCBpbnRlcmZhY2UgKGVnLiBtdWx0aSBpbnN0YW5jZSBJ U0lTKQ0KKiBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBZYW5nIG1vZHVsZSBpcyB0aGF0IHRoZSBj dXJyZW50IHN0cnVjdHVyZSB3b3VsZCBub3QgYWxsb3cgYXVnbWVudGluZyBhIHNhaWQgaW50ZXJm YWNlIG11bHRpcGxlIHRpbWVzIGZvciBhIHNhbWUgcGFyYW1ldGVyIG9mIGEgc2FpZCBwcm90b2Nv bCB0eXBlLg0KDQoNCi0tLSBFZGl0b3JpYWwgYXNwZWN0cy4uLg0KDQpBbHRob3VnaCBpdCdzIG5v dCB0aGUgcHJpbWFyeSBwdXJwb3NlIG9mIHRoaXMgcmV2aWV3LCBJIGhhdmUgdG8gbWVudGlvbiB0 aGF0IHRoZSBlZGl0b3JpYWwgcXVhbGl0eSBvZiB0aGUgZG9jdW1lbnQgaXMgZXhjZWxsZW50IDsg SSBoYXZlIHBhcnRpY3VsYXJseSBhcHByZWNpYXRlZCB0aGUgSFRNTC1yZW5kZXJlZCB2ZXJzaW9u IHByb2R1Y2VkIGJ5IHRoZSBYTUwgUkZDIGVkaXRpbmcgdG9vbGNoYWluLiANCg0KDQo= ------_=_NextPart_001_01CD08E4.995CEA7C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIA0KICA8L2hlYWQ+DQogIDxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KICAgIEhlbGxvLA0KICAgIDxwPkkgaGF2ZSBiZWVuIHNlbGVj dGVkIGFzIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIGFuIGVhcmx5DQogICAgICBy ZXZpZXcgb2YgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2 aWV3IGFsbA0KICAgICAgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdA0KICAgICAgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBz b21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGlzDQogICAgICBwYXJ0aWN1bGFyIGNhc2Ug aXMgYW4gZWFybHkgcmV2aWV3IHJlcXVlc3RlZCBieSBSb3V0aW5nIEFEcywgd2l0aA0KICAgICAg dGhlIGdvYWwgb2YgYXNzZXNzaW5nIHRoZSByZWxldmFuY2Ugb2YgdGhlIHdvcmsgYW5kIGV2ZW50 dWFsbHkNCiAgICAgIHByb3ZpZGUgZ3VpZGFuY2UuPGJyPg0KICAgIDwvcD4NCiAgICA8cD5BbHRo b3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0 aW5nDQogICAgICBBRHMsIGl0IGNhbiBiZSBoZWxwZnVsIGlmIHlvdSBjb25zaWRlciB0aGVtIGFs b25nIHdpdGggYW55IG90aGVyDQogICAgICBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLjwvcD4N CiAgICA8cD5Gb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0 ZSwgcGxlYXNlIHNlZSA8YQ0KICAgICAgICBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0Ig0K ICAgICAgICBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3JhdGUvcm91dGlu Zy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3JhdGUvcm91dGluZy5odG1s PC9hPg0KICAgIDwvcD4NCiAgICBEb2N1bWVudDogZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1j ZmctMDI8YnI+DQogICAgUmV2aWV3ZXI6IFRob21hcyBNb3Jpbjxicj4NCiAgICBSZXZpZXcgRGF0 ZTogMjAxMi0wMy0yMjxicj4NCiAgICBJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjazxi cj4NCiAgICA8cD48c3Ryb25nPlN1bW1hcnk6PC9zdHJvbmc+IDwvcD4NCiAgICBNeSBvdmVyYWxs IGltcHJlc3Npb24gb2YgdGhpcyBkb2N1bWVudCBpcyByYXRoZXIgcG9zaXRpdmUsIGl0IHNlZW0N CiAgICB0byBtZSBhcyBwcm92aWRpbmcgYSBnb29kIHN0YXJ0aW5nIHBvaW50IGZvciBjb3Zlcmlu ZyByb3V0aW5nIHRhYmxlcw0KICAgIGFuZCByb3V0aW5nIHByb3RvY29scyBpbiBuZXRtb2QuIDxi cj4NCiAgICA8YnI+DQogICAgSG93ZXZlciwgSSB0aGluayB0aGVyZSBpcyBwb3NzaWJseSBzb21l IHJvb20gZm9yIGltcHJvdmVtZW50IGZvcg0KICAgIG1ha2luZyB0aGlzIGJhc2UgWWFuZyByb3V0 aW5nIG1vZHVsZSBnZW5lcmljIGVub3VnaCB0byByZWFsbHkgYmUNCiAgICBhcHBsaWNhYmxlIHRv IGFsbCByb3V0aW5nIHByb3RvY29scyBhbmQgdXNlIGNhc2VzLsKgIFNlZcKgIGJlbG93IGZvcg0K ICAgIG1vcmUgc3BlY2lmaWMgcXVlc3Rpb25zL3N1Z2dlc3Rpb25zLCBnZW5lcmljIG9yIHJlbGF0 ZWQgdG8gc3BlY2lmaWMNCiAgICBwcm90b2NvbHMgb3IgdXNlIGNhc2VzIChFQ01QIHN1cHBvcnQs IG11bHRpY2FzdCwgTVBMUy9CR1AgVlBOcywNCiAgICBldGMuKS48YnI+DQogICAgPHA+SXQgaXMg YWxzbyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZSB1c2VmdWxuZXNzIG9mIHRoZXNlIHNwZWNz DQogICAgICBpcyBjb25kaXRpb25lZCAoYSkgYnkgdGhlIGRldmVsb3BtZW50IG9mIFlhbmcgbW9k dWxlcyBmb3IgZWFjaA0KICAgICAgcmVsZXZhbnQgcm91dGluZyBwcm90b2NvbCAod2hpY2ggc2hv dWxkIGJlIGZhaXJseSBkb2FibGUgYXNzdW1pbmcNCiAgICAgIHRoaXMgYmFzZSBtb2R1bGUgaXMg Z2VuZXJpYyBlbm91Z2gpIGFuZCAoYikgY29uZGl0aW9uZWQgYnkgdGhlDQogICAgICBkZXZlbG9w bWVudCBvZiBhZGRpdGlvbmFsIFlhbmcgbW9kdWxlcyBhbGxvd2luZyB0aGUgZGVzY3JpcHRpb24g b2YNCiAgICAgIG5vbi10cml2aWFsIGltcG9ydC9leHBvcnQgZmlsdGVycyBiZXR3ZWVuIHJvdXRp bmcgcHJvdG9jb2xzIGFuZA0KICAgICAgcm91dGluZyB0YWJsZXMgKHRoaXMgcGFydCBiZWluZyBw b3NzaWJseSBoYXJkZXIgdG8gYWNoaWV2ZSwgc2luY2UNCiAgICAgIGl0IG1lYW5zIGZpbmRpbmcg YSBjb21tb24gbGFuZ3VhZ2UgYWJsZSB0byBleHByZXNzIHRoZSB2YXJpZXR5IG9mDQogICAgICBB Q0xzL3BvbGljaWVzIHRoYXQgY2FuIGJlIGV4cHJlc3NlZCBvbiBkaWZmZXJlbnQgcm91dGVyIE9T ZXMNCiAgICAgIHRvZGF5KS48YnI+DQogICAgPC9wPg0KICAgIDxvbCB0eXBlPSJjaXJjbGUiPg0K ICAgIDwvb2w+DQogICAgPHA+PHN0cm9uZz5Db21tZW50czo8L3N0cm9uZz48L3A+DQogICAgLS0t IE5vdGUgV2VsbCAuLi48YnI+DQogICAgPGJyPg0KICAgIEknbSBob3BpbmcgdGhpcyByZXZpZXcg d2lsbCBiZSByZWxldmFudCBhbmQgdXNlZnVsLiBCdXQsIGtlZXBpbmcgaW4NCiAgICBtaW5kIHRo YXQgZG9pbmcgdGhpcyByZXZpZXcgd2FzIG15IGZpcnN0IGV4cG9zdXJlIGF0IFlhbmcsIHNvbWUN CiAgICBjb21tZW50cyBJJ20gbWFraW5nIGNvdWxkIHBvc3NpYmx5IGJlIGNvbXBsZXRlbHkgb2Zm IHRyYWNrLCBhbmQgd2hhdA0KICAgIEkgdGhpbmsgSSB1bmRlcnN0b29kIGNvdWxkIGFzIHdlbGwg YmUsIHBhcnRseSBvciBmdWxseSwgd3JvbmcuDQogICAgSWYvd2hlbiB0aGlzIGhhcHBlbnMgdG8g YmUgdGhlIGNhc2UsIEkgYXBvbG9naXplOyBqdXN0IGJlIGZyYW5rIGFuZA0KICAgIGhvbmVzdCBh bmQgZXZlbnR1YWxseSB0ZWxsIG1lIHRvIGdvIGJhY2sgaG9tZSBhbmQgcmVhZCBhIGZldyBvdGhl cg0KICAgIHNwZWNzIGJlZm9yZSBJIGNvbWUgYmFjay4uLiA7LSk8YnI+DQogICAgPGJyPg0KICAg IFRoZXJlIHdhcyBvbmUgc3BlY2lmaWMgZGlmZmljdWx0eSBmb3IgZG9pbmcgdGhpcyByZXZpZXc6 IGZvciBzb21lb25lDQogICAgbGFja2luZyBYUGF0aCBmbHVlbmN5LCBpdCBpcyBoYXJkIHRvIHVu ZGVyc3RhbmQgc29tZSBkZXRhaWxzIG9mIHRoZQ0KICAgIFlhbmQgbW9kdWxlcy4gRm9yIGluc3Rh bmNlLCB0aGVyZSBpcyBhIGNvbXBsZXggY29uZGl0aW9uIGZvcg0KICAgIHJvdXRpbmctcHJvdG9j b2wvY29ubmVjdGVkLXJvdXRpbmctdGFibGVzLCBhbmQgaXQgd291bGQgaGF2ZQ0KICAgIHJlbWFp bmVkIHRvdGFsbHkgb2JzY3VyZSB0byBtZSB3aXRob3V0IHRoZSBlcnJvci1tZXNzYWdlIHRoYXQg aXMNCiAgICBhbHNvIHByb3ZpZGVkIDsgdGhlIGNvcnJlc3BvbmRpbmcgY29uc3RyYWludCB3YXMg YWxzbyBleHBsYWluZWQgaW4NCiAgICB0aGUgSW50cm8gb2Ygc2VjdGlvbiA0LCBzbyB0aGlzIHBh cnRpY3VsYXIgY2FzZSB3YXMgb2sgKHNlZSBtb3JlDQogICAgcHJlY2lzZSBjb21tZW50IGJlbG93 KS4gQmV5b25kIHRoaXMgZXhhbXBsZSwgdGhlIHJlYWwgaXNzdWUgaXMgdGhhdA0KICAgIEkgY2Fu J3Qga25vdyBpZiB0aGVyZSBpcyBhbnkgb3RoZXIgc2ltaWxhciBYUGF0aCBjb25zdHJhaW50IG9y IG90aGVyDQogICAgZGV0YWlsIHRoYXQgSSBtaWdodCBoYXZlIG1pc3NlZC48YnI+DQogICAgPGJy Pg0KICAgIDxicj4NCiAgICAtLSBEb2N1bWVudCBvcmdhbml6YXRpb248YnI+DQogICAgPGJyPg0K ICAgIFRoZSBpbnRlcmZhY2UgcGFyYW1ldGVycyBmb3IgSVB2NiBOZWlnaGJvciBEaXNjb3Zlcnkg d291bGQgSSB0aGluaw0KICAgIGRlc2VydmUgYmVpbmcgbW92ZWQgaW4gYSBjb21wYW5pb24gWWFu ZyBtb2R1bGUsIHVubGVzcyB0aGVyZSBpcyBhDQogICAgc3Ryb25nIHJlYXNvbiAoc3VjaCBhcyBh IGRlcGVuZGVuY3kpIHdoeSBpdCB3b3VsZCBiZSBuZWVkZWQgdG8gYmUNCiAgICBrZXB0IGhlcmUu PGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgLS0tIEV4dGVuc2liaWxpdHk8YnI+DQogICAg PGJyPg0KICAgIEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlc2Ugc3BlY3Mgd2hlcmUgd3JpdHRlbiB3 aXRoIGV4dGVuc2liaWxpdHkgaW4NCiAgICBtaW5kLCB3aGljaCBpcyBhIHZlcnkgcG9zaXRpdmUg cG9pbnQuIE9uZSByb3V0aW5nIHByb3RvY29sIGV4YW1wbGUNCiAgICBpcyBnaXZlbiAoUklQKSwg YnV0IHRoZSBzdHJ1Y3R1cmUgaXMgc3VwcG9zZWRseSBhcHBsaWNhYmxlIHRvIG90aGVyDQogICAg cm91dGluZyBwcm90b2NvbHMuIFlvdSB3aWxsIGZpbmQgYmVsb3cgYSBmZXcgcXVlc3Rpb25zIHJl bGF0ZWQgdG8NCiAgICB0aGUgZ2VuZXJpY25lc3MsIGluIGZhY3QgbW9zdGx5IGNhc2VzIHRoYXQg bWF5IHNob3cgdGhhdCB0aGUgY3VycmVudA0KICAgIHNwZWNzIG1heSBub3QgYmUgZ2VuZXJpYyBl bm91Z2ggd2l0aCBzdWdnZXN0aW9ucyBvbiBwb3NzaWJsZSBmaXhlcy48YnI+DQogICAgPGJyPg0K ICAgIDxicj4NCiAgICAtLS0gQ29tcGxldGVuZXNzPGJyPg0KICAgIDxicj4NCiAgICBPbmUgcXVl c3Rpb24gaXMgaG93IHRoZXNlIFlhbmcgbW9kdWxlcyBjYW4gYmUgdXNlZCB0b2RheS4gSXQgaXMN CiAgICBjbGVhciB0aGF0IHdpdGhvdXQgY29tcGFuaW9uIHNwZWNzIGZvciBzcGVjaWZpYyBwcm90 b2NvbHMgYW5kDQogICAgZmlsdGVycywgbm90IHZlcnkgbXVjaCBjYW4gYmUgZG9uZSB3aXRoIGl0 IChtZXJlbHkgc3RhdGljIHJvdXRpbmcNCiAgICB3aXRoIG9ubHkgdHJpdmlhbCBhY2NlcHQtYWxs IC8gZGVueS1hbGwgZmlsdGVycykuIEl0IGlzIHBlcmZlY3RseQ0KICAgIGFja25vd2xlZGdlZCBp biB0aGUgZG9jdW1lbnQuwqAgT25lIHBhcnQgdGhhdCBtYXkgcHJvdmUgaGFyZCB0bw0KICAgIGFj aGlldmUgaXMgdGhlIHVuaWZpY2F0aW9uIG9mIHRoZSB2YXJpZXR5IG9mIEFDTC9wb2xpY2llcyBl eGlzdGluZw0KICAgIG9uIGRpZmZlcmVudCByb3V0aW5nIGVxdWlwbWVudCB2ZW5kb3JzIE9TZXMs IGludG8gb25lIGNvbW1vbiBZYW5nDQogICAgbGFuZ3VhZ2UgZm9yIHJvdXRpbmcgZmlsdGVycy48 YnI+DQogICAgPGJyPg0KICAgIDxicj4NCiAgICAtLS3CoCBJbmZvcm1hdGlvbiBvbiByb3V0ZXM8 YnI+DQogICAgPGJyPg0KICAgIFRoZSBZYW5nIG1vZHVsZSBsZXQncyB0aGUgb3BlcmF0b3IgcmVh ZCB0aGUgcm91dGluZyB0YWJsZXMuIEl0IGxvb2tzDQogICAgbGlrZSBhIHZlcnkgdmFsaWQgYW5k IHVzZWZ1bCB0aGluZyAoYW5kIG5vdCBuZXcsIHNlZSBSRkMxMjEzIE1JQikuDQogICAgPGJyPg0K ICAgIDxicj4NCiAgICBIb3dldmVyLCBJJ20gd29uZGVyaW5nIGFib3V0IHRoZSBmb2xsb3dpbmcg cG9pbnRzOjxicj4NCiAgICA8YnI+DQogICAgLSB1c3VhbGx5LCBhIHJvdXRpbmcgdGFibGUgbWF5 IGhhdmUgbXVsdGlwbGUgcm91dGVzIGZvciBhIHNhaWQNCiAgICBkZXN0aW5hdGlvbiBhZGRyZXNz LCBzb21lIGJlaW5nIHBvc3NpYmx5IGxlc3Mgc3BlY2lmaWMgdGhhbiBvdGhlcnMsDQogICAgb3Ig aW5hY3RpdmUgZHVlIHRvIHZhcmlvdXMgcmVhc29ucyA6IGl0IGRpZCBub3QgaWRlbnRpZnkgaG93 IHRoZXNlDQogICAgc3BlY2lmaWNhdGlvbiBhbGxvdyB0aGUgb3BlcmF0b3IgdG8gc2VlIGFsbCBy b3V0ZXMgb2YgYSByb3V0aW5nDQogICAgdGFibGUgZm9yIGEgc2FpZCBwcmVmaXgsIG9yIGFsbCB0 aGUgbW9zdCBzcGVjaWZpYyByb3V0ZXMgaW5jbHVkaW5nDQogICAgdGhlIGluYWN0aXZlIG9uZXMs IG9yIGFsbCB0aGUgbW9zdCBzcGVjaWZpYyBhY3RpdmVzIHJvdXRlcyB3aGVuDQogICAgdGhlcmUg aXMgbW9yZSB0aGFuIG9uZSAocmVxdWlyZWQgSSB0aGluayBmb3IgRUNNUCBzdXBwb3J0KSwgZXRj LiA/DQogICAgaXQgc2VlbXMgaXQgd291bGQgYmUgd29ydGggdG8gZXh0ZW5kIHRoZSBnZXQtcm91 dGUgUlBDIHRvIGFsbG93DQogICAgZXhwcmVzc2luZyBhbGwgdGhlc2Uga2luZCBvZiBxdWVzdGlv bnM8YnI+DQogICAgPGJyPg0KICAgIC0gd2hlbiBkdW1waW5nIGEgZnVsbCByb3V0aW5nIHRhYmxl LCB3aWxsIHRoaXMgYmUgZWZmaWNpZW50ID8NCiAgICB3b3VsZG4ndCBpdCBiZSBtb3JlIGVmZmlj aWVudCB0byByZWx5IG9uIG90aGVyIGRlZGljYXRlZCBtZWNoYW5pc20NCiAgICBhbHJlYWR5IHVz ZWQgdG9kYXkgdG8gZ2V0IGtub3dsZWRnZSBvZiBhIHJvdXRpbmcgcHJvdG9jb2wgKGUuZy4gQkNQ DQogICAgb3IgUm91dGUgUmVmbGVjdGlvbiBmb3IgQkdQLCBvciBJR1AgdGFwcGluZyB0ZWNobmlx dWVzIGZvciBJR1BzKSA8YnI+DQogICAgPGJyPg0KICAgIC0gYXNzdW1pbmcgdGhhdCBpbiBzb21l IGNhc2VzIGR1bXBpbmcgd2hvbGUgcm91dGluZyB0YWJsZXMgd291bGQgbm90DQogICAgYmUgZWZm aWNpZW50LCB3aWxsIHRoZXJlIGJlIGFuIGVmZmljaWVudCB3YXkgdG8gZ2V0IGFnZ3JlZ2F0ZQ0K ICAgIGluZm9ybWF0aW9uIG9uIGEgcm91dGluZyB0YWJsZSA7IHN1Y2ggYXMgImhvdyBtYW55IHJv dXRlcyBpbiB0aGUNCiAgICByb3V0aW5nIHRhYmxlIiA/IG9yICJob3cgbWFueSBpbmFjdGl2ZSBy b3V0ZXMgaW4gdGhlIHJvdXRpbmcgdGFibGUiDQogICAgP8KgICJob3cgbWFueSByb3V0ZXMgZm9y IHByZWZpeCB4LnkueiIgPzxicj4NCiAgICA8YnI+DQogICAgLSB0aGUgdGVybSAiZGVzdGluYXRp b24tYWRkcmVzcyIgY2hvc2VuIHRvIGRlc2lnbmF0ZSB0aGUgcGllY2Ugb2YNCiAgICBpbmZvcm1h dGlvbiBiYXNlZCBvbiB3aGljaCB0aGUgZ2V0LXJvdXRlIFJQQyB3b3JrcywgaXMgcG9zc2libHkg bm90DQogICAgc3VpdGFibGUgZm9yIGFsbCByb3V0aW5nIHByb3RvY29scy4gVGhlIGV4YW1wbGVz IHRoYXQgSSB3b3VsZCBzZWUNCiAgICBhcmUgKGEpIE1QLUJHUCwgd2hlcmUgdGhlIHJvdXRpbmcg aW5mb3JtYXRpb24gKE5MUkkpIGNhbiBiZSBtb3N0bHkNCiAgICBhbnl0aGluZyAoZGVwZW5kcyBv biB0aGUgU0FGSSksIGFuZCAoYikgbXVsdGljYXN0LCB3aGVyZSB0aGUgcm91dGluZw0KICAgIGlu Zm9ybWF0aW9uIG9uIHdoaWNoIHRoZSBQSU0gcHJvdG9jb2xzIHdvcmsgY2FuIGJlIGEgKHNvdXJj ZSxncm91cCkNCiAgICB0dXBsZSwgcG9zc2libHkgYXVnbWVudGVkIHdpdGggZmxhZ3M8YnI+DQog ICAgPGJyPg0KICAgIC0gKHJlbGF0ZWQgdG8gdGhlIHByZXZpb3VzIHBvaW50OikgOiBJJ20gdW5j bGVhciBpZiB0aGVzZSBzcGVjcw0KICAgIGFsbG93IGEgZ2V0LXJvdXRlIHRvIG1hdGNoIG9uIGRp ZmZlcmVudCBwb3J0aW9ucyBvciBhdHRyaWJ1dGVzIG9mIGENCiAgICByb3V0ZXPCoCAoZWcuIGdl dCByb3V0ZSBmb3IgcHJlZml4IFggYWR2ZXJ0aXNlZCBieSBwZWVyIFgsIG9yIGhhdmluZw0KICAg IGJlZW4gcmVhZHZlcnRpc2VkIGJ5IEFTIFkuLi4pLi4uIEFzIEkgdW5kZXJzdGFuZCwgdGhlcmUg Y2FuIGJlIHNvbWUNCiAgICBBRk4vU0FGSSBzcGVjaWZpYyBleHRlbnNpb25zLCBidXQgbm8gcGVy LXByb3RvY29sIGV4dGVuc2lvbnMuIElzDQogICAgdGhpcyBhIGNvcnJlY3QgdW5kZXJzdGFuZGlu ZyA/IElmIG5vdCwgd291bGRuJ3QgaXQgbWFrZSBzZW5zZSB0bw0KICAgIG1ha2UgaXQgbW9yZSBl eHRlbnNpYmxlID88YnI+DQogICAgPGJyPg0KICAgIC0gd2h5IHJlc3RyaWN0IHRoZSBnZXQtcm91 dGUgUlBDIHRvIG9ubHkgcXVlcnkgdGhlIHNwZWNpYWwvZGVmYXVsdA0KICAgICJGSUIiIHJvdXRp bmcgdGFibGUgPyBpdCB3b3VsZCBzZWVtIHVzZWZ1bCB0byBiZSBhYmxlIHRvIHF1ZXJ5IGFueQ0K ICAgIHJvdXRpbmcgdGFibGUuPGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgPGJyPg0KICAg IC0tLSBSZWRpc3RyaWJ1dGluZyByb3V0ZXMgZGlyZWN0bHkgYmV0d2VlbiByb3V0aW5nIHByb3Rv Y29sczxicj4NCiAgICA8YnI+DQogICAgVGhlc2Ugc3BlY2lmaWNhdGlvbnMgb25seSBhbGxvdyB0 aGUgZXhjaGFuZ2Ugb2Ygcm91dGVzIGZyb20gYQ0KICAgIHJvdXRpbmcgcHJvdG9jb2wgb3Igcm91 dGluZyB0YWJsZSB0byBhIHJvdXRpbmcgdGFibGUsIGJ1dCBub3QgZnJvbSBhDQogICAgcm91dGlu ZyBwcm90b2NvbCB0byBhbm90aGVyIHJvdXRpbmcgcHJvdG9jb2xzLiBIb3dldmVyLCB0aGUgbGF0 dGVyDQogICAgaXMgc29tZXRoaW5nIHVzZWQgYSBsb3QgaW4gcHJhY3RpY2UgKGUuZy4gY29udHJv bGxpbmcgcmVkaXN0cmlidXRpb24NCiAgICBiZXR3ZWVuIHR3byBJR1AgYXJlYXMpLiBPZiBjb3Vy c2UsIGJ5IHVzaW5nIGFuIGludGVybWVkaWF0ZSByb3V0aW5nDQogICAgdGFibGUgeW91IGNvdWxk IGFjaGlldmUgdGhlIHNhbWUgcmVzdWx0LCBidXQgZG9lc24ndCBpdCBsb29rIGxpa2UNCiAgICBl eHRyYSBvdmVyaGVhZCA/PGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgLS0tIE1vZGlmeSBy b3V0ZXMgYmVpbmcgcmVkaXN0cmlidXRlZDxicj4NCiAgICA8YnI+DQogICAgVGhlcmUgZG9lcyBu b3Qgc2VlbSB0byBiZSBhbnkgd2F5IHRocm91Z2ggd2hpY2ggYSByb3V0ZSBtYXkgYmUNCiAgICBt b2RpZmllZC9hdWdtZW50ZWQgYnkgYSBmaWx0ZXIgd2hlbiBleHBvcnRlZCBmcm9tIGEgcm91dGlu ZyB0YWJsZSBvcg0KICAgIHByb3RvY29sIHRvIGFub3RoZXIuIEl0IHNlZW1zIHRvIG1lIHRoYXQg dGhpcyBpcyBzb21ldGhpbmcgdGhhdCBpcw0KICAgIHVzZWQgYSBsb3QgaW4gcHJhY3RpY2UuPGJy Pg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgLS0tIE11bHRpcGxlIHJvdXRpbmcgaW5zdGFuY2Vz PGJyPg0KICAgIDxicj4NCiAgICBUaGUgc3BlY3MgYXJlIHdyaXR0ZW4gc28gYXMgdG8gYWxsb3cg bXVsdGlwbGUgInJvdXRlcnMiIHRvIGNvLWV4aXN0DQogICAgb24gYW4gZXF1aXBtZW50IGluIGlz b2xhdGlvbiwgd2hpY2ggbG9va3MgdmVyeSB1c2VmdWwuwqAgSG93ZXZlciwgSSdtDQogICAgd29u ZGVyaW5nIGlmIHN1Y2ggYW4gYWJpbGl0eSBpcyBzcGVjaWZpYyB0byAicm91dGluZyIsIG9yIGlm IGl0DQogICAgc2hvdWxkbid0IGJlIHBhcnQgb2YgYSBtb3JlIGdlbmVyaWMgWWFuZyBtb2R1bGUs IHNvIGFzIHRvIHJldXNlIHRoZQ0KICAgIHNhbWUgc3ViLXJvdXRlciBoaWVyYXJjaHkgZm9yIHJv dXRpbmcgYW5kIG90aGVyIFlhbmcgbW9kdWxlcy48YnI+DQogICAgPGJyPg0KICAgIDxicj4NCiAg ICAtLS3CoCBBcHBsaWNhYmlsaXR5IHRvIFJGQzQzNjQ8YnI+DQogICAgPGJyPg0KICAgIEFsbG93 aW5nIG11bHRpcGxlICJyb3V0ZXJzIiBpcyBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQgZm9yIHVzaW5n IHRoZXNlDQogICAgc3BlY3MgaW4gdGhlIGNvbnRleHQgb2YgUkZDNDM2NCAoTVBMUy9CR1AgSVAg VlBOcykuIEhvd2V2ZXIsIGlmIEkNCiAgICB1bmRlcnN0YW5kIGNvcnJlY3RseSBZYW5nIHN5bnRh eCwgdGhlIHdheSB0aGUgZmlsdGVycyBhcmUgZGVmaW5lZA0KICAgIHdvdWxkIG5vdCB3b3JrIGlu IHRoZSBjb250ZXh0IG9mIFJGQzQzNjQsIHdoZXJlIGEgQkdQIHJvdXRpbmcNCiAgICBpbnN0YW5j ZSBpbiB0aGUgbWFzdGVyICJyb3V0ZXIiIGV4cG9ydHMgc2VsZWN0ZWQgcm91dGVzIGluIGVhY2gg b2YNCiAgICB0aGUgcm91dGluZyB0YWJsZSBvZiBlYWNoIFZQTiAoVlJGKS7CoCBUaGUgVlJGIGFs c28gZXhwb3J0IHJvdXRlcyB0bw0KICAgIHRoZSBtYXN0ZXIgaW5zdGFuY2UuPGJyPg0KICAgIDxi cj4NCiAgICBUaGUgdHdvIG9ic3RhY2xlcyBJIHdvdWxkIHNlZSAoSSBtaWdodCBiZSB3cm9uZykg YXJlIHRoZSBmb2xsb3dpbmc6PGJyPg0KICAgIC0gbm8gd2F5IHRvIG1vZGlmeSByb3V0ZXMgd2hp bGUgdGhleSBhcmUgaW1wb3J0ZWQvZXhwb3J0ZWQgOiB0aGUNCiAgICBSRkM0MzY0IHVzZS1jYXNl IHdvdWxkIHJlcXVpcmUgdGhlIGFiaWxpdHkgdG8gKGF0IGxlYXN0KSBhZGQvc3RyaXANCiAgICBh dHRyaWJ1dGVzIHRvL2Zyb20gdGhlIHJvdXRlczxicj4NCiAgICAtIG5vIHdheSB0byByZWRpc3Ry aWJ1dGUgcm91dGVzIGJldHdlZW4gcm91dGluZyB0YWJsZXMgb2YgZGlmZmVyZW50DQogICAgInJv dXRlcnMiICh3aGF0IGxldCBtZSB0aGluayB0aGlzIGNvbnN0cmFpbnQgZXhpc3RzIGlzIChhKSB0 aGUNCiAgICBpbmFiaWxpdHkgdG8gbmFtZSBhIHJvdXRlciB3aGVuIGRlc2lnbmF0aW5nIGEgcm91 dGluZy10YWJsZSB0bw0KICAgIGltcG9ydC9leHBvcnQgZnJvbS90bywgYW5kIChiKSB0aGUgWFBh dGhzIGZvcg0KICAgIGNvbm5lY3RlZC1yb3V0aW5nLXRhYmxlcy9yb3V0aW5nLXRhYmxlL25hbWUg YW5kDQogICAgcmVjaXBpZW50LXJvdXRpbmctdGFibGVzIHJlY2lwaWVudC1uYW1lLCB3aGljaCBz ZWVtcyB0byBub3QgYmUgYWJsZQ0KICAgIHRvIHBvaW50IGhpZ2hlciBpbiB0aGUgaGllcmFyY2h5 IHRoYW4gdGhlICdyb3V0ZXInIG9uIHdoaWNoIHRoZXkgYXJlDQogICAgZGVmaW5lZCApPGJyPg0K ICAgIC0gdGhlIGNvbnN0cmFpbnQgdGhhdCBmb3IgYSBzYWlkIHJvdXRpbmcgcHJvdG9jb2xzICJG b3IgZWFjaA0KICAgIEFGTi9TQUZJIHBhaXIgdGhlcmUgbWF5IGJlIGF0IG1vc3Qgb25lIGNvbm5l Y3RlZCByb3V0aW5nIHRhYmxlLiIgLg0KICAgIEluIHRoZSBSRkM0MzY0IGNhc2UsIHRoZSBnbG9i YWwgQkdQIHJvdXRpbmcgcHJvY2VzcyB3b3VsZCBwdXNoDQogICAgcm91dGVzIHRvIG11bHRpcGxl IFZSRnMuPGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgLS0tIEVuYWJsaW5nL2Rpc2FibGlu ZyBhbiBpbnRlcmZhY2U8YnI+DQogICAgPGJyPg0KICAgIFNvbWV0aGluZyBkb25lIHZlcnkgb2Z0 ZW4gb24gYSByb3V0ZXIgY29uc2lzdHMgaW4gcHV0dGluZyBhbg0KICAgIGludGVyZmFjZSAic2h1 dGRvd24iIG9yICJpbmFjdGl2ZSIsIHByZXNlcnZpbmcgaXRzIGNvbmZpZ3VyYXRpb24gYnV0DQog ICAgbWFraW5nIGl0IGlnbm9yZWQgYnkgdGhlIHJvdXRlciBhbmQga2VlcGluZyB0aGUgbGluayBk b3duLsKgIFRoZXNlDQogICAgc3BlY2lmaWNhdGlvbnMgZG9uJ3Qgc2VlbSB0byBwcm92aWRlIHRo aXMuwqAgSXMgdGhpcyBzb21ldGhpbmcNCiAgICBhbHJlYWR5LCBvciBleHBlY3RlZCB0byBiZSwg cHJvdmlkZWQgYnkgYW5vdGhlciBZYW5nIGV4dGVuc2lvbiA/IDxicj4NCiAgICA8YnI+DQogICAg SWYgc28sIGhvdyB3b3VsZCB0aGUgdHdvIGludGVyYWN0LCBpZiBmb3IgaW5zdGFuY2UsIGFuIGlu dGVyZmFjZSBpcw0KICAgIHNodXRkb3duIGluIHRoaXMgb3RoZXIgbW9kdWxlIGJ1dCB1c2VkIGlu IHRoZSByb3V0aW5nIG1vZHVsZSA/PGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgLS0tIEVu YWJsaW5nL0Rpc2FibGluZyBhIHByb3RvY29sIG9uIGFuIGludGVyZmFjZSwgb3IgbW9kaWZ5aW5n DQogICAgcHJvdG9jb2wgcGVyLWludGVyZmFjZSBwYXJhbWV0ZXJzPGJyPg0KICAgIDxicj4NCiAg ICBTb21ldGhpbmcgZG9uZSB2ZXJ5IG9mdGVuIG9uIGEgcm91dGVyIGNvbnNpc3RzIGluIGVuYWJs aW5nL2Rpc2FibGluZw0KICAgIGEgc2FpZCBwcm90b2NvbCBvbiBhIHNhaWQgaW50ZXJmYWNlLCBv ciBtb3JlIGdlbmVyYWxseSBtb2RpZnlpbmcNCiAgICBwYXJhbWV0ZXJzIGZvciBhIHNhaWQgcHJv dG9jb2wgb24gYSBzYWlkIGludGVyZmFjZSAodHlwaWNhbCBleGFtcGxlDQogICAgYmVpbmcgdGhl IG1ldHJpYykuwqAgQXMgSSB1bmRlcnN0YW5kIHRoaXMgd291bGQgYmUgYWxsb3dlZCBieSB0aGVz ZQ0KICAgIHNwZWNzIGJ5IGhhdmluZyBhIG1vZHVsZSBleHRlbmRpbmcgcHJvdG9jb2wgWCBhdWdt ZW50DQogICAgcm91dGluZy9yb3V0ZXIvaW50ZXJmYWNlIHdpdGggaXRzIG93biBwYXJhbWV0ZXJz LsKgIEhvd2V2ZXIsIEknbQ0KICAgIHdvbmRlcmluZyBpZiB0aGVzZSBwZXItcHJvdG9jb2wgcGVy LWludGVyZmFjZSBwYXJhbWV0ZXJzIHdvdWxkbid0IGJlDQogICAgYmV0dGVyIHBsYWNlZCB1bmRl ciBlYWNoIHJvdXRpbmcvcm91dGVyL3JvdXRpbmctcHJvdG9jb2xbWF0uIDxicj4NCiAgICA8YnI+ DQogICAgVGhlIHJlYXNvbnMgSSBzZWUgYXJlIHRoZSBmb2xsb3dpbmc6PGJyPg0KICAgICogaW4g c29tZSBjYXNlcyBhIHNhaWQgcm91dGVyIG1heSBydW4gbXVsdGlwbGUgaW5zdGFuY2VzIG9mIGEg c2FpZA0KICAgIHByb3RvY29sIHR5cGUsIGluIHBhcmFsbGVsLCBhbmQgeW91IG1heSBuZWVkIHRv IGhhdmUgYSB3YXkgdG8NCiAgICBkaWZmZXJlbnRpYXRlIGVuYWJsaW5nIGluc3RhbmNlIEEgb2Yg cHJvdG9jb2wgWCBmcm9tIGluc3RhbmNlIEIgb2YNCiAgICBwcm90b2NvbCBYPGJyPg0KICAgICog eW91IGNvdWxkIGV2ZW4gZmluZCB1c2UgY2FzZXMgd2hlcmUgYSBtdWx0aXBsZSBpbnN0YW5jZXMg b2YgYSBzYWlkDQogICAgcHJvdG9jb2wgdHlwZSBydW4gaW4gcGFyYWxsZWwgb24gYSBzYWlkIGlu dGVyZmFjZSAoZWcuIG11bHRpDQogICAgaW5zdGFuY2UgSVNJUyk8YnI+DQogICAgKiBteSB1bmRl cnN0YW5kaW5nIG9mIHRoZSBZYW5nIG1vZHVsZSBpcyB0aGF0IHRoZSBjdXJyZW50IHN0cnVjdHVy ZQ0KICAgIHdvdWxkIG5vdCBhbGxvdyBhdWdtZW50aW5nIGEgc2FpZCBpbnRlcmZhY2UgbXVsdGlw bGUgdGltZXMgZm9yIGENCiAgICBzYW1lIHBhcmFtZXRlciBvZiBhIHNhaWQgcHJvdG9jb2wgdHlw ZS48YnI+DQogICAgPGJyPg0KICAgIDxicj4NCiAgICAtLS0gRWRpdG9yaWFsIGFzcGVjdHMuLi48 YnI+DQogICAgPGJyPg0KICAgIEFsdGhvdWdoIGl0J3Mgbm90IHRoZSBwcmltYXJ5IHB1cnBvc2Ug b2YgdGhpcyByZXZpZXcsIEkgaGF2ZSB0bw0KICAgIG1lbnRpb24gdGhhdCB0aGUgZWRpdG9yaWFs IHF1YWxpdHkgb2YgdGhlIGRvY3VtZW50IGlzIGV4Y2VsbGVudCA7IEkNCiAgICBoYXZlIHBhcnRp Y3VsYXJseSBhcHByZWNpYXRlZCB0aGUgSFRNTC1yZW5kZXJlZCB2ZXJzaW9uIHByb2R1Y2VkIGJ5 DQogICAgdGhlIFhNTCBSRkMgZWRpdGluZyB0b29sY2hhaW4uIDxicj4NCiAgICA8YnI+DQogIDwv Ym9keT4NCjwvaHRtbD4NCg== ------_=_NextPart_001_01CD08E4.995CEA7C-- From lhotka@cesnet.cz Fri Mar 23 12:39:12 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A2F21F842F; Fri, 23 Mar 2012 12:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, J_CHICKENPOX_23=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 Ffhb1ypVaGpo; Fri, 23 Mar 2012 12:39:08 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4373A21F8460; Fri, 23 Mar 2012 12:39:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D75CC5401AE; Fri, 23 Mar 2012 20:39:04 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miL1-ZmQTuUk; Fri, 23 Mar 2012 20:38:59 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C9A2C540159; Fri, 23 Mar 2012 20:38:59 +0100 (CET) From: Ladislav Lhotka To: thomas.morin@orange.com, rtg-ads@tools.ietf.org In-Reply-To: References: User-Agent: Notmuch/0.11+128~g6f388fa (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Hi Thomas, MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii thanks a lot for your review, I find you comments very helpful. Please see my responses inline (I am also cc-ing it to the NETMOD mailing list). Mail-Followup-To: thomas.morin@orange.com, rtg-ads@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-netmod-routing-cfg.all@tools.ietf.org, netmod@ietf.org Date: Fri, 23 Mar 2012 20:38:16 +0100 Message-ID: X-Mailman-Approved-At: Fri, 23 Mar 2012 15:22:14 -0700 Cc: draft-ietf-netmod-routing-cfg.all@tools.ietf.org, rtg-dir@ietf.org, netmod@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netmod-routing-cfg X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 19:39:12 -0000 On Fri, 23 Mar 2012 12:04:10 +0100, wrote: > Hello, > > I have been selected as Routing Directorate reviewer for an early review of this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. This particular case is an early review requested by Routing ADs, with the goal of assessing the relevance of the work and eventually provide guidance. > > > Although these comments are primarily for the use of the Routing ADs, it can be helpful if you consider them along with any other comments that you receive. > > For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Document: draft-ietf-netmod-routing-cfg-02 > Reviewer: Thomas Morin > Review Date: 2012-03-22 > Intended Status: Standards Track > > > Summary: > > My overall impression of this document is rather positive, it seem to me as providing a good starting point for covering routing tables and routing protocols in netmod. > > However, I think there is possibly some room for improvement for making this base Yang routing module generic enough to really be applicable to all routing protocols and use cases. See below for more specific questions/suggestions, generic or related to specific protocols or use cases (ECMP support, multicast, MPLS/BGP VPNs, etc.). > This is quite possible, I only dared to address areas I am reasonably familiar with, which is essentially standard IP routing and some MPLS. > > It is also important to note that the usefulness of these specs is conditioned (a) by the development of Yang modules for each relevant routing protocol (which should be fairly doable assuming this base module is generic enough) and (b) conditioned by the development of additional Yang modules allowing the description of non-trivial import/export filters between routing protocols and routing tables (this part being possibly harder to achieve, since it means finding a common language able to express the variety of ACLs/policies that can be expressed on different router OSes today). > Absolutely. This is a usual dilemma: we can either try to develop a full-fledged route filtering framework and expect/force everybody to use it, or open the space for multiple competing frameworks. The draft and the routing module take the latter approach, because the logics of existing implementations differ from each other considerably, so it is not very likely to find their common denominator. I plan to implement the route filtering framework of the BIRD routing daemon which it is maintained by my company. > > Comments: > > --- Note Well ... > > I'm hoping this review will be relevant and useful. But, keeping in mind that doing this review was my first exposure at Yang, some comments I'm making could possibly be completely off track, and what I think I understood could as well be, partly or fully, wrong. If/when this happens to be the case, I apologize; just be frank and honest and eventually tell me to go back home and read a few other specs before I come back... ;-) No, I don't think it is necessary. :^) Andy Bierman once described the problem we are facing here: "The domain experts don't really know the data modeling stuff, and the data modeling experts don't really know the domain stuff." I certainly hope we can obtain sound results through cooperation between both classes of experts. > > There was one specific difficulty for doing this review: for someone lacking XPath fluency, it is hard to understand some details of the Yand modules. For instance, there is a complex condition for routing-protocol/connected-routing-tables, and it would have remained totally obscure to me without the error-message that is also provided ; the corresponding constraint was also explained in the Intro of section 4, so this particular case was ok (see more precise comment below). Beyond this example, the real issue is that I can't know if there is any other similar XPath constraint or other detail that I might have missed. > RFC 6087 requires all Standards Track modules to describe the purpose of all 'must' statements in 'description'. Actually, such a description often seems superfluous if there is an 'error-message' statement. At any rate, the purpose of such statement should be reasonably clear even without deciphering the XPath expressions. Please let me know if it is not the case and I will try to improve the descriptions and/or error messages. > > -- Document organization > > The interface parameters for IPv6 Neighbor Discovery would I think deserve being moved in a companion Yang module, unless there is a strong reason (such as a dependency) why it would be needed to be kept here. Other IPv6 ND parameters are defined by the "ietf-ip" module. It may indeed be worth reconsidering the structure of the "core" modules. > > > --- Extensibility > > It seems to me that these specs where written with extensibility in mind, which is a very positive point. One routing protocol example is given (RIP), but the structure is supposedly applicable to other routing protocols. You will find below a few questions related to the genericness, in fact mostly cases that may show that the current specs may not be generic enough with suggestions on possible fixes. > > > --- Completeness > > One question is how these Yang modules can be used today. It is clear that without companion specs for specific protocols and filters, not very much can be done with it (merely static routing with only trivial accept-all / deny-all filters). It is perfectly acknowledged in the document. One part that may prove hard to achieve is the unification of the variety of ACL/policies existing on different routing equipment vendors OSes, into one common Yang language for routing filters. Right. When we were preparing the current NETMOD charter, I actually proposed to include a route filtering framework but the WG consensus then was not to do so. As a proof of concept covering both routing protocols and route filtering, I will try to develop a complete data model for BIRD. > > > --- Information on routes > > The Yang module let's the operator read the routing tables. It looks like a very valid and useful thing (and not new, see RFC1213 MIB). > > However, I'm wondering about the following points: > > - usually, a routing table may have multiple routes for a said destination address, some being possibly less specific than others, or inactive due to various reasons : it did not identify how these specification allow the operator to see all routes of a routing table for a said prefix, or all the most specific routes including the inactive ones, or all the most specific actives routes when there is more than one (required I think for ECMP support), etc. ? it seems it would be worth to extend the get-route RPC to allow expressing all these kind of questions The 'get-route' method doesn't try to be terribly general or extensible, it is mainly intended as a reminder to routing experts that YANG also allows for defining new RPC methods. I think it will be easier to decide what methods are needed as soon as there are data models for the major routing protocols, such as OSPF or BGP. > > - when dumping a full routing table, will this be efficient ? wouldn't it be more efficient to rely on other dedicated mechanism already used today to get knowledge of a routing protocol (e.g. BCP or Route Reflection for BGP, or IGP tapping techniques for IGPs) RPC methods doing such things should be defined as a part of data models for routing protocols. With a route filtering framework, one could also set up an extra routing table and feed it with an appropriately filtered selection of routes. > > - assuming that in some cases dumping whole routing tables would not be efficient, will there be an efficient way to get aggregate information on a routing table ; such as "how many routes in the routing table" ? or "how many inactive routes in the routing table" ? "how many routes for prefix x.y.z" ? Yup, this sounds like a useful thing to have. Perhaps it might make sense to also have a generic RPC returning the number of entries in a list or leaf-list. > > - the term "destination-address" chosen to designate the piece of information based on which the get-route RPC works, is possibly not suitable for all routing protocols. The examples that I would see are (a) MP-BGP, where the routing information (NLRI) can be mostly anything (depends on the SAFI), and (b) multicast, where the routing information on which the PIM protocols work can be a (source,group) tuple, possibly augmented with flags Yes, see above. Do you have an idea how to define a general method without having the data models for MP-BGP or multicast routing? > > - (related to the previous point:) : I'm unclear if these specs allow a get-route to match on different portions or attributes of a routes (eg. get route for prefix X advertised by peer X, or having been readvertised by AS Y...)... As I understand, there can be some AFN/SAFI specific extensions, but no per-protocol extensions. Is this a correct understanding ? If not, wouldn't it make sense to make it more extensible ? There can be per-protocol extensions, too, it is also demonstrated in the RIP example. > > - why restrict the get-route RPC to only query the special/default "FIB" routing table ? it would seem useful to be able to query any routing table. This could be done but it would bring new issues to consider - multiple candidate routes etc. The 'get-route' method is supposed to answer the simple question: "Which route will be used for forwarding packets to destination W.X.Y.Z?" > > > > --- Redistributing routes directly between routing protocols > > These specifications only allow the exchange of routes from a routing protocol or routing table to a routing table, but not from a routing protocol to another routing protocols. However, the latter is something used a lot in practice (e.g. controlling redistribution between two IGP areas). Of course, by using an intermediate routing table you could achieve the same result, but doesn't it look like extra overhead ? Some implementations (IOS, for example) redistribute routes between protocols while others (JUNOS, BIRD) use an intermediate routing table. But as you say, the former approach may be emulated with the latter. In the most typical case when two protocols are connected to the same (e.g. main) routing table, each protocol can use a filter to pull the routes originating from the other protocol. > > > --- Modify routes being redistributed > > There does not seem to be any way through which a route may be modified/augmented by a filter when exported from a routing table or protocol to another. It seems to me that this is something that is used a lot in practice. Of course, this is just another task for the future route filtering framework(s). > > > --- Multiple routing instances > > The specs are written so as to allow multiple "routers" to co-exist on an equipment in isolation, which looks very useful. However, I'm wondering if such an ability is specific to "routing", or if it shouldn't be part of a more generic Yang module, so as to reuse the same sub-router hierarchy for routing and other Yang modules. OK, so you mean virtualization of the entire device, be it a router or anything else. AFAIK, this hasn't been discussed by the WG yet. > > > --- Applicability to RFC4364 > > Allowing multiple "routers" is a good starting point for using these specs in the context of RFC4364 (MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the way the filters are defined would not work in the context of RFC4364, where a BGP routing instance in the master "router" exports selected routes in each of the routing table of each VPN (VRF). The VRF also export routes to the master instance. The draft says: "Although it it not enforced by the data model, different router instances normally do not internally share any data." So this may be a use case for sharing data among different router instances. There is nothing in the data model (or YANG) preventing this. I will also relax the cited sentence, in the following sense: "Implementations may specify the rules for sharing data among router instances." > > The two obstacles I would see (I might be wrong) are the following: > - no way to modify routes while they are imported/exported : the RFC4364 use-case would require the ability to (at least) add/strip attributes to/from the routes Each import/export is subject to a route filter, which should be able to perform such manipulations. > - no way to redistribute routes between routing tables of different "routers" (what let me think this constraint exists is (a) the inability to name a router when designating a routing-table to import/export from/to, and (b) the XPaths for connected-routing-tables/routing-table/name and recipient-routing-tables recipient-name, which seems to not be able to point higher in the hierarchy than the 'router' on which they are defined ) True, the connected routing table currently must be within the same router instance. So this constraint should be removed, and implementations that need such an isolation will have to state it explicitly. > - the constraint that for a said routing protocols "For each AFN/SAFI pair there may be at most one connected routing table." . In the RFC4364 case, the global BGP routing process would push routes to multiple VRFs. This is most likely not a problem because any number of recipient routing tables can be configured to receive (filtered) routes from the single routing table which is connected to a routing protocol, cf. the "recipient-routing-tables" list. > > > --- Enabling/disabling an interface > > Something done very often on a router consists in putting an interface "shutdown" or "inactive", preserving its configuration but making it ignored by the router and keeping the link down. These specifications don't seem to provide this. Is this something already, or expected to be, provided by another Yang extension ? The "ietf-interfaces" module has this "enabled" switch, that will server this purpose. We are also discussing where to put the "is-router" toggle that enables/disables forwarding on an interface. > > If so, how would the two interact, if for instance, an interface is shutdown in this other module but used in the routing module ? Good point, this has to be specified in the draft. > > > --- Enabling/Disabling a protocol on an interface, or modifying protocol per-interface parameters > > Something done very often on a router consists in enabling/disabling a said protocol on a said interface, or more generally modifying parameters for a said protocol on a said interface (typical example being the metric). As I understand this would be allowed by these specs by having a module extending protocol X augment routing/router/interface with its own parameters. However, I'm wondering if these per-protocol per-interface parameters wouldn't be better placed under each routing/router/routing-protocol[X]. It is up to the designer of the protocol data model, both options are possible. Maybe we should give some guidelines. > > The reasons I see are the following: > * in some cases a said router may run multiple instances of a said protocol type, in parallel, and you may need to have a way to differentiate enabling instance A of protocol X from instance B of protocol X > * you could even find use cases where a multiple instances of a said protocol type run in parallel on a said interface (eg. multi instance ISIS) > * my understanding of the Yang module is that the current structure would not allow augmenting a said interface multiple times for a same parameter of a said protocol type. If something like this is necessary, one can augment an interface configuration with a list where each entry corresponds to one instance of the routing protocol. > > > --- Editorial aspects... > > Although it's not the primary purpose of this review, I have to mention that the editorial quality of the document is excellent ; I have particularly appreciated the HTML-rendered version produced by the XML RFC editing toolchain. Thank you. Best regards, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From adrian@olddog.co.uk Sat Mar 24 16:00:48 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C2821E8036; Sat, 24 Mar 2012 16:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] 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 vJ4BEXCviFHY; Sat, 24 Mar 2012 16:00:37 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 5266321E802D; Sat, 24 Mar 2012 16:00:37 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2ON0Z14030689; Sat, 24 Mar 2012 23:00:35 GMT Received: from 950129200 (dhcp-4691.meeting.ietf.org [130.129.70.145]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2ON0ECu030614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Mar 2012 23:00:35 GMT From: "Adrian Farrel" To: Date: Sat, 24 Mar 2012 22:59:55 -0000 Message-ID: <015d01cd0a11$ed86f920$c894eb60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0KEbNRAGLT/jv/SyuiPWCH+iPodw== Content-Language: en-gb Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: [RTG-DIR] Routing AD's office hours X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 23:00:48 -0000 Room is 233M From adrian@olddog.co.uk Sun Mar 25 02:53:40 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDEC21F8578 for ; Sun, 25 Mar 2012 02:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 zO+qkNFBMZ0B for ; Sun, 25 Mar 2012 02:53:39 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9C43621F8555 for ; Sun, 25 Mar 2012 02:53:39 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2P9rcKT031723 for ; Sun, 25 Mar 2012 10:53:38 +0100 Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2P9rbTM031716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 25 Mar 2012 10:53:38 +0100 From: "Adrian Farrel" To: Date: Sun, 25 Mar 2012 10:53:38 +0100 Message-ID: <029b01cd0a6d$27a15550$76e3fff0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0KbM8LYa02z4xESi2V4IQrxACH0Q== Content-Language: en-gb Subject: [RTG-DIR] BoFs you could usefully go to in Paris X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 09:53:40 -0000 Hi, If some of you can find it in your hearts to go to and participate in a few BoFs, that would be helpful. Any reports sent to the Directorate would be *really* helpful (Stewart and I are stretched to make it to all the BoFs). Infrastructure-to-Application Information Exposure BOF Monday, March 26 2012 1300-1500 http://www.ietf.org/proceedings/83/agenda/agenda-83-i2aex.txt (This is extensions to ALTO for specific applications some of which have seen an airing in RTG in the past, viz. Data Center and capacity requests) RFC Format BOF Tuesday, March 27 17:10-18:10 http://www.ietf.org/proceedings/83/agenda/agenda-83-rfcform.txt (This is a discussion about the different production media for RFCs, e.g. ASCII, PDF...) Network Virtualization Over Layer3 (nvo3) BOF Wednesday, March 28 13:00-15:00 http://www.ietf.org/proceedings/83/agenda/agenda-83-nvo3.html (This is about building overlays, potentially limited to the Data Center) Thanks, Adrian From adrian@olddog.co.uk Tue Mar 27 03:43:46 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C331C21F8643; Tue, 27 Mar 2012 03:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 TCJa1sa-MNe6; Tue, 27 Mar 2012 03:43:46 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D341521F8843; Tue, 27 Mar 2012 03:43:40 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2RAhad7026693; Tue, 27 Mar 2012 11:43:39 +0100 Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2RAhXZo026663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2012 11:43:34 +0100 From: "Adrian Farrel" To: Date: Tue, 27 Mar 2012 11:43:34 +0100 Message-ID: <067d01cd0c06$7680c4e0$63824ea0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0MBnJEmY/kzZ0DTVOPV1x0qBvKVA== Content-Language: en-gb Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: [RTG-DIR] Additional topic at Routing Area meeting X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:43:47 -0000 Hi, We're squeezing an additional topic onto the agenda. Dimitri will talk about "Information exchanges between router agents" which will be (AFAICS) his thoughts on the growing need to distribute information between routers which is not critical for packet routing. Cheers, Adrian