From nobody Mon Feb 1 05:49:51 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13D51A90AB; Mon, 1 Feb 2016 05:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 JBwMAXjF-ZFa; Mon, 1 Feb 2016 05:49:48 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D551A90A8; Mon, 1 Feb 2016 05:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1396; q=dns/txt; s=iport; t=1454334588; x=1455544188; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FTAQIXVZ75zkkI99IiKe2nP02kl49HPyLBtDBxKAgS4=; b=NsqEVsuilKF5sCfSxpy80iN/sQA28Jn7Y2o6FZBV9cfX2afoPg27sfIR A2pEST6hSj1V3RDRIUmuQ59eOpXLKiG5dGBIrHms5wHYOtk8g5lJCrpZM 3hvs8lXp3O7LyYM+jSNNjwLh5iU/fwl+MxJfulWcwbiMfVe9Yz+3PHdh5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALBQDNYa9W/4gNJK1egzqBPwaIUq9Jg?= =?us-ascii?q?iGBY4YPAoEzORMBAQEBAQEBgQqEQgEBBDo0GwIBCDYQMiUCBAESiBu8VwEBAQE?= =?us-ascii?q?BAQEDAQEBAQEBARmGDwGENohsAQSSbIQDAY1KgVuHZ4Uujj0BIQFAggIZHYE0a?= =?us-ascii?q?ogBfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,380,1449532800"; d="scan'208";a="69011875" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Feb 2016 13:49:47 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u11DnlLu028389 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Feb 2016 13:49:47 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 1 Feb 2016 07:49:46 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Mon, 1 Feb 2016 07:49:47 -0600 From: "Alvaro Retana (aretana)" To: Loa Andersson , "rtg-dir@ietf.org" , "rtg-ads@ietf.org" Thread-Topic: Sorry I missed that draft-ietf-spring-problem-statement were progressing to IESG review Thread-Index: AQHRXLd3DPnvk/DJPkOrBzcXPVeyy58XRiEA Date: Mon, 1 Feb 2016 13:49:46 +0000 Message-ID: References: <56AEF71A.6070208@pi.nu> In-Reply-To: <56AEF71A.6070208@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <7F2B93C95F6508449756B5B9CD836EC8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [RTG-DIR] Sorry I missed that draft-ietf-spring-problem-statement were progressing to IESG review X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 13:49:50 -0000 On 2/1/16, 1:11 AM, "Loa Andersson" wrote: Loa: Hi! >I just saw the DISCUSS from Deborah on draft-ietf-spring-problem- >statement. This draft slid under mt radar, sorry I should have been >more observant. > >I find my self a bit split, on one hand I support Segment/Source >Routing (there are a number of cases where it is beneficial), on the >other hand I quite agree with what Deborah put in her DISCUSS/COMMENT. >Especially we need to take care when we talk about other, especially >IETF, technologies. Even though the authors haven't replied to Deborah's DISCUSS, I'm sure they will take that text out. >I went back to see what we said in the rtg dir review and to my >surprise found that it was not reviewed by the directorate. I fail to >see why this is. Shouldn't this important draft have been through a >directorate review? Yes, it probably should have -- that one is on me. The IETF Last Call happened over the holidays, there had been extensive discussion on the mailing list, this document is a "process document" (if I was the only one deciding I wouldn't have published it), etc. All that doesn't justify the non-review -- just pointing out what went through my mind at the moment. Given the DISCUSSes there's still plenty of time for more review if anyone who hasn't read this document wants to do it. Thanks! Alvaro. From nobody Wed Feb 3 05:08:59 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC071A8A6E; Wed, 3 Feb 2016 05:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 L-nPY9fqoRxm; Wed, 3 Feb 2016 05:08:56 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEBD1A8A67; Wed, 3 Feb 2016 05:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1429; q=dns/txt; s=iport; t=1454504936; x=1455714536; h=from:to:cc:subject:date:message-id:mime-version; bh=9+ZJku2TZgpBb6ZYk7J8f1GpXnpeMwzmRhiEQzvF1H8=; b=R5xjbM2stj3dB3gKi9semZGBP5GHYyEBKax0vQQfWFT6r5zwuNdIvCxn Xd+XJaYVs1fzHgm+GgLWttlxjqmAAcDL3Bw2In4vnsjabi02G31y1SVRZ tmab3Lvj3dEcHfNh/3Jiyfrau5CySZRZfPmbKmd44Pj5PnMiXFVONgP5f Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvCADu+rFW/5ldJa1bA4JuTIFFiFWjL?= =?us-ascii?q?IVeiDQBDYFkhg2BRjgUAQEBAQEBAYEKhDgMBHkSAQsBdCcEAQ2IIL9xAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEWjksRAWWDcwWWcQGBEow6hSaJS44/AR4BAUKDZIklN?= =?us-ascii?q?HwBAQE?= X-IronPort-AV: E=Sophos; i="5.22,390,1449532800"; d="scan'208,217"; a="67565329" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2016 13:08:55 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u13D8tkG011777 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2016 13:08:55 GMT Received: from xch-aln-016.cisco.com (173.36.7.26) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 07:08:55 -0600 Received: from xch-aln-016.cisco.com ([173.36.7.26]) by XCH-ALN-016.cisco.com ([173.36.7.26]) with mapi id 15.00.1104.009; Wed, 3 Feb 2016 07:08:55 -0600 From: "George Swallow (swallow)" To: "mpls-chairs@ietf.org" , "rtg-dir@ietf.org" Thread-Topic: Status change at Cisco Thread-Index: AQHRXoQJRMcySpyhQECpwz+yBUB2AQ== Date: Wed, 3 Feb 2016 13:08:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.212.3] Content-Type: multipart/alternative; boundary="_000_D2D76614130C90swallowciscocom_" MIME-Version: 1.0 Archived-At: Cc: "swallow.ietf@gmail.com" Subject: [RTG-DIR] Status change at Cisco X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:08:57 -0000 --_000_D2D76614130C90swallowciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi - Today is my last day as a Cisco Employee. Beginning tomorrow (or soon ther= eafter) I will be consulting to Cisco. Cisco will continue to fund my part= icipation in the IETF. In case there is a short disruption of email, use the address in the CC lis= t. For phone, use my cell 617 378 5409. George --_000_D2D76614130C90swallowciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <620C8BBF58FC6946BDD50A42A5BD382A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi -

Today is my last day as a Cisco Employee.  Beginning tomorrow (or= soon thereafter) I will be consulting to Cisco.  Cisco will continue = to fund my participation in the IETF.

In case there is a short disruption of email, use the address in the C= C list.  For phone, use my cell 617 378 5409.

George
--_000_D2D76614130C90swallowciscocom_-- From nobody Fri Feb 5 13:43:06 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BF51B2D50; Fri, 5 Feb 2016 13:43:02 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 eLK3Vay5Rcdc; Fri, 5 Feb 2016 13:43:00 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 E54E01A885E; Fri, 5 Feb 2016 13:42:56 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id s2so49937165oie.2; Fri, 05 Feb 2016 13:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=aMb8ckDXEWWczoDSXVkL6J+t8iyymPrj5nm17v3aerI=; b=HpdKf7CQy6AxwIz5hBZI7/X8fR3oZhbZitvDPwBlnu64XatcNtiNoYg06NW5b4HUWw WSRBaJNuKyaaGjFD2XEWd3cQtxUr/TmAJJ84Sj8M7SWeO8hEqMchwJyXSSp+OkgLQ8k0 CYG1uNOHwemVh36pZJwLSpGw7KVRH+zNxuKHcIywx+udXpJjRSVxXzM4pThi7rW14zqn wwfliZetzj/uB4/QQCGnxeUDLOtj4wVotJW2SApkCzKlGHdoPMq0NgGZ96uAUgCs6GSL oh3fw4y4Wid32YxerTjVXwuCfBHYcWlA2dmIFhvBQCTr/BKA1vZ3BQe4+RN7FdsDAI37 qHNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=aMb8ckDXEWWczoDSXVkL6J+t8iyymPrj5nm17v3aerI=; b=HNsUPrlkqcESmE615ioL9gHyqzbR0h2TROeRD1KVUqlL8fYgdow+12Tna4SNGpaI2H Z+1tGhhsS2FUveaSytYjKKGONDryP3aIq9ICXgWGSd7jqsp+xylX6OgZ2HV8EbErYHd3 uQer3GEWusAENiSYdLZrgm6hWQ6Rgd9bEh6AE9lBYCWPqDu9+7c+ARVzO9MoxeJPe90T PUVC2y/CAFlMhZiNYLUMvhsdSo6k+m3BIVwuCGufwlD8nmf9MoMx6FuwmBm19azuS7iF SNcpH9eLewhYEUCiZpzQg67pnDsAdL0Imt9kFY9JEmMw31DCiY035wO9fvG0muHmQ/J1 lAQQ== X-Gm-Message-State: AG10YOQdLPbbgmwD7qb59uyKG7mu2ISvJIAwHeZ8vBbT01Z81YpG58Sf4QAhVMZ4waRssUs9jJZJ1a1MlIqKvA== X-Received: by 10.202.241.214 with SMTP id p205mr10411285oih.126.1454708576320; Fri, 05 Feb 2016 13:42:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.196.104 with HTTP; Fri, 5 Feb 2016 13:42:36 -0800 (PST) From: "Andrew G. Malis" Date: Fri, 5 Feb 2016 16:42:36 -0500 Message-ID: To: IETF Discussion Content-Type: multipart/alternative; boundary=94eb2c094b58f18145052b0cbb70 Archived-At: Cc: "" , "rtg-dir@ietf.org" , tsvwg@ietf.org, IESG , draft-ietf-tsvwg-circuit-breaker.all@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-tsvwg-circuit-breaker-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 21:43:02 -0000 --94eb2c094b58f18145052b0cbb70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, and sometimes on special request. The purpose of the review is to provide assistance to the IESG. For more information about the Routing Directorate, please see = =E2=80=8B http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir It would be helpful if you could consider these comments 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-tsvwg-circuit-breaker-11.txt Reviewer: Andy Malis Review Date: February 5, 2016 IETF LC End Date: February 9, 2016 Intended Status: Best Current Practice Summary: I have some minor concerns about this document that I think should be resolved before publication. Major Issues: No major issues found. Minor Issues: Page 3, first paragraph: There are no citations to the claim that non-congestion-controlled traffic "can form a significant proportion of the total traffic traversing a link". Sure, video is a major part of Internet traffic these days, but much Internet video is dynamically adaptive. One or more citations would be useful. Section 4: There are so many issues that they should be numbered, so that they can be referred to individually (from another document, for example). Page 11: In my opinion, the second and third requirements on this page should be "MUST"s rather than "SHOULD"s. Page 12, discussion of "In-Band" near the bottom of the page: This paragraph implies that an in-band control method will always provide fate-sharing of the control and regular traffic. It may provide fate-sharing, but that is by no means assured. For example, the network may be using ECMP, or traffic tunnels for data but not control traffic. Section 5: I'm not sure why Section 5 is a separate section, and not integrated into Section 3 as new subsections, which I think would be an improvement. Page 13, first paragraph: "presented in figure 2" -> "presented in figures 1 and 2". Page 19, fourth paragraph: This paragraph states that "IP-based traffic is generally assumed to be congestion-controlled". This is true for TCP-based traffic, but I would not make such an assumption for all IP-based traffic. Nits: The abbreviation "CB" is defined early in the document, but is hardly if ever used thereafter, rather "Circuit Breaker" is almost always spelled out. It may be useful to actually use the abbreviation. Page 3, first paragraph, fifth line, "connection" -> "connections". Figure 1: Move the vertical line between the "Measure" and "Trigger" boxes one space to the right. Page 10, fourth paragraph: "If necessary, MAY combine" -> "If necessary, a CB MAY combine". Page 11, fifth paragraph: "needs to be" -> "MUST" Page 12, second paragraph: There are two separate references to Section 8. One combined reference should be sufficient. Page 12, second to last paragraph: "in-Band" should have the "i" capitalized. Page 15, last paragraph: "tranport" -> "transport" Page 17, fifth paragraph: "Pseudo Wire" -> "PW" Regards, Andy --94eb2c094b58f18145052b0cbb70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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, and sometimes on special request. The purp= ose of the review is to provide assistance to the IESG. For more informatio= n about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/= rtg/trac/wiki/RtgDir

It would be helpful if yo= u could consider these comments along with any other IETF Last Call comment= s that you receive, and strive to resolve them through discussion or by upd= ating the draft.

Document: draft-ietf-tsvwg-circui= t-breaker-11.txt
Reviewer: Andy Malis
Review Date: Febr= uary 5, 2016
IETF LC End Date: February 9, 2016
Intende= d Status: Best Current Practice

Summary:

I have some minor concerns about this document that I think= should be resolved before publication.

Major Issu= es:

No major issues found.

Minor Issues:

Page 3, first paragraph: There are= no citations to the claim that non-congestion-controlled traffic "can= form a significant proportion of the total traffic traversing a link"= . Sure, video is a major part of Internet traffic these days, but much Inte= rnet video is dynamically adaptive. One or more citations would be useful.<= /div>

Section 4: There are so many issues that they shou= ld be numbered, so that they can be referred to individually (from another = document, for example).

Page 11: In my opinion, th= e second and third requirements on this page should be "MUST"s ra= ther than "SHOULD"s.

Page 12, discussion= of "In-Band" near the bottom of the page: This paragraph implies= that an in-band control method will always provide fate-sharing of the con= trol and regular traffic. It may provide fate-sharing, but that is by no me= ans assured. For example, the network may be using ECMP, or traffic tunnels= for data but not control traffic.

Section 5: I= 9;m not sure why Section 5 is a separate section, and not integrated into S= ection 3 as new subsections, which I think would be an improvement.

Page 13, first paragraph: "presented in figure 2&quo= t; -> "presented in figures 1 and 2".

Page 19, fourth paragraph: This paragraph states that "IP-based traff= ic is generally assumed to be congestion-controlled". This is true for= TCP-based traffic, but I would not make such an assumption for all IP-base= d traffic.

Nits:

The abbr= eviation "CB" is defined early in the document, but is hardly if = ever used thereafter, rather "Circuit Breaker" is almost always s= pelled out. It may be useful to actually use the abbreviation.
Page 3, first paragraph, fifth line, "connection" -&= gt; "connections".

Figure 1: Move the ve= rtical line between the "Measure" and "Trigger" boxes o= ne space to the right.

Page 10, fourth paragraph: = "If necessary, MAY combine" -> "If necessary, a CB MAY co= mbine".

Page 11, fifth paragraph: "needs= to be" -> "MUST"

Page 12, secon= d paragraph: There are two separate references to Section 8. One combined r= eference should be sufficient.

Page 12, second to = last paragraph: "in-Band" should have the "i" capitaliz= ed.

Page 15, last paragraph: "tranport" = -> "transport"

Page 17, fifth paragra= ph: "Pseudo Wire" -> "PW"

R= egards,
Andy

--94eb2c094b58f18145052b0cbb70-- From nobody Fri Feb 5 19:23:51 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE801B322E; Fri, 5 Feb 2016 17:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 9Zqh5eCWJoym; Fri, 5 Feb 2016 17:21:02 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E211B322D; Fri, 5 Feb 2016 17:21:01 -0800 (PST) Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) with Microsoft SMTP Server (TLS) id 15.1.396.15; Sat, 6 Feb 2016 01:20:57 +0000 Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0396.020; Sat, 6 Feb 2016 01:20:57 +0000 From: Chris Bowers To: "bruno.decraene@orange.com" , "rtg-ads@ietf.org" Thread-Topic: RtgDir review: draft-ietf-rtgwg-mrt-frr-architecture-09 Thread-Index: AdFapJJOEIRxVEGZTDqri7ekVvJZbAACsUdw Date: Sat, 6 Feb 2016 01:20:57 +0000 Message-ID: References: <23108_1454079959_56AB7FD7_23108_16575_1_53C29892C857584299CBF5D05346208A0F7A569A@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <23108_1454079959_56AB7FD7_23108_16575_1_53C29892C857584299CBF5D05346208A0F7A569A@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; BY2PR05MB614; 5:i1hQfuVZ3A+wZJs8ZUCsS5BkN3/V3404vIvJ1brOy3Vv3TUFCuT16WO832FQY506HpwTMA/p2iSe2R/6zqsycKJh4klhk6BrpgQx2y/jj4+ZsbQ+tjwoW6j9LHe3OE1pvZ6YLB1AsB//ndmFYeOrTw==; 24:F9MM+rM3f8RDQHsgoRzKDkUMAC4h4yG/gyV+wVZtp78Rj2RMh+Ml/llyWkx2GuEGwBvsOXWIGjc/CjhcQA4LjHlu+7yYlsnD4Opjr/FJngI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB614; x-ms-office365-filtering-correlation-id: ac8871c9-5385-4f00-b7ee-08d32e93c44f x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY2PR05MB614; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB614; x-forefront-prvs: 08444C7C87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51914003)(164054003)(37854004)(377454003)(51444003)(377424004)(13464003)(10400500002)(2900100001)(3280700002)(1096002)(122556002)(33656002)(5890100001)(92566002)(102836003)(2501003)(586003)(5001770100001)(6116002)(66066001)(15975445007)(77096005)(3660700001)(1220700001)(40100003)(87936001)(3846002)(4326007)(5001960100002)(74316001)(86362001)(19580405001)(99286002)(54356999)(19580395003)(575784001)(230783001)(2950100001)(2906002)(189998001)(5008740100001)(1720100001)(5003600100002)(5002640100001)(76176999)(5004730100002)(11100500001)(50986999)(76576001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB614; H:BY2PR05MB614.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2016 01:20:57.5813 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB614 Archived-At: X-Mailman-Approved-At: Fri, 05 Feb 2016 19:23:50 -0800 Cc: "rtg-dir@ietf.org" , "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" , "rtgwg@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-rtgwg-mrt-frr-architecture-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 01:21:06 -0000 QnJ1bm8sDQoNClRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIGNvbW1lbnRzLiAgV2UgaGF2ZSBwdWJs aXNoZWQgYSBuZXcgcmV2aXNpb24gaW5jb3Jwb3JhdGluZyB5b3VyIGZlZWRiYWNrLCBhcyB3ZWxs IGFzIHNvbWUgb3V0c3RhbmRpbmcgZmVlZGJhY2sgZnJvbSBXRyBsYXN0IGNhbGwsIEFEIHJldmll dywgYW5kIHRoZSBJRVNHLiAgDQoNCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGd3Zy1tcnQtZnJyLWFyY2hpdGVjdHVyZS0xMA0KRGlmZjog ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJ0 Z3dnLW1ydC1mcnItYXJjaGl0ZWN0dXJlLTEwDQoNClNwZWNpZmljIGNvbW1lbnQgYXJlIGFkZHJl c3NlZCBiZWxvdyB3aXRoIFtDQl0uIA0KDQpUaGFua3MsDQpDaHJpcw0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSBbbWFpbHRvOmJy dW5vLmRlY3JhZW5lQG9yYW5nZS5jb21dIA0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDI5LCAyMDE2 IDk6MDYgQU0NClRvOiBydGctYWRzQGlldGYub3JnDQpDYzogcnRnd2dAaWV0Zi5vcmc7IHJ0Zy1k aXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcnRnd2ctbXJ0LWZyci1hcmNoaXRlY3R1cmVAaWV0Zi5v cmcNClN1YmplY3Q6IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtcnRnd2ctbXJ0LWZyci1hcmNo aXRlY3R1cmUtMDkNCg0KSGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0 aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJl Y3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRy YWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcs IGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2 aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKA i2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0K QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUg Um91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRo ZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3Ug cmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9y IGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtcnRnd2ctbXJ0 LWZyci1hcmNoaXRlY3R1cmUtMDkudHh0DQpSZXZpZXdlcjogQnJ1bm8gRGVjcmFlbmUNClJldmll dyBEYXRlOiAyMDE2LTAxLTI5DQpJRVRGIExDIEVuZCBEYXRlOiAyMDE2LTAxLTI5DQpJbnRlbmRl ZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KDQpTdW1tYXJ5Og0KICAgIEkgaGF2ZSBzb21lIG1p bm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSBy ZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24uDQoNCkNvbW1lbnRzOg0KICAgRG9jdW1lbnQgaXMg Y2xlYXIgYW5kIHZlcnkgd2VsbCB3cml0dGVuLiBUaGFuayB5b3UuIFZlcnkgbXVjaCBhcHByZWNp YXRlZCBnaXZlbiB0aGUgc2l6ZSBvZiB0aGUgZG9jdW1lbnQgYW5kIHRoZSBzdWJqZWN0Lg0KDQpN YWpvcnMgSXNzdWVzOg0KICAgTm9uZQ0KDQpNaW5vciBJc3N1ZXM6DQoNCi0tLS0NCi0gc2VjdGlv biA2OiBVbmljYXN0IGZvcndhcmRpbmcgd2l0aCBNUlQgYW5kIEZhc3QtUmVyb3V0ZSBUaGlzIHNl Y3Rpb24gbGlzdCBtYW55IHBvc3NpYmlsaXRpZXMgb2Ygd2hhdCBjb3VsZCBoYXZlIGJlIGRvbmUg b3Igd2hhdCBjb3VsZCBiZSB1c2VkLiBUaGlzIGlzIHZlcnkgaW50ZXJlc3RpbmcgYW5kIG9wZW4g bGFyZ2VyIHBvc3NpYmlsaXRpZXMsIGJ1dCBmb3IgYSBTVEQgdHJhY2sgZG9jdW1lbnQsIGl0IG1h eSBoYXZlIGJlZW4gbW9yZSBwcmVzY3JpcHRpdmUuICAoYW5kIHRoZSBsYXN0IHBhcmFncmFwaCBv ZiDCpzYuMy4xLjIgc3RhcnRpbmcgd2l0aCAiRm9yIGNvbXBsZXRlbmVzcyIgZnVydGhlciBwdXNo IHRoZSBjdXJzb3Igb24gdGhlIHNpZGUgb2YgY2F0YWxvZyBvZiBwb3NzaWJsZSBzb2x1dGlvbnMg cmF0aGVyIHRoYW4gdGhlIHNwZWNpZmljYXRpb24gb2YgYSBvbmUgU1REIHRyYWNrIHNvbHV0aW9u LikgQnV0IEkgYWdyZWUgdGhhdCB0aGUgIk1SVCBhcmNoaXRlY3R1cmUiIGNvdWxkIGJlIHNlZW4g YXMgYnJvYWRlciB0aGFuIGEgc2luZ2xlIHNvbHV0aW9uLiBBbmQgdGhlIGRvY3VtZW50IHByb3Bv c2UgdGhlIGRlZmluaXRpb24gb2YgIk1SVCBwcm9maWxlcyIgd2hpY2ggc2VlbSBhcHByb3ByaWF0 ZSB0byBhbGxvdyBmb3IgaW50ZXJvcGVyYWJsZSBkZXBsb3ltZW50cyAoYnV0IGFzIGEgc2luZ2xl IHByb2ZpbGUgaXMgZGVmaW5lZCwgaXQgd291bGQgaGF2ZSBiZWVuIHBvc3NpYmxlIHRvIHdyaXRl IGEgc2luZ2xlIHNvbHV0aW9uLCB3aGlsZSBzdGlsbCBiZWluZyBleHRlbmRhYmxlIGluIHRoZSBm dXR1cmUpLiANCg0KRXZlbnR1YWxseSBJIHdvdWxkIHByb3Bvc2UgYSBzbGlnaHQgY2hhbmdlIGlu IHRoZSBUb0MgZm9yIHRoZSByZWFkZXIgdG8gbW9yZSBlYXNpbHkgdW5kZXJzdGFuZCB3aGF0IGlz IG9wdGlvbmFsIHZzIHJlcXVpcmVkOg0KOnMvNi4xIE1SVCBGb3J3YXJkaW5nIE1lY2hhbmlzbXMv Ni4xIEludHJvZHVjdGlvbiB0byBNUlQgRm9yd2FyZGluZyBvcHRpb25zIEFkZGluZyAiNi4yLjQg UmVxdWlyZWQgc3VwcHBvcnQiLCB1c2luZyAiNi4zLjMgUmVxdWlyZWQgc3VwcG9ydCIgYXMgbW9k ZWwgKHBsdXMgbW92aW5nIHRoZSBsYXN0IHNlbnRlbmNlIG9mIDYuMi4zIGluIHRoaXMgc2VjdGlv bikNCg0KW0NCXSAgR29vZCBpZGVhLiAgQ2hhbmdlcyBpbXBsZW1lbnRlZCBpbjoNCmh0dHBzOi8v Z2l0aHViLmNvbS9jYm93ZXJzL2RyYWZ0LWlldGYtcnRnd2ctbXJ0LWZyci1hcmNoaXRlY3R1cmUv Y29tbWl0L2U1ZjM4N2M5Y2MxNzUxNDc1MjQwYjAyZTBiNzk4NjFmNGQ4NGUzMTgNCg0KLS0tLQ0K Q29tcGFyaXNvbjoNCltOb3RlOiBZZXMsIEkgcmVhZCB0aGF0IGF1dGhvcnMgd2lsbCByZW1vdmUg dGhlIGNvbXBhcmlzb24gdGFibGUgaW4gdGhlIG5leHQgdmVyc2lvbi4gOi0pIEJ1dCBJIGhhZCBz dGFydGVkIHRoZSByZXZpZXcgYmVmb3JlLCBhbmQgSSdtIHN0aWxsIHJldmlld2luZyB0aGUgbGF0 ZXN0IHZlcnNpb24uXQ0KDQpJJ20gbm90IHN1cmUgdGhhdCB0aGUgY29tcGFyaXNvbiBpcyBiZXN0 IHBsYWNlZCBpbiB0aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24uIEknZCByYXRoZXIgbW92ZSBpdCBs YXRlciBpbiB0aGUgZG9jLCBvciBpbiBhcHBlbmRpeCBhbmQgaGF2ZSB0aGUgaW50cm9kdWN0aW9u IG9ubHkgcmVmZXJlbmNlIGl0LiBPciBpbiBhIGRpZmZlcmVudCBkcmFmdC4NCg0KLSAzcmQgY29s dW1uDQoiICAgVGhlIHRoaXJkIGNvbHVtbiBnaXZlcyBhbiBlc3RpbWF0ZSBvZiB0aGUgYW1vdW50 IG9mIGNvbXB1dGF0aW9uDQogICByZXF1aXJlZCBhdCBlYWNoIG5vZGUgdG8gc3VwcG9ydCB0aGUg RlJSIG1ldGhvZCwgaW4gYWRkaXRpb24gdG8gdGhlDQogICB1c3VhbCBTUEYgY29tcHV0YXRpb24g cm9vdGVkIGF0IHRoZSBjb21wdXRpbmcgbm9kZSBpdHNlbGYuICBUaGlzDQogICBtZXRyaWMgb2Yg Y29tcGFyaXNvbiBpcyBpbXBvcnRhbnQgZm9yIGltcGxlbWVudGF0aW9ucyB0aGF0IHNlZWsgdG8N CiAgIHF1aWNrbHkgcmVjb21wdXRlIHJlcGFpciBwYXRocyINCg0Kb2suIEJ1dCBmb3IgcmVndWxh ciByb3V0aW5nLCB0aGlzIHRpbWUgaXMgdHlwaWNhbGx5IGRyaXZlbiBieSBGSUIgdXBkYXRlIHJh dGhlciB0aGFuIGNvbnRyb2wgcGxhbmUgY29tcHV0YXRpb24uIEdpdmVuIHRoYXQgInRoZSBNUlQg TG93cG9pbnQgYWxnb3JpdGhtIGlzIGNvbXB1dGF0aW9uYWxseSBlZmZpY2llbnQiLCBpdCdzIG5v dCBjbGVhciB0byBtZSB0aGF0IGNvbnRyb2wgcGxhbmUgY29tcHV0YXRpb24gaXMgdGhlIHJpZ2h0 IG1ldHJpYyB0byBldmFsdWF0ZSB0aGUgdGltZSB0byBiZSByZWFkeSBmb3IgdGhlIG5leHQgZmFp bHVyZS4gRXNwZWNpYWxseSBzaW5jZSBNUlQgcmVxdWlyZXMgYSBsYXJnZXIgRklCICgqMykgYW5k IGhlbmNlIHdpbGwgYmUgc2xvd2VyIG9uIHRoZSBtYWluIGZhY3Rvci4NCg0KLSBNUlQgdXNlIGEg ZGVkaWNhdGVkIGluZnJhc3RydWN0dXJlIChwcm90b2NvbHMgZXh0ZW5zaW9uLCBhbGdvcml0aG0s IFJJQi9GSUIgZW50cmllcykgZm9yIHRoZSBGUlIgdHJhZmZpYy4gwqcxNC4xIHJlY29tbWVuZHMg dG8gY2hlY2sgdGhhdCB0aGlzIGluZnJhc3RydWN0dXJlIGlzIHJ1bm5pbmcgY29ycmVjdGx5IHdo aWNoIHJlcHJlc2VudCBhbiBhZGRpdGlvbmFsIG9wZXJhdGlvbmFsIHdvcmsgYW5kIHRvb2xpbmcu IE90aGVyIHNvbHV0aW9ucyBlLmcuIExGQSwgVEktTEZBLCBSTEZBIHJlLXVzZXMgdGhlIG5vbWlu YWwgcm91dGluZyBpbmZyYXN0cnVjdHVyZSB3aGljaCBpcyBhbHJlYWR5IG1vbml0b3JlZC4NCi0g VHJhZmZpYyBjYXBhY2l0eSBtYXkgYmUgYW4gaW50ZXJlc3RpbmcgbWV0cmljIHRvIGNvbXBhcmUg KGFzIGRpc2N1c3NlZCBpbiDCpzE0LjIpDQo9PT09PT09PT0NCltDQl0gQXMgeW91IG5vdGVkLCB0 aGlzIHRhYmxlIGFuZCB0ZXh0IGhhcyBiZWVuIHJlbW92ZWQsIGJ1dCB0aGUgZmVlZGJhY2sgaXMg dXNlZnVsIGluIGNhc2UgdGhlIHRleHQgZW5kcyB1cCBpbiBhbm90aGVyIGRvY3VtZW50IGF0IHNv bWUgcG9pbnQgaW4gdGhlIGZ1dHVyZS4NCmh0dHBzOi8vZ2l0aHViLmNvbS9jYm93ZXJzL2RyYWZ0 LWlldGYtcnRnd2ctbXJ0LWZyci1hcmNoaXRlY3R1cmUvY29tbWl0Lzc2NTVhY2JkNmYzNTBiNDUw NWFiNjNhOWIyMWU1MzU4MmI5MTNiMDQNCj09PT09PT09PQ0KDQotLS0tDQrCpzE0LjIgVHJhZmZp YyBDYXBhY2l0eSBvbiBCYWNrdXAgUGF0aHMNCkhhdmluZyBub3QgcmVhZCBNUlQgTG93IFBvaW50 IEFsZ28sDQoiQWR2ZXJ0aXNpbmcgbGlua3MgYXMgTVJULUluZWxpZ2libGUgaXMgdGhlIG1haW4g dG9vbCBwcm92aWRlZCBieSBNUlQtRlJSIGZvciBrZWVwaW5nIGJhY2t1cCB0cmFmZmljIG9mZiBv ZiBsb3dlciBiYW5kd2lkdGggbGlua3MgZHVyaW5nIGZhc3QtcmVyb3V0ZSBldmVudHMuIg0KIk1h aW4iIG9yICJPbmx5Ij8gSWYgb3RoZXJzIHRvb2xzIGFyZSBlZmZlY3RpdmUsIGl0IG1heSBiZSB1 c2VmdWwgdG8gaW5kaWNhdGUgdGhlbS4NCkluIHBhcnRpY3VsYXIsIGl0J3Mgbm90IG9idmlvdXMg d2hldGhlciBJR1AgY29zdCBpcyB0YWtlbiBpbnRvIGFjY291bnQgYW5kIG1heSBiZSB1c2VmdWwg dG8gZ2l2ZSBwcmVmZXJlbmNlIHRvIHNvbWUgYmFja3VwIHBhdGguIElmIG5vdCwgaXQgbWF5IGJl IHVzZWZ1bCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBiYWNrdXAgcGF0aCB3aWxsIG5vdCAoc2lnbmlm aWNhbnRseSkgdGFrZSBpbnRvIGFjY291bnQgdGhlIElHUCBtZXRyaWNzIChlLmcuIGRlbGF5LCBi YW5kd2lkdGgsIGRpc3RhbmNlLCBjb3N0LCBvcGVyYXRvciBwcmVmZXJlbmNlcy4uLikNCj09PT09 PT09PT0NCltDQl0gSSBtb2RpZmllZCB0aGUgdGV4dCB0byByZWFkIGFzIGJlbG93LiAgDQoNClRo ZSBNUlQgTG93cG9pbnQgYWxnb3JpdGhtIHByb2R1Y2VzIGEgcGFpciBvZiBkaXZlcnNlIHBhdGhz IHRvIGVhY2gNCiAgIGRlc3RpbmF0aW9uLiAgVGhlc2UgcGF0aHMgYXJlIGdlbmVyYXRlZCBieSBm b2xsb3dpbmcgdGhlIGRpcmVjdGVkDQogICBsaW5rcyBvbiBhIGNvbW1vbiBHQURBRy4gIFRoZSBk ZWNpc2lvbiBwcm9jZXNzIGZvciBjb25zdHJ1Y3RpbmcgdGhlDQogICBHQURBRyBpbiB0aGUgTVJU IExvd3BvaW50IGFsZ29yaXRobSB0YWtlcyBpbnRvIGFjY291bnQgaW5kaXZpZHVhbCBJR1ANCiAg IGxpbmsgbWV0cmljcy4gIEF0IGFueSBnaXZlbiBub2RlLCBsaW5rcyBhcmUgZXhwbG9yZWQgaW4g b3JkZXIgZnJvbQ0KICAgbG93ZXN0IElHUCBtZXRyaWMgdG8gaGlnaGVzdCBJR1AgbWV0cmljLiAg QWRkaXRpb25hbGx5LCB0aGUgcHJvY2Vzcw0KICAgZm9yIGNvbnN0cnVjdGluZyB0aGUgTVJULVJl ZCBhbmQgQmx1ZSB0cmVlcyB1c2VzIFNQRiB0cmF2ZXJzYWxzIG9mDQogICB0aGUgR0FEQUcuICBU aGVyZWZvcmUsIHRoZSBJR1AgbGluayBtZXRyaWMgdmFsdWVzIGFmZmVjdCB0aGUgY29tcHV0ZWQN CiAgIGJhY2t1cCBwYXRocy4gIEhvd2V2ZXIsIGFkanVzdGluZyB0aGUgSUdQIGxpbmsgbWV0cmlj cyBpcyBub3QgYQ0KICAgZ2VuZXJhbGx5IGFwcGxpY2FibGUgdG9vbCBmb3IgbW9kaWZ5aW5nIHRo ZSBNUlQgYmFja3VwIHBhdGhzLg0KICAgQWNoaWV2aW5nIGEgZGVzaXJlZCBzZXQgb2YgTVJUIGJh Y2t1cCBwYXRocyBieSBhZGp1c3RpbmcgSUdQIG1ldHJpY3MNCiAgIHdoaWxlIGF0IHRoZSBzYW1l IHRpbWUgbWFpbnRhaW5pbmcgdGhlIGRlc2lyZWQgZmxvdyBvZiB0cmFmZmljIGFsb25nDQogICB0 aGUgc2hvcnRlc3QgcGF0aHMgaXMgbm90IHBvc3NpYmxlIGluIGdlbmVyYWwuDQoNCiAgIE1SVC1G UlIgYWxsb3dzIGFuIG9wZXJhdG9yIHRvIGV4Y2x1ZGUgYSBsaW5rIGZyb20gdGhlIE1SVCBJc2xh bmQsIGFuZA0KICAgdGh1cyB0aGUgR0FEQUcsIGJ5IGFkdmVydGlzaW5nIGl0IGFzIE1SVC1JbmVs aWdpYmxlLiAgU3VjaCBhIGxpbmsNCiAgIHdpbGwgbm90IGJlIHVzZWQgb24gdGhlIE1SVCBmb3J3 YXJkaW5nIHBhdGggZm9yIGFueSBkZXN0aW5hdGlvbi4NCiAgIEFkdmVydGlzaW5nIGxpbmtzIGFz IE1SVC1JbmVsaWdpYmxlIGlzIHRoZSBtYWluIHRvb2wgcHJvdmlkZWQgYnkgTVJULQ0KICAgRlJS IGZvciBrZWVwaW5nIGJhY2t1cCB0cmFmZmljIG9mZiBvZiBsb3dlciBiYW5kd2lkdGggbGlua3Mg ZHVyaW5nDQogICBmYXN0LXJlcm91dGUgZXZlbnRzLg0KPT09PT09PT09PT0NCi0tLQ0KIlRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGEgc29sdXRpb24gZm9yIElQL0xEUCBmYXN0LXJlcm91dGUgW1JG QzU3MTRdLiBNUlQtRlJSIGNyZWF0ZXMgdHdvIGFsdGVybmF0ZSB0cmVlcyBzZXBhcmF0ZSBmcm9t IHRoZSBwcmltYXJ5IG5leHQtaG9wIGZvcndhcmRpbmcgdXNlZCBkdXJpbmcgc3RhYmxlIG9wZXJh dGlvbi4iDQpPbmUgb2YgdGhlIHRyZWUgbWF5IHVzZSB0aGUgcHJpbWFyeSBuZXh0LWhvcCBhbmQg aGVuY2UgaXMgbm90IHRoYXQgc2VwYXJhdGUuDQoNCj09PT09PT09DQpbQ0JdICBDaGFuZ2VkICJz ZXBhcmF0ZSIgdG8gImRpc3RpbmN0IiBhbmQgbW9kaWZpZWQgd29yZGluZyB0byBjbGFyaWZ5LiBN b2RpZmVkIHRleHQ6DQoNCk1SVC1GUlIgY3JlYXRlcyB0d28gYWx0ZXJuYXRlIGZvcndhcmRpbmcg dHJlZXMgd2hpY2ggYXJlIGRpc3RpbmN0IGZyb20gDQp0aGUgcHJpbWFyeSBuZXh0LWhvcCBmb3J3 YXJkaW5nIHVzZWQgZHVyaW5nIHN0YWJsZSBvcGVyYXRpb24uDQo9PT09PT09PQ0KDQotLS0NCiJb VEktTEZBXSBhaW1zIHRvIHByb3ZpZGUiDQpBbGwgRlJSIHNvbHV0aW9ucyAicHJvdmlkZXMiIHdp bGwgVEktTEZBICJhaW1zIHRvIHByb3ZpZGUiIDstKSBBbHRob3VnaCBUSS1MRkEgaXMgbm90IGEg V0cgZG9jdW1lbnQsIElNSE8gdGhlIGRvY3VtZW50IGNvdWxkIHVzZSB0aGUgc2FtZSBmb3JtdWxh dGlvbiBmb3IgYWxsIEZSUiBzb2x1dGlvbnMuDQoNCj09PT09PT0NCltDQl0gV2FzIGluIHRoZSBu b3ctZGVsZXRlZCBjb21wYXJpc29uIHNlY3Rpb24uDQo9PT09PT09DQoNCi0tLQ0KwqcxLjENCiJB c3ltbWV0cmljIGxpbmsgY29zdHMgYXJlIGFsc28gYSBjb21tb24gYXNwZWN0IG9mIG5ldHdvcmtz LiAgVGhlcmUNCiAgIGFyZSBhdCBsZWFzdCB0aHJlZSBjb21tb24gY2F1c2VzIGZvciB0aGVtLiAg Rmlyc3QsIGFueSBicm9hZGNhc3QNCiAgIGludGVyZmFjZSBpcyByZXByZXNlbnRlZCBieSBhIHBz ZXVkby1ub2RlIGFuZCBoYXMgYXN5bW1ldHJpYyBsaW5rDQogICBjb3N0cyB0byBhbmQgZnJvbSB0 aGF0IHBzZXVkby1ub2RlLiAgU2Vjb25kLCB3aGVuIHJvdXRlcnMgY29tZSB1cCBvcg0KICAgYSBs aW5rIHdpdGggTERQIGNvbWVzIHVwLCBpdCBpcyByZWNvbW1lbmRlZCBpbiBbUkZDNTQ0M10gYW5k DQogICBbUkZDNjk4N10gdGhhdCB0aGUgbGluayBtZXRyaWMgYmUgcmFpc2VkIHRvIHRoZSBtYXhp bXVtIGNvc3Q7IHRoaXMNCiAgIG1heSBub3QgYmUgc3ltbWV0cmljIGFuZCBmb3IgW1JGQzY5ODdd IGlzIG5vdCBleHBlY3RlZCB0byBiZS4gIg0KICAgDQpHaXZlbiB0aGUgcHJldmlvdXMgRmlndXJl IDEsIEkgYXNzdW1lIHRoYXQgdGhlIHRhcmdldCBvZiB0aGUgY29tbWVudCBpcyBUSS1MRkEgbGlu ayBwcm90ZWN0aW9uIHdpdGggMiBsYWJlbHMuIEluIHRoaXMgY2FzZSwgMiBjb21tZW50czoNCi0g SUlOTSwgd2hhdCBpcyBuZWVkZWQgKGZvciB0aGUgcHJvb2YpIGlzIHN5bW1ldHJpYyBjb3N0IGJl dHdlZW4gX2ZvcndhcmRpbmdfIG5vZGVzLiBQc2V1ZG8tbm9kZSB3b3VsZCBub3QgY291bnQvYmUg YW4gaXNzdWUuDQotIFRJLUxGQSBuZWVkcyBTZWdtZW50IFJvdXRpbmcgaW4gd2hpY2ggY2FzZSBM RFAgd291bGQgbm90IGJlIHVzZWQuIEhlbmNlIGl0IGRvZXMgbm90IHNlZW0gZmFpciB0byBhc3N1 bWUgdGhhdCBMRFAtSUdQIHN5bmMgd291bGQgYmUgcHJlc2VudC4NCg0KPT09PT09PQ0KW0NCXSBJ IGRlbGV0ZWQgdGhpcyBwYXJhZ3JhcGguDQoNCj09PT09PT0NCg0KLS0tDQoiV2hlbiBhIG5ldHdv cmsgbmVlZHMgdG8gdXNlIGEgbWljcm8tbG9vcCBwcmV2ZW50aW9uIG1lY2hhbmlzbQ0KICAgW1JG QzU3MTVdIHN1Y2ggYXMgT3JkZXJlZCBGSUJbUkZDNjk3Nl0gb3IgTmVhcnNpZGUNCiAgIFR1bm5l bGluZ1tSRkM1NzE1XSwgdGhlbiB0aGUgd2hvbGUgSUdQIGFyZWEgbmVlZHMgdG8gaGF2ZSBhbHRl cm5hdGVzDQogICBhdmFpbGFibGUiDQoNCkkgd291bGQgcHJvcG9zZQ0KDQoiV2hlbiBhIG5ldHdv cmsgdG8gdXNlIE9yZGVyZWQgRklCW1JGQzY5NzZdIG9yIE5lYXJzaWRlDQogICBUdW5uZWxpbmdb UkZDNTcxNV0gYXMgYSBtaWNyby1sb29wIHByZXZlbnRpb24gbWVjaGFuaXNtDQogICBbUkZDNTcx NV0sIHRoZW4gdGhlIHdob2xlIElHUCBhcmVhIG5lZWRzIHRvIGhhdmUgYWx0ZXJuYXRlcw0KICAg YXZhaWxhYmxlIg0KICAgDQpNb3RpdmF0aW9uOiB0aGUgcmVxdWlyZW1lbnQgZm9yIEZSUiBjb21l cyBmcm9tIHRoZXNlIDIgc3BlY2lmaWMgc29sdXRpb25zLCBub3QgZnJvbSAiYSBtaWNyby1sb29w IHByZXZlbnRpb24gbWVjaGFuaXNtIi4gSSB3b24ndCBhcmd1ZSB3aGV0aGVyIHRoZSBvcmlnaW5h bCB0ZXh0IGlzIGZpbmUgZnJvbSBhbiBlbmdsaXNoIHN0YW5kcG9pbnQgKGFzIGl0IHdlbGwgYmV5 b25kIG15IHNraWxscyksIGJ1dCBvbmUgcmVhZGVyIGNvdWxkIG1pc2ludGVycHJldCBpdC4NCj09 PT09PT09PT09PT0NCltDQl0gQWdyZWVkLiAgQ2hhbmdlcyBpbjoNCmh0dHBzOi8vZ2l0aHViLmNv bS9jYm93ZXJzL2RyYWZ0LWlldGYtcnRnd2ctbXJ0LWZyci1hcmNoaXRlY3R1cmUvY29tbWl0L2Q2 MDMxYmE2Y2NmMjEwY2ZjMjRhOTBjNTVkMDhjODA3NzMwMDA1NDENCj09PT09PT09PT09PT0NCi0t LQ0KIkFEQUc6ICAgQWxtb3N0IERpcmVjdGVkIEFjeWNsaWMgR3JhcGggLSBhIGdyYXBoIHRoYXQs IGlmIGFsbCBsaW5rcyBpbmNvbWluZyB0byB0aGUgcm9vdCB3ZXJlIHJlbW92ZWQsIHdvdWxkIGJl IGEgREFHLiINCkl0J3Mgbm90IGNsZWFyIHRvIG1lIHdoYXQgInRoZSByb290IiBpcy4gSXQgc2Vl bXMgdG8gcmVmZXIgdG8gImEgZ3JhcGgiIGFuZCBJIGNhbid0IGZpbmQgaG93IHRoaXMgcm9vdCBp cyBkZXRlcm1pbmVkLiBNYXkgYmUgeW91IG1lYW4gOnMvZ3JhcGgvREFHICBidXQgZXZlbiBpbiB0 aGlzIGNhc2UsIGl0J3Mgbm90IG9idmlvdXMgdG8gbWUgdGhhdCB0aGVyZSBpcyBhIHNpbmdsZSAi cm9vdCIuIChzb3JyeSBpZiB0aGlzIGlzIG9idmlvdXMgZm9yIGV2ZXJ5b25lIGVsc2UuIE5vIG5l ZWQgdG8gZXhwbGFpbiBpdCB0byBtZS4gSSdtIGp1c3QgY2hlY2tpbmcgdGhhdCB0aGlzIGlzIHdl bGwgZGVmaW5lZCkNCj09PT09PT09PT09PT09DQpbQ0JdIEdvb2QgY2F0Y2guICBJIGhvcGUgdGhp cyB2ZXJzaW9uIGlzIG1vcmUgY2xlYXIuDQogICBBREFHOiAgIEFsbW9zdCBEaXJlY3RlZCBBY3lj bGljIEdyYXBoIC0gYSBncmFwaCB3aXRoIG9uZSBub2RlDQogICAgICBkZXNpZ25hdGVkIGFzIHRo ZSByb290LiAgVGhlIGdyYXBoIGhhcyB0aGUgcHJvcGVydHkgdGhhdCBpZiBhbGwNCiAgICAgIGxp bmtzIGluY29taW5nIHRvIHRoZSByb290IHdlcmUgcmVtb3ZlZCwgdGhlbiByZXN1bHRpbmcgZ3Jh cGgNCiAgICAgIHdvdWxkIGJlIGEgREFHLg0KPT09PT09PT09PT09PT0NCg0KLS0tDQrCpzYuMS4x LjENCiJIb3dldmVyLCBpdA0KICAgcmVkdWNlcyB0aGUgbGFiZWwgc3BhY2UgZm9yIG90aGVyIHVz ZXMsIGFuZCBpdCBpbmNyZWFzZXMgdGhlIG1lbW9yeQ0KICAgbmVlZGVkIHRvIHN0b3JlIHRoZSBs YWJlbHMgYW5kIHRoZSBjb21tdW5pY2F0aW9uIHJlcXVpcmVkIGJ5IExEUCB0bw0KICAgZGlzdHJp YnV0ZSBGRUMtbGFiZWwgYmluZGluZ3MuIg0KDQpJdCBhbHNvIGluY3JlYXNlIHRoZSB0aW1lIG5l ZWRlZCB0byBpbnN0YWxsIHRoZSBGUlIgZW50cmllcyBpbiB0aGUgRklCIGhlbmNlIHRoZSB0aW1l IG5lZWRlZCBiZWZvcmUgdGhlIG5leHQgZmFpbHVyZSBtYXkgYmUgcHJvdGVjdGVkLg0KPT09PT09 PT0NCltDQl0gIEFkZGVkIHRoZSBmb2xsb3dpbmcgdGV4dC4gDQoNCiAgIEluIGdlbmVyYWwsIHRo aXMgYXBwcm9hY2ggd2lsbCBhbHNvDQogICBpbmNyZWFzZSB0aGUgdGltZSBuZWVkZWQgdG8gaW5z dGFsbCB0aGUgRlJSIGVudHJpZXMgaW4gdGhlIEZJQiBhbmQNCiAgIGhlbmNlIHRoZSB0aW1lIG5l ZWRlZCBiZWZvcmUgdGhlIG5leHQgZmFpbHVyZSBjYW4gYmUgcHJvdGVjdGVkLg0KPT09PT09PT0N Cg0KLS0tDQpbUkZDNzMwN10gKExEUCBNVCkgaXMgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBmb3Ig Ym90aCBMRFAgYW5kIElQIHRyYWZmaWMuIEl0IG1heSBldmVudHVhbGx5IGJlIHNlZW4gYXMgYSBf bm9ybWF0aXZlXyByZWZlcmVuY2UuIA0KW0NCXSAgQ2hhbmdlZCBSRkM3MzA3IHRvIG5vcm1hdGl2 ZS4gIEFsc28gdG9vayB0aGUgb3Bwb3J0dW5pdHkgdG8gbW92ZSBSRkM1Mjg2IHRvIGluZm9ybWF0 aXZlLg0KDQotLS0NCiJBbGwgcm91dGVycyBpbiBhbiBNUlQgSXNsYW5kIE1VU1Qgc3VwcG9ydCB0 aGUgc2FtZSBNUlQgcHJvZmlsZS4iDQoNCm9rLCBidXQgSU1ITyB0aGlzIGlzIG1vcmUgYSBtYXR0 ZXIgb2YgZGVmaW5pdGlvbiB0aGFuIGEgbWF0dGVyIG9mIGJlaGF2aW9yIHRoYXQgTVVTVCBiZSBl bmZvcmNlZC4gU28gSSB3b3VsZCByYXRoZXIgaGF2ZSBhIGRlZmluaXRpb24gb2YgYW4gTVJUIElz bGFuZC4gKGUuZy4gQW4gTVJUIElzbGFuZCBpcyBkZWZpbmVkIGFzIHRoZSBzZXQgb2Ygcm91dGVy cyBzdXBwb3J0aW5nIHRoZSBzYW1lIE1SVCBwcm9maWxlLCBpbiB0aGUgc2FtZSBJR1AgYXJlYS9s ZXZlbCBhbmQgdGhlIGJpLWRpcmVjdGlvbmFscyBsaW5rcyBpbnRlcmNvbm5lY3RpbmcgdGhvc2Ug cm91dGVycywiLg0KDQo9PT09PT09PT09PT0NCltDQl0gR29vZCBwb2ludC4gSSBtYWRlIHRoZSBm b2xsb3dpbmcgY2hhbmdlcw0KDQogICBBdCBhIGhpZ2ggbGV2ZWwsIGFuIE1SVCBJc2xhbmQgaXMg ZGVmaW5lZCBhcyB0aGUgc2V0IG9mIHJvdXRlcnMNCiAgIHN1cHBvcnRpbmcgdGhlIHNhbWUgTVJU IHByb2ZpbGUsIGluIHRoZSBzYW1lIElHUCBhcmVhL2xldmVsIGFuZCB0aGUNCiAgIGJpLWRpcmVj dGlvbmFsIGxpbmtzIGludGVyY29ubmVjdGluZyB0aG9zZSByb3V0ZXJzLiAgTW9yZSBkZXRhaWxl ZA0KICAgZGVzY3JpcHRpb25zIG9mIHRoZXNlIGNyaXRlcmlhIGFyZSBnaXZlbiBiZWxvdy4NCg0K Ny4xLiAgSUdQIEFyZWEgb3IgTGV2ZWwNCg0KICAgQWxsIGxpbmtzIGluIGFuIE1SVCBJc2xhbmQg YXJlIGJpZGlyZWN0aW9uYWwgYW5kIGJlbG9uZyB0byB0aGUgc2FtZQ0KICAgSUdQIGFyZWEgb3Ig bGV2ZWwuICAuLi4uLi4NCg0KNy4yLiAgU3VwcG9ydCBmb3IgYSBzcGVjaWZpYyBNUlQgcHJvZmls ZQ0KDQogICBBbGwgcm91dGVycyBpbiBhbiBNUlQgSXNsYW5kIHN1cHBvcnQgdGhlIHNhbWUgTVJU IHByb2ZpbGUuICAuLi4uLi4uDQo9PT09PT09PT09PT0NCg0KLS0tDQrCpyA3LjIgIkEgZ2l2ZW4g cm91dGVyIGNhbiBzdXBwb3J0IG11bHRpcGxlIE1SVCBwcm9maWxlcyBhbmQgcGFydGljaXBhdGUg aW4gbXVsdGlwbGUgTVJUIElzbGFuZHMuIiBbLi4uXSAiTm90ZSB0aGF0IGEgcm91dGVyIG1heSBh ZHZlcnRpc2Ugc3VwcG9ydCBmb3IgbXVsdGlwbGUgZGlmZmVyZW50IE1SVCBwcm9maWxlcy4iDQoN CklNSE8gdGhlIHNlY29uZCBzZW50ZW5jZSBpcyByZWR1bmRhbnQgYW5kIGNvdWxkIGJlIHJlbW92 ZWQuDQo9PT09PQ0KW0NCXSBBZ3JlZWQuDQo9PT09PQ0KLS0tDQrCpzguMyAidGhlIG1vc3QgcHJl ZmVycmVkIEdBREFHIFJvb3QgU2VsZWN0aW9uIFByaW9yaXR5DQogICAgICBhZHZlcnRpc2VkIChj b3JyZXNwb25kaW5nIHRvIHRoZSBsb3dlc3QgbnVtZXJpY2FsIHZhbHVlIG9mIEdBREFHDQogICAg ICBSb290IFNlbGVjdGlvbiBQcmlvcml0eSkiDQoNCkRvIHlvdSBtZWFuIHRoYXQgdGhlIF9tb3N0 IHByZWZlcnJlZF8gaXMgdGhlIG5vZGUgYWR2ZXJ0aXNpbmcgdGhlIF9sb3dlc3QgcHJpb3JpdHlf PyBUaGlzIGRvZXMgbm90IHNlZW0gaW50dWl0aXZlIHRvIG1lLiBJZiBzbywgSU1ITyB0aGlzIHNo b3VsZCBiZSBzcGVjaWZpZWQgY2xlYXJseSBzb21ld2hlcmUsIG5vdCBqdXN0IGJldHdlZW4gYnJh Y2tldHMuCUJ1dCBJIHdvdWxkIHJhdGhlciBmYXZvcmluZyBhIGludHVpdGl2ZSBiZWhhdmlvciAo ZS5nLiBpZiBsb3dlc3QgbnVtZXJpY2FsIHZhbHVlIGlzIHByZWZlcmVkLCB1c2UgdGhlIHdvcmQg IkNvc3QiIG9yICJNZXRyaWMiIHJhdGhlciB0aGFuICJQcmlvcml0eSIuIElmICJQcmlvcml0eSIg aXMga2VwdCwgcHJlZmVyIHRoZSBoaWdoZXN0IHZhbHVlLiAgDQoNCj09PT09PT09PT09PT0NCltD Ql0gIEkgYWdyZWUgdGhhdCB0aGlzIGlzIGNvdW50ZXItaW50dWl0aXZlLiAgIEkgbG9va2VkIGlu dG8gY2hhbmdpbmcgdGhpcyBhIHdoaWxlIGJhY2ssIGJ1dCBJIHN0b3BwZWQgd2hlbiBJIGZvdW5k IG90aGVyIGV4YW1wbGVzIG9mIGxvd2VyIG51bWVyaWNhbCBwcmlvcml0eSB2YWx1ZXMgYmVpbmcg dXNlZCB0byBpbmRpY2F0ZSBoaWdoZXIgcHJlZmVyZW5jZS4gUkZDIDMyMDkgKFJTVlAtVEUpIHVz ZXMgdGhpcyBjb252ZW50aW9uIGZvciBzZXR1cCBwcmlvcml0eSBmb3IgUlNWUCBMU1BzLiA4MDIu MUQgKHNwYW5uaW5nIHRyZWUpIHVzZXMgaXQgZm9yIGJyaWRnZSBwcmlvcml0eS4gICAgSSB0aGlu ayB0aGF0IGNoYW5naW5nIHRoZSBhY3R1YWwgb3JkZXJpbmcgaW4gdGhlIGFsZ29yaXRobSBhdCB0 aGlzIHBvaW50IGluIG5vdCBhIGdvb2QgaWRlYSBzaW5jZSBpdCB3aWxsIGNyZWF0ZSBjb25mdXNp b24uICBJIGFtIG5vdCBvcHBvc2VkIHRvIGNoYW5naW5nIHRoZSBuYW1lLCBidXQgSSB3b3VsZCBh bHNvIG5lZWQgdG8gcHJvcGFnYXRlIHRoYXQgY2hhbmdlIGludG8gdGhlIGFsZ29yaXRobSBkcmFm dCB0ZXh0LCBwc2V1ZG8tY29kZSwgYW5kIFB5dGhvbiBpbXBsZW1lbnRhdGlvbiwgc28gaWYgd2Ug Y2hhbmdlIHRoZSBuYW1lLCBJIG9ubHkgd2FudCBkbyBpdCBvbmNlLiAgDQoNClNvbWVob3cgImNv c3QiIGFuZCAibWV0cmljIiBkb27igJl0IHNlZW0gbGlrZSBnb29kIG9wdGlvbnMgYmVjYXVzZSB0 aGVyZSBpcyBhbHJlYWR5IHRoZSBJR1AgY29zdCBvciBtZXRyaWMgaW4gdGhpcyBwcm9ibGVtIGRv bWFpbi4gQWxzbyBjb3N0cyBhbmQgbWV0cmljcyBhcmUgdHlwaWNhbGx5IGN1bXVsYXRpdmUsIHdo ZXJlYXMgdGhpcyBpcyBub3QuICBNeSBwcmVmZXJlbmNlIGF0IHRoaXMgcG9pbnQgd291bGQgYmUg Zm9yIHNvbWV0aGluZyBuZXV0cmFsIGxpa2UgIkdBREFHIFJvb3QgU2VsZWN0aW9uIE51bWJlciIg b3IgIkdBREFHIFJvb3QgU2VsZWN0aW9uIFZhbHVlIiBzbyB0aGF0IHRoZSB1c2VyIGlzIG5vdCBt aXNsZWQgaW50byBtYWtpbmcgYXNzdW1wdGlvbnMgYWJvdXQgaG93IHRoZSB2YWx1ZSBpcyB1c2Vk LiAgQW5vdGhlciBvcHRpb24gd291bGQgYmUgIkdBREFHIFJvb3QgU2VsZWN0aW9uIFBlbmFsdHki LiAgDQoNCkZvciB0aGUgbW9tZW50LCBJJ3ZlIHRyaWVkIHRvIGFkZHJlc3MgcG90ZW50aWFsIGNv bmZ1c2lvbiB3aGlsZSBsZWF2aW5nIHRoZSBuYW1lIHRoZSBzYW1lIHdpdGggdGhlIHRleHQgYmVs b3csIGJ1dCB3b3VsZCBhcHByZWNpYXRlIGZlZWRiYWNrIG9uIHRoZSBhYm92ZSBzdWdnZXN0aW9u IGFzIHdlbGwuDQoNCiAgIEdBREFHIFJvb3QgU2VsZWN0aW9uIFBvbGljeTogICBBbW9uZyB0aGUg cm91dGVycyBpbiB0aGUgTVJUIElzbGFuZA0KICAgICAgd2l0aCB0aGUgbG93ZXN0IG51bWVyaWNh bCB2YWx1ZSBhZHZlcnRpc2VkIGZvciBHQURBRyBSb290DQogICAgICBTZWxlY3Rpb24gUHJpb3Jp dHksIGFuIGltcGxlbWVudGF0aW9uIE1VU1QgcGljayB0aGUgcm91dGVyIHdpdGgNCiAgICAgIHRo ZSBoaWdoZXN0IFJvdXRlciBJRCB0byBiZSB0aGUgR0FEQUcgcm9vdC4gIE5vdGUgdGhhdCBhIGxv d2VyDQogICAgICBudW1lcmljYWwgdmFsdWUgZm9yIEdBREFHIFJvb3QgU2VsZWN0aW9uIFByaW9y aXR5IGluZGljYXRlcyBhDQogICAgICBoaWdoZXIgcHJlZmVyZW5jZSBmb3Igc2VsZWN0aW9uLg0K PT09PT09PT09PT09PQ0KLS0NCsKnNi4xLjEuNA0KIklmIGEgcm91dGVyIHN1cHBvcnRzIGEgcHJv ZmlsZSB0aGF0IGluY2x1ZGVzIHRoZSBNUlQgTERQIExhYmVsIG9wdGlvbg0KICAgZm9yIE1SVCB0 cmFuc2l0IGZvcndhcmRpbmcgbWVjaGFuaXNtLCB0aGVuIGl0IE1VU1Qgc3VwcG9ydCBvcHRpb24g MUEsDQogICB3aGljaCBlbmNvZGVzIHRvcG9sb2d5LXNjb3BlZCBGRUNzIHVzaW5nIGEgc2luZ2xl IGxhYmVsLiINCg0Kb2suIEJ1dCBpbiB0aGlzIGNvbmRpdGlvbiwgSSdtIG5vdCBzdXJlIHRvIHNl ZSBhIHJlYXNvbiB3aHkgYW55b25lIHdvdWxkIGltcGxlbWVudCBvcHRpb24gMUIgaW4gYWRkaXRp b24uIEluIHdoaWNoIGNhc2UsIGl0IG1heSBoYXZlIHNpbXBsaWZpZWQgdGhlIHNwZWMgdG8ganVz dCBtb3ZlIG9wdGlvbiAxQiBpbiBhcHBlbmRpeCBhbmQgaGVuY2UgcmVtb3ZlIE1SVCBMRFAgbGFi ZWwgb3B0aW9ucy4NCj09PT09PT0NCltDQl0gIEkgbW9kaWZpZWQgdGhlIGV4aXN0aW5nIHRleHQg dG8gY2xhcmlmeSB0aGUgcmVhc29uaW5nLiAgVGhlIG1haW4gY2hhbmdlcyBhbmQgYWRkZWQgdGV4 dCBhcmUgY29waWVkIGJlbG93LCBidXQgc2VlIHRoaXMgZ2l0aHViIGRpZmYgZm9yIHRoZSBjb21w bGV0ZSBzZXQgb2YgY2hhbmdlcy4NCg0KaHR0cHM6Ly9naXRodWIuY29tL2Nib3dlcnMvZHJhZnQt aWV0Zi1ydGd3Zy1tcnQtZnJyLWFyY2hpdGVjdHVyZS9jb21taXQvMGY3ZGUyM2I1MGFhZTA1NGRh YTE3YWU2MmE0MGU1MzY2YzY2OWNhZg0KDQoNCjYuMS4xLjMuICBDb21wYXRpYmlsaXR5IG9mIE1S VCBMRFAgTGFiZWwgT3B0aW9ucyAxQSBhbmQgMUINCg0KICAgTVJUIHRyYW5zaXQgZm9yd2FyZGlu ZyBiYXNlZCBvbiBNUlQgTERQIExhYmVsIG9wdGlvbnMgMUEgYW5kIDFCIGNhbg0KICAgY29leGlz dCBpbiB0aGUgc2FtZSBuZXR3b3JrLCB3aXRoIGEgcGFja2V0IGJlaW5nIGZvcndhcmRlZCBhbG9u ZyBhDQogICBzaW5nbGUgTVJUIHBhdGggdXNpbmcgdGhlIHNpbmdsZSBsYWJlbCBvZiBvcHRpb24g MUEgZm9yIHNvbWUgaG9wcyBhbmQNCiAgIHRoZSB0d28gbGFiZWwgc3RhY2sgb2Ygb3B0aW9uIDFC IGZvciBvdGhlciBob3BzLiAgSG93ZXZlciwgdG8NCiAgIHNpbXBsaWZ5IHRoZSBwcm9jZXNzIG9m IE1SVCBJc2xhbmQgZm9ybWF0aW9uIHdlIHJlcXVpcmUgdGhhdCBhbGwNCiAgIHJvdXRlcnMgaW4g dGhlIE1SVCBJc2xhbmQgc3VwcG9ydCBhdCBsZWFzdCBvbmUgY29tbW9uIGZvcndhcmRpbmcNCiAg IG1lY2hhbmlzbS4gIEFzIGFuIGV4YW1wbGUsIHRoZSBEZWZhdWx0IE1SVCBQcm9maWxlIHJlcXVp cmVzIHN1cHBvcnQNCiAgIGZvciB0aGUgTVJUIExEUCBMYWJlbCBPcHRpb24gMUEgZm9yd2FyZGlu ZyBtZWNoYW5pc20uICBUaGlzIGVuc3VyZXMNCiAgIHRoYXQgdGhlIHJvdXRlcnMgaW4gYW4gTVJU IGlzbGFuZCBzdXBwb3J0aW5nIHRoZSBEZWZhdWx0IE1SVCBQcm9maWxlDQogICB3aWxsIGJlIGFi bGUgdG8gZXN0YWJsaXNoIE1SVCBmb3J3YXJkaW5nIHBhdGhzIGJhc2VkIG9uIE1SVCBMRFAgTGFi ZWwNCiAgIE9wdGlvbiAxQS4gIEhvd2V2ZXIsIGFuIGltcGxlbWVudGF0aW9uIHN1cHBvcnRpbmcg T3B0aW9uIDFBIG1heSBhbHNvDQogICBzdXBwb3J0IE9wdGlvbiAxQi4gIElmIHRoZSBzY2FsaW5n IG9yIHBlcmZvcm1hbmNlIGNoYXJhY3RlcmlzdGljcyBmb3INCiAgIHRoZSB0d28gb3B0aW9ucyBk aWZmZXIgaW4gdGhpcyBpbXBsZW1lbnRhdGlvbiwgdGhlbiBpdCBtYXkgYmUNCiAgIGRlc2lyYWJs ZSBmb3IgYSBwYWlyIG9mIGFkamFjZW50IHJvdXRlcnMgdG8gdXNlIE9wdGlvbiAxQiBsYWJlbHMN CiAgIGluc3RlYWQgb2YgdGhlIE9wdGlvbiAxQSBsYWJlbHMuICBJZiB0aG9zZSByb3V0ZXJzIHN1 Y2Nlc3NmdWxseQ0KICAgbmVnb3RpYXRlIHRoZSB1c2Ugb2YgT3B0aW9uIDFCIGxhYmVscywgdGhl eSBhcmUgZnJlZSB0byB1c2UgdGhlbS4NCiAgIFRoaXMgY2FuIG9jY3VyIHdpdGhvdXQgYW55IG9m IHRoZSBvdGhlciByb3V0ZXJzIGluIHRoZSBNUlQgSXNsYW5kDQogICBiZWluZyBtYWRlIGF3YXJl IG9mIGl0Lg0KDQogICBOb3RlIHRoYXQgdGhpcyBkb2N1bWVudCBvbmx5IGRlZmluZXMgdGhlIERl ZmF1bHQgTVJUIFByb2ZpbGUgd2hpY2gNCiAgIHJlcXVpcmVzIHN1cHBvcnQgZm9yIHRoZSBNUlQg TERQIExhYmVsIE9wdGlvbiAxQSBmb3J3YXJkaW5nDQogICBtZWNoYW5pc20uDQoNCjYuMS4xLjQu ICBSZXF1aXJlZCBzdXBwb3J0IGZvciBNUlQgTERQIExhYmVsIG9wdGlvbnMNCg0KICAgSWYgYSBy b3V0ZXIgc3VwcG9ydHMgYSBwcm9maWxlIHRoYXQgaW5jbHVkZXMgdGhlIE1SVCBMRFAgTGFiZWwg T3B0aW9uDQogICAxQSBmb3IgdGhlIE1SVCB0cmFuc2l0IGZvcndhcmRpbmcgbWVjaGFuaXNtLCB0 aGVuIGl0IE1VU1Qgc3VwcG9ydA0KICAgb3B0aW9uIDFBLCB3aGljaCBlbmNvZGVzIHRvcG9sb2d5 LXNjb3BlZCBGRUNzIHVzaW5nIGEgc2luZ2xlIGxhYmVsLg0KICAgVGhlIHJvdXRlciBNQVkgYWxz byBzdXBwb3J0IG9wdGlvbiAxQi4NCg0KICAgSWYgYSByb3V0ZXIgc3VwcG9ydHMgYSBwcm9maWxl IHRoYXQgaW5jbHVkZXMgdGhlIE1SVCBMRFAgTGFiZWwgT3B0aW9uDQogICAxQiBmb3IgdGhlIE1S VCB0cmFuc2l0IGZvcndhcmRpbmcgbWVjaGFuaXNtLCB0aGVuIGl0IE1VU1Qgc3VwcG9ydA0KICAg b3B0aW9uIDFCLCB3aGljaCBlbmNvZGVzIHRoZSB0b3BvbG9neSBhbmQgRkVDIHVzaW5nIGEgdHdv IGxhYmVsDQogICBzdGFjay4gIFRoZSByb3V0ZXIgTUFZIGFsc28gc3VwcG9ydCBvcHRpb24gMUEu DQoNCj09PT09PT09PT09PT09PT09PT09PT0NCi0tDQrCpzEwDQogIlNlY29uZCwgdGhpcyBhbGxv d3MgZmFpbHVyZXMgdGhhdCBtaWdodCBhcHBlYXIgaW4gbXVsdGlwbGUgYXJlYXMNCiAgIChlLmcu ICBBQlIvTEJSIGZhaWx1cmVzKSB0byBiZSBzZXBhcmF0ZWx5IGlkZW50aWZpZWQgYW5kIHJlcGFp cmVkDQogICBhcm91bmQuICBUaGlyZCwgdGhlIHBhY2tldCBjYW4gYmUgZmFzdC1yZXJvdXRlZCBh Z2FpbiwgaWYgbmVjZXNzYXJ5LA0KICAgZHVlIHRvIGEgZmFpbHVyZSBpbiBhIGRpZmZlcmVudCBh cmVhLiINCg0KSXQncyBub3Qgb2J2aW91cyB0byBtZSB3aHkgdGhlIHNlY29uZCBhbmQgdGhpcmQg cmVhc29ucyBhcmUgcmVhbGx5IGRpZmZlcmVudC4NCj09PT09PT09PT0NCltDQl0gIFJld3JvdGUg dGhlIGZvbGxvd2luZyB0ZXh0IHRvIGNsYXJpZnkuDQoNCiAgIFNlY29uZCwgdGhpcyBhbGxvd3Mg YSBzaW5nbGUgcm91dGVyIGZhaWx1cmUgdGhhdCBtYW5pZmVzdHMgaXRzZWxmIGluDQogICBtdWx0 aXBsZSBhcmVhcyAoYXMgd291bGQgYmUgdGhlIGNhc2Ugd2l0aCBhbiBBQlIvTEJSIGZhaWx1cmUp IHRvIGJlDQogICBzZXBhcmF0ZWx5IGlkZW50aWZpZWQgYW5kIHJlcGFpcmVkIGFyb3VuZC4gIFRo aXJkLCB0aGUgcGFja2V0IGNhbiBiZQ0KICAgZmFzdC1yZXJvdXRlZCBhZ2FpbiwgaWYgbmVjZXNz YXJ5LCBkdWUgdG8gYSBzZWNvbmQgZGlzdGluY3QgZmFpbHVyZQ0KICAgaW4gYSBkaWZmZXJlbnQg YXJlYS4NCj09PT09PT09PT09DQoNCi0tLQ0KwqcxMA0KIiAgIEFuIEFCUi9MQlIgdGhhdCByZWNl aXZlcyBhIHBhY2tldCBvbiBNUlQtUmVkIG9yIE1SVC1CbHVlIHRvd2FyZHMNCiAgIGRlc3RpbmF0 aW9uIFogc2hvdWxkIGNvbnRpbnVlIHRvIGZvcndhcmQgdGhlIHBhY2tldCBhbG9uZyBNUlQtUmVk IG9yDQogICBNUlQtQmx1ZSBvbmx5IGlmIHRoZSBiZXN0IHJvdXRlIHRvIFogaXMgaW4gdGhlIHNh bWUgYXJlYSBhcyB0aGUNCiAgIGludGVyZmFjZSB0aGF0IHRoZSBwYWNrZXQgd2FzIHJlY2VpdmVk IG9uLiAgIA0KDQpUaGlzIHNlZW1zIGEgYml0IE9TUEYgc3BlY2lmaWMuIFdoYXQgYWJvdXQgSVMt SVM/IEluIHBhcnRpY3VsYXIgd2hlbiBzb21lIHJvdXRlcnMgbWF5IGJlIGluIGJvdGggbGV2ZWxz Lg0KICAgDQpJZGVtIGluIMKnMTAuMToNCiIgVG8gdGhvc2Ugcm91dGVycyBpbiB0aGUgc2FtZSBh cmVhIGFzIHRoZSBiZXN0IHJvdXRlIHRvIHRoZQ0KICAgZGVzdGluYXRpb24sIHRoZSBBQlIvTEJS IGFkdmVydGlzZXMgdGhlIGZvbGxvd2luZyBGRUMtbGFiZWwgYmluZGluZ3M6Ig0KDQpIb3cgZG8g dGhpcyBhcHBseSB0byBJUy1JUyBMQlI/DQoNCj09PT09PT09PT0NCltDQl0NCkkgY3JlYXRlZCBh biBhcHBlbmRpeCB0byBleHBsaWNpdGx5IGRlc2NyaWJlIHRoZSBJUy1JUyBpbnRlci1sZXZlbCBm b3J3YXJkaW5nIGJlaGF2aW9yLiAgUGxlYXNlIHNlZSB0aGUgbGF0ZXN0IGRyYWZ0IGZvciB0aGF0 IGFwcGVuZGl4Lg0KDQo9PT09PT09PT09DQogDQotLS0NCiAiVGhlIHVzZSBvZiB0aGUgUmFpbmJv dy1GRUMgYnkgdGhlIEFCUiBmb3Igbm9uLWJlc3QtYXJlYSBhZHZlcnRpc2VtZW50cyBpcyBSRUNP TU1FTkRFRC4iDQoNCiBJIGRvbid0IHNlZSB0aGUgYmFzaXMgZm9yIHRoaXMgcmVjb21tZW5kYXRp b24uIFRoaXMgY2hvaWNlIHNlZW1zIGRyaXZlbiBieSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbnMu IE90aGVyIGltcGxlbWVudGF0aW9ucyBtYXkgaGF2ZSBubyByZWFzb24gdG8gc2VuZCB0aGUgUmFp bmJvdy1GRUMuDQogSU1PLCBpdCB3b3VsZCBiZSBlbm91Z2ggdG8gc2F5ICJhIHJvdXRlciB0aGF0 IHN1cHBvcnRzIHRoZSBMRFAgTGFiZWwgTVJUIEZvcndhcmRpbmcgTWVjaGFuaXNtIE1VU1QgYmUg YWJsZSB0byByZWNlaXZlIGFuZCBjb3JyZWN0bHkgaW50ZXJwcmV0IHRoZSBSYWluYm93LUZFQy4i IHdoaWNoIGlzIGFscmVhZHkgc2FpZC4gSGVuY2UgSSB3b3VsZCBwcm9wb3NlOg0KDQogT0xEOg0K ICAgIFRoZSB1c2Ugb2YgdGhlIFJhaW5ib3ctRkVDIGJ5IHRoZSBBQlIgZm9yIG5vbi1iZXN0LWFy ZWENCiAgIGFkdmVydGlzZW1lbnRzIGlzIFJFQ09NTUVOREVELiAgQW4gQUJSIE1BWSBhZHZlcnRp c2UgdGhlIGxhYmVsIGZvcg0KICAgdGhlIGRlZmF1bHQgdG9wb2xvZ3kgaW4gc2VwYXJhdGUgTVJU LUJsdWUgYW5kIE1SVC1SZWQgYWR2ZXJ0aXNlbWVudHMuDQogICBIb3dldmVyLCBhIHJvdXRlcg0K IA0KIE5FVzoNCiAgIEFuIEFCUiBtYXkgY2hvb3NlIHRvIGVpdGhlciBhZHZlcnRpc2UgdGhlIFJh aW5ib3ctRkVDIG9yIGFkdmVydGlzZSBzZXBhcmF0ZSBNUlQtQmx1ZSBhbmQgTVJULVJlZCBhZHZl cnRpc2VtZW50cy4gVGhpcyBpcyBhIGxvY2FsIGNob2ljZS4NCiAgIEEgcm91dGVyDQoNCkluIHdo aWNoIGNhc2UsIHNlY3Rpb24gMTAuMSB3b3VsZCBuZWVkIHRvIGJlIHVwZGF0ZWQgdG8gcmVmbGVj dCB0aGlzLiAgIA0KPT09PT09PT0NCltDQl0gQWdyZWVkLiAgQ2hhbmdlcyBjYXB0dXJlZCBpbiB0 aGlzIGRpZmYuDQpodHRwczovL2dpdGh1Yi5jb20vY2Jvd2Vycy9kcmFmdC1pZXRmLXJ0Z3dnLW1y dC1mcnItYXJjaGl0ZWN0dXJlL2NvbW1pdC9lODg0ZTIyNmY3MjU2MDcyMWEyYWIzMzg4MjI0ODk5 Mzk4NjZiM2M3DQoNCj09PT09PT09DQoNCg0KLS0tDQrCpzE2IElBTkENCkluIGRyYWZ0LWhhYXMt Y29kZS1wb2ludC1yZXNlcnZhdGlvbi1iY3AsIEplZmYgcHJvcG9zZWQgdG8gcmVzZXJ2ZSB0aGUg bGFzdCBjb2RlIHBvaW50ICgyNTUpIHRvIGFsbG93IGZvciBmdXR1cmUgZXh0ZW5zaW9uLiBXaGls ZSBJJ20gbm90IHN1cmUgdGhpcyB3b3VsZCBiZSBuZWVkZWQgZm9yIE1SVCBwcm9maWxlcywgdGhp cyB3b3VsZCBhbHNvIGNhdXNlIG5vIGhhcm0uDQo9PT09PT09PT0NCltDQl0gR29vZCBwb2ludC4g IEFkZHJlc3NlZCBoZXJlLg0KDQpodHRwczovL2dpdGh1Yi5jb20vY2Jvd2Vycy9kcmFmdC1pZXRm LXJ0Z3dnLW1ydC1mcnItYXJjaGl0ZWN0dXJlL2NvbW1pdC8xNDQ1NTE0ZWFhZGU3NmU3YTg2MDVl YWFlMTg3ODBlNjllMTI3ZWFkDQoNCj09PT09PT09PQ0KDQoNCk5pdHM6DQotIExGQSBpbXBvc2Vz IG5vIGFkZGl0aW9uYWwgbGFiZWxzIGltcG9zZWQgdG9vIG1hbnkgImltcG9zZSI/DQotIDpzL0lT SVMvSVMtSVMNCi0gOnMvaW1wbG1lbnRhdGlvbnMvaW1wbGVtZW50YXRpb25zDQoNCj09PT09PT09 PT09PT09DQpbQ0JdIEFncmVlZC4gIA0KDQo9PT09PT09PT09PT09PQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv bi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz aWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu DQpUaGFuayB5b3UuDQoNCg0K From nobody Mon Feb 8 02:30:08 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081FE1ACE82; Mon, 8 Feb 2016 02:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.401 X-Spam-Level: ** X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 6JtAlvY6URLw; Mon, 8 Feb 2016 02:30:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A36D1ACE8D; Mon, 8 Feb 2016 02:30:01 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C610F22C3FC; Mon, 8 Feb 2016 11:29:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E83D723807D; Mon, 8 Feb 2016 11:29:58 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0279.002; Mon, 8 Feb 2016 11:29:55 +0100 From: To: Chris Bowers Thread-Topic: RtgDir review: draft-ietf-rtgwg-mrt-frr-architecture-09 Thread-Index: AdFapJJOEIRxVEGZTDqri7ekVvJZbAACsUdwAefb1sA= Date: Mon, 8 Feb 2016 10:29:55 +0000 Message-ID: <23730_1454927399_56B86E26_23730_3093_3_53C29892C857584299CBF5D05346208A0F7C0883@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <23108_1454079959_56AB7FD7_23108_16575_1_53C29892C857584299CBF5D05346208A0F7A569A@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.8.84516 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-rtgwg-mrt-frr-architecture@ietf.org" , "rtgwg@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-rtgwg-mrt-frr-architecture-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 10:30:07 -0000 Q2hyaXMsDQoNClRoYW5rcyBmb3IgY29uc2lkZXJpbmcgbXkgY29tbWVudHMgYW5kIHRha2luZyB0 aGVtIGludG8gYWNjb3VudC4NCg0KTG9va3MgYWxsIGdvb2QgdG8gbWUuDQoNCjEgcG9pbnQgaW5s aW5lIFtCcnVub10gYXMgeW91IGV4cGxpY2l0bHkgYXNrZWQgZm9yIGZlZWRiYWNrLg0KDQpCcnVu bw0KDQoNCj4gRnJvbTogQ2hyaXMgQm93ZXJzIFttYWlsdG86Y2Jvd2Vyc0BqdW5pcGVyLm5ldF0g PiBTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMDYsIDIwMTYgMjoyMSBBTQ0KPiANCj4gQnJ1bm8s DQo+IA0KPiBUaGFua3MgZm9yIHRoZSBkZXRhaWxlZCBjb21tZW50cy4gIFdlIGhhdmUgcHVibGlz aGVkIGEgbmV3IHJldmlzaW9uDQo+IGluY29ycG9yYXRpbmcgeW91ciBmZWVkYmFjaywgYXMgd2Vs bCBhcyBzb21lIG91dHN0YW5kaW5nIGZlZWRiYWNrIGZyb20NCj4gV0cgbGFzdCBjYWxsLCBBRCBy ZXZpZXcsIGFuZCB0aGUgSUVTRy4NCj4gDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGd3Zy1tcnQtZnJyLQ0KPiBhcmNoaXRlY3R1cmUt MTANCj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLXJ0Z3dnLW1ydC1mcnItDQo+IGFyY2hpdGVjdHVyZS0xMA0KPiANCj4gU3BlY2lm aWMgY29tbWVudCBhcmUgYWRkcmVzc2VkIGJlbG93IHdpdGggW0NCXS4NCj4gDQo+IFRoYW5rcywN Cj4gQ2hyaXMNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGJydW5v LmRlY3JhZW5lQG9yYW5nZS5jb20gW21haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tXQ0K PiBTZW50OiBGcmlkYXksIEphbnVhcnkgMjksIDIwMTYgOTowNiBBTQ0KPiBUbzogcnRnLWFkc0Bp ZXRmLm9yZw0KPiBDYzogcnRnd2dAaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0LWll dGYtcnRnd2ctbXJ0LWZyci0NCj4gYXJjaGl0ZWN0dXJlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJ0 Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtcnRnd2ctbXJ0LWZyci1hcmNoaXRlY3R1cmUtMDkNCj4g DQo+IEhlbGxvLA0KPiANCj4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGly ZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZQ0KPiBSb3V0aW5nIERpcmVjdG9y YXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRz IGFzDQo+IHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywg YW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsDQo+IHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSBy ZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nDQo+IEFEcy4gRm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBz ZWUgDQo+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdE aXINCj4gDQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdA0KPiB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3Vs ZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdA0KPiBDYWxsIGNv bW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91 Z2gNCj4gZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+IA0KPiBEb2N1bWVu dDogZHJhZnQtaWV0Zi1ydGd3Zy1tcnQtZnJyLWFyY2hpdGVjdHVyZS0wOS50eHQNCj4gUmV2aWV3 ZXI6IEJydW5vIERlY3JhZW5lDQo+IFJldmlldyBEYXRlOiAyMDE2LTAxLTI5DQo+IElFVEYgTEMg RW5kIERhdGU6IDIwMTYtMDEtMjkNCj4gSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sN Cj4gDQo+IFN1bW1hcnk6DQo+ICAgICBJIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91dCB0 aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUNCj4gcmVzb2x2ZWQgYmVmb3JlIHB1 YmxpY2F0aW9uLg0KPiANCj4gQ29tbWVudHM6DQo+ICAgIERvY3VtZW50IGlzIGNsZWFyIGFuZCB2 ZXJ5IHdlbGwgd3JpdHRlbi4gVGhhbmsgeW91LiBWZXJ5IG11Y2gNCj4gYXBwcmVjaWF0ZWQgZ2l2 ZW4gdGhlIHNpemUgb2YgdGhlIGRvY3VtZW50IGFuZCB0aGUgc3ViamVjdC4NCj4gDQo+IE1ham9y cyBJc3N1ZXM6DQo+ICAgIE5vbmUNCj4gDQo+IE1pbm9yIElzc3VlczoNCj4gDQo+IC0tLS0NCj4g LSBzZWN0aW9uIDY6IFVuaWNhc3QgZm9yd2FyZGluZyB3aXRoIE1SVCBhbmQgRmFzdC1SZXJvdXRl IFRoaXMgc2VjdGlvbiBsaXN0DQo+IG1hbnkgcG9zc2liaWxpdGllcyBvZiB3aGF0IGNvdWxkIGhh dmUgYmUgZG9uZSBvciB3aGF0IGNvdWxkIGJlIHVzZWQuIFRoaXMgaXMNCj4gdmVyeSBpbnRlcmVz dGluZyBhbmQgb3BlbiBsYXJnZXIgcG9zc2liaWxpdGllcywgYnV0IGZvciBhIFNURCB0cmFjayBk b2N1bWVudCwNCj4gaXQgbWF5IGhhdmUgYmVlbiBtb3JlIHByZXNjcmlwdGl2ZS4gIChhbmQgdGhl IGxhc3QgcGFyYWdyYXBoIG9mIMKnNi4zLjEuMg0KPiBzdGFydGluZyB3aXRoICJGb3IgY29tcGxl dGVuZXNzIiBmdXJ0aGVyIHB1c2ggdGhlIGN1cnNvciBvbiB0aGUgc2lkZSBvZg0KPiBjYXRhbG9n IG9mIHBvc3NpYmxlIHNvbHV0aW9ucyByYXRoZXIgdGhhbiB0aGUgc3BlY2lmaWNhdGlvbiBvZiBh IG9uZSBTVEQgdHJhY2sNCj4gc29sdXRpb24uKSBCdXQgSSBhZ3JlZSB0aGF0IHRoZSAiTVJUIGFy Y2hpdGVjdHVyZSIgY291bGQgYmUgc2VlbiBhcyBicm9hZGVyDQo+IHRoYW4gYSBzaW5nbGUgc29s dXRpb24uIEFuZCB0aGUgZG9jdW1lbnQgcHJvcG9zZSB0aGUgZGVmaW5pdGlvbiBvZiAiTVJUDQo+ IHByb2ZpbGVzIiB3aGljaCBzZWVtIGFwcHJvcHJpYXRlIHRvIGFsbG93IGZvciBpbnRlcm9wZXJh YmxlIGRlcGxveW1lbnRzDQo+IChidXQgYXMgYSBzaW5nbGUgcHJvZmlsZSBpcyBkZWZpbmVkLCBp dCB3b3VsZCBoYXZlIGJlZW4gcG9zc2libGUgdG8gd3JpdGUgYQ0KPiBzaW5nbGUgc29sdXRpb24s IHdoaWxlIHN0aWxsIGJlaW5nIGV4dGVuZGFibGUgaW4gdGhlIGZ1dHVyZSkuDQo+IA0KPiBFdmVu dHVhbGx5IEkgd291bGQgcHJvcG9zZSBhIHNsaWdodCBjaGFuZ2UgaW4gdGhlIFRvQyBmb3IgdGhl IHJlYWRlciB0byBtb3JlDQo+IGVhc2lseSB1bmRlcnN0YW5kIHdoYXQgaXMgb3B0aW9uYWwgdnMg cmVxdWlyZWQ6DQo+IDpzLzYuMSBNUlQgRm9yd2FyZGluZyBNZWNoYW5pc21zLzYuMSBJbnRyb2R1 Y3Rpb24gdG8gTVJUIEZvcndhcmRpbmcNCj4gb3B0aW9ucyBBZGRpbmcgIjYuMi40IFJlcXVpcmVk IHN1cHBwb3J0IiwgdXNpbmcgIjYuMy4zIFJlcXVpcmVkIHN1cHBvcnQiIGFzDQo+IG1vZGVsIChw bHVzIG1vdmluZyB0aGUgbGFzdCBzZW50ZW5jZSBvZiA2LjIuMyBpbiB0aGlzIHNlY3Rpb24pDQo+ IA0KPiBbQ0JdICBHb29kIGlkZWEuICBDaGFuZ2VzIGltcGxlbWVudGVkIGluOg0KPiBodHRwczov L2dpdGh1Yi5jb20vY2Jvd2Vycy9kcmFmdC1pZXRmLXJ0Z3dnLW1ydC1mcnItDQo+IGFyY2hpdGVj dHVyZS9jb21taXQvZTVmMzg3YzljYzE3NTE0NzUyNDBiMDJlMGI3OTg2MWY0ZDg0ZTMxOA0KPiAN Cj4gLS0tLQ0KPiBDb21wYXJpc29uOg0KPiBbTm90ZTogWWVzLCBJIHJlYWQgdGhhdCBhdXRob3Jz IHdpbGwgcmVtb3ZlIHRoZSBjb21wYXJpc29uIHRhYmxlIGluIHRoZSBuZXh0DQo+IHZlcnNpb24u IDotKSBCdXQgSSBoYWQgc3RhcnRlZCB0aGUgcmV2aWV3IGJlZm9yZSwgYW5kIEknbSBzdGlsbCBy ZXZpZXdpbmcgdGhlDQo+IGxhdGVzdCB2ZXJzaW9uLl0NCj4gDQo+IEknbSBub3Qgc3VyZSB0aGF0 IHRoZSBjb21wYXJpc29uIGlzIGJlc3QgcGxhY2VkIGluIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlv bi4NCj4gSSdkIHJhdGhlciBtb3ZlIGl0IGxhdGVyIGluIHRoZSBkb2MsIG9yIGluIGFwcGVuZGl4 IGFuZCBoYXZlIHRoZSBpbnRyb2R1Y3Rpb24NCj4gb25seSByZWZlcmVuY2UgaXQuIE9yIGluIGEg ZGlmZmVyZW50IGRyYWZ0Lg0KPiANCj4gLSAzcmQgY29sdW1uDQo+ICIgICBUaGUgdGhpcmQgY29s dW1uIGdpdmVzIGFuIGVzdGltYXRlIG9mIHRoZSBhbW91bnQgb2YgY29tcHV0YXRpb24NCj4gICAg cmVxdWlyZWQgYXQgZWFjaCBub2RlIHRvIHN1cHBvcnQgdGhlIEZSUiBtZXRob2QsIGluIGFkZGl0 aW9uIHRvIHRoZQ0KPiAgICB1c3VhbCBTUEYgY29tcHV0YXRpb24gcm9vdGVkIGF0IHRoZSBjb21w dXRpbmcgbm9kZSBpdHNlbGYuICBUaGlzDQo+ICAgIG1ldHJpYyBvZiBjb21wYXJpc29uIGlzIGlt cG9ydGFudCBmb3IgaW1wbGVtZW50YXRpb25zIHRoYXQgc2VlayB0bw0KPiAgICBxdWlja2x5IHJl Y29tcHV0ZSByZXBhaXIgcGF0aHMiDQo+IA0KPiBvay4gQnV0IGZvciByZWd1bGFyIHJvdXRpbmcs IHRoaXMgdGltZSBpcyB0eXBpY2FsbHkgZHJpdmVuIGJ5IEZJQiB1cGRhdGUgcmF0aGVyDQo+IHRo YW4gY29udHJvbCBwbGFuZSBjb21wdXRhdGlvbi4gR2l2ZW4gdGhhdCAidGhlIE1SVCBMb3dwb2lu dCBhbGdvcml0aG0gaXMNCj4gY29tcHV0YXRpb25hbGx5IGVmZmljaWVudCIsIGl0J3Mgbm90IGNs ZWFyIHRvIG1lIHRoYXQgY29udHJvbCBwbGFuZQ0KPiBjb21wdXRhdGlvbiBpcyB0aGUgcmlnaHQg bWV0cmljIHRvIGV2YWx1YXRlIHRoZSB0aW1lIHRvIGJlIHJlYWR5IGZvciB0aGUgbmV4dA0KPiBm YWlsdXJlLiBFc3BlY2lhbGx5IHNpbmNlIE1SVCByZXF1aXJlcyBhIGxhcmdlciBGSUIgKCozKSBh bmQgaGVuY2Ugd2lsbCBiZQ0KPiBzbG93ZXIgb24gdGhlIG1haW4gZmFjdG9yLg0KPiANCj4gLSBN UlQgdXNlIGEgZGVkaWNhdGVkIGluZnJhc3RydWN0dXJlIChwcm90b2NvbHMgZXh0ZW5zaW9uLCBh bGdvcml0aG0sDQo+IFJJQi9GSUIgZW50cmllcykgZm9yIHRoZSBGUlIgdHJhZmZpYy4gwqcxNC4x IHJlY29tbWVuZHMgdG8gY2hlY2sgdGhhdCB0aGlzDQo+IGluZnJhc3RydWN0dXJlIGlzIHJ1bm5p bmcgY29ycmVjdGx5IHdoaWNoIHJlcHJlc2VudCBhbiBhZGRpdGlvbmFsIG9wZXJhdGlvbmFsDQo+ IHdvcmsgYW5kIHRvb2xpbmcuIE90aGVyIHNvbHV0aW9ucyBlLmcuIExGQSwgVEktTEZBLCBSTEZB IHJlLXVzZXMgdGhlIG5vbWluYWwNCj4gcm91dGluZyBpbmZyYXN0cnVjdHVyZSB3aGljaCBpcyBh bHJlYWR5IG1vbml0b3JlZC4NCj4gLSBUcmFmZmljIGNhcGFjaXR5IG1heSBiZSBhbiBpbnRlcmVz dGluZyBtZXRyaWMgdG8gY29tcGFyZSAoYXMgZGlzY3Vzc2VkIGluDQo+IMKnMTQuMikNCj4gPT09 PT09PT09DQo+IFtDQl0gQXMgeW91IG5vdGVkLCB0aGlzIHRhYmxlIGFuZCB0ZXh0IGhhcyBiZWVu IHJlbW92ZWQsIGJ1dCB0aGUgZmVlZGJhY2sgaXMNCj4gdXNlZnVsIGluIGNhc2UgdGhlIHRleHQg ZW5kcyB1cCBpbiBhbm90aGVyIGRvY3VtZW50IGF0IHNvbWUgcG9pbnQgaW4gdGhlDQo+IGZ1dHVy ZS4NCj4gaHR0cHM6Ly9naXRodWIuY29tL2Nib3dlcnMvZHJhZnQtaWV0Zi1ydGd3Zy1tcnQtZnJy LQ0KPiBhcmNoaXRlY3R1cmUvY29tbWl0Lzc2NTVhY2JkNmYzNTBiNDUwNWFiNjNhOWIyMWU1MzU4 MmI5MTNiMDQNCj4gPT09PT09PT09DQo+IA0KPiAtLS0tDQo+IMKnMTQuMiBUcmFmZmljIENhcGFj aXR5IG9uIEJhY2t1cCBQYXRocw0KPiBIYXZpbmcgbm90IHJlYWQgTVJUIExvdyBQb2ludCBBbGdv LA0KPiAiQWR2ZXJ0aXNpbmcgbGlua3MgYXMgTVJULUluZWxpZ2libGUgaXMgdGhlIG1haW4gdG9v bCBwcm92aWRlZCBieSBNUlQtRlJSDQo+IGZvciBrZWVwaW5nIGJhY2t1cCB0cmFmZmljIG9mZiBv ZiBsb3dlciBiYW5kd2lkdGggbGlua3MgZHVyaW5nIGZhc3QtcmVyb3V0ZQ0KPiBldmVudHMuIg0K PiAiTWFpbiIgb3IgIk9ubHkiPyBJZiBvdGhlcnMgdG9vbHMgYXJlIGVmZmVjdGl2ZSwgaXQgbWF5 IGJlIHVzZWZ1bCB0byBpbmRpY2F0ZQ0KPiB0aGVtLg0KPiBJbiBwYXJ0aWN1bGFyLCBpdCdzIG5v dCBvYnZpb3VzIHdoZXRoZXIgSUdQIGNvc3QgaXMgdGFrZW4gaW50byBhY2NvdW50IGFuZCBtYXkN Cj4gYmUgdXNlZnVsIHRvIGdpdmUgcHJlZmVyZW5jZSB0byBzb21lIGJhY2t1cCBwYXRoLiBJZiBu b3QsIGl0IG1heSBiZSB1c2VmdWwgdG8NCj4gaW5kaWNhdGUgdGhhdCB0aGUgYmFja3VwIHBhdGgg d2lsbCBub3QgKHNpZ25pZmljYW50bHkpIHRha2UgaW50byBhY2NvdW50IHRoZQ0KPiBJR1AgbWV0 cmljcyAoZS5nLiBkZWxheSwgYmFuZHdpZHRoLCBkaXN0YW5jZSwgY29zdCwgb3BlcmF0b3IgcHJl ZmVyZW5jZXMuLi4pDQo+ID09PT09PT09PT0NCj4gW0NCXSBJIG1vZGlmaWVkIHRoZSB0ZXh0IHRv IHJlYWQgYXMgYmVsb3cuDQo+IA0KPiBUaGUgTVJUIExvd3BvaW50IGFsZ29yaXRobSBwcm9kdWNl cyBhIHBhaXIgb2YgZGl2ZXJzZSBwYXRocyB0byBlYWNoDQo+ICAgIGRlc3RpbmF0aW9uLiAgVGhl c2UgcGF0aHMgYXJlIGdlbmVyYXRlZCBieSBmb2xsb3dpbmcgdGhlIGRpcmVjdGVkDQo+ICAgIGxp bmtzIG9uIGEgY29tbW9uIEdBREFHLiAgVGhlIGRlY2lzaW9uIHByb2Nlc3MgZm9yIGNvbnN0cnVj dGluZyB0aGUNCj4gICAgR0FEQUcgaW4gdGhlIE1SVCBMb3dwb2ludCBhbGdvcml0aG0gdGFrZXMg aW50byBhY2NvdW50IGluZGl2aWR1YWwgSUdQDQo+ICAgIGxpbmsgbWV0cmljcy4gIEF0IGFueSBn aXZlbiBub2RlLCBsaW5rcyBhcmUgZXhwbG9yZWQgaW4gb3JkZXIgZnJvbQ0KPiAgICBsb3dlc3Qg SUdQIG1ldHJpYyB0byBoaWdoZXN0IElHUCBtZXRyaWMuICBBZGRpdGlvbmFsbHksIHRoZSBwcm9j ZXNzDQo+ICAgIGZvciBjb25zdHJ1Y3RpbmcgdGhlIE1SVC1SZWQgYW5kIEJsdWUgdHJlZXMgdXNl cyBTUEYgdHJhdmVyc2FscyBvZg0KPiAgICB0aGUgR0FEQUcuICBUaGVyZWZvcmUsIHRoZSBJR1Ag bGluayBtZXRyaWMgdmFsdWVzIGFmZmVjdCB0aGUgY29tcHV0ZWQNCj4gICAgYmFja3VwIHBhdGhz LiAgSG93ZXZlciwgYWRqdXN0aW5nIHRoZSBJR1AgbGluayBtZXRyaWNzIGlzIG5vdCBhDQo+ICAg IGdlbmVyYWxseSBhcHBsaWNhYmxlIHRvb2wgZm9yIG1vZGlmeWluZyB0aGUgTVJUIGJhY2t1cCBw YXRocy4NCj4gICAgQWNoaWV2aW5nIGEgZGVzaXJlZCBzZXQgb2YgTVJUIGJhY2t1cCBwYXRocyBi eSBhZGp1c3RpbmcgSUdQIG1ldHJpY3MNCj4gICAgd2hpbGUgYXQgdGhlIHNhbWUgdGltZSBtYWlu dGFpbmluZyB0aGUgZGVzaXJlZCBmbG93IG9mIHRyYWZmaWMgYWxvbmcNCj4gICAgdGhlIHNob3J0 ZXN0IHBhdGhzIGlzIG5vdCBwb3NzaWJsZSBpbiBnZW5lcmFsLg0KPiANCj4gICAgTVJULUZSUiBh bGxvd3MgYW4gb3BlcmF0b3IgdG8gZXhjbHVkZSBhIGxpbmsgZnJvbSB0aGUgTVJUIElzbGFuZCwg YW5kDQo+ICAgIHRodXMgdGhlIEdBREFHLCBieSBhZHZlcnRpc2luZyBpdCBhcyBNUlQtSW5lbGln aWJsZS4gIFN1Y2ggYSBsaW5rDQo+ICAgIHdpbGwgbm90IGJlIHVzZWQgb24gdGhlIE1SVCBmb3J3 YXJkaW5nIHBhdGggZm9yIGFueSBkZXN0aW5hdGlvbi4NCj4gICAgQWR2ZXJ0aXNpbmcgbGlua3Mg YXMgTVJULUluZWxpZ2libGUgaXMgdGhlIG1haW4gdG9vbCBwcm92aWRlZCBieSBNUlQtDQo+ICAg IEZSUiBmb3Iga2VlcGluZyBiYWNrdXAgdHJhZmZpYyBvZmYgb2YgbG93ZXIgYmFuZHdpZHRoIGxp bmtzIGR1cmluZw0KPiAgICBmYXN0LXJlcm91dGUgZXZlbnRzLg0KPiA9PT09PT09PT09PQ0KPiAt LS0NCj4gIlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc29sdXRpb24gZm9yIElQL0xEUCBmYXN0 LXJlcm91dGUgW1JGQzU3MTRdLg0KPiBNUlQtRlJSIGNyZWF0ZXMgdHdvIGFsdGVybmF0ZSB0cmVl cyBzZXBhcmF0ZSBmcm9tIHRoZSBwcmltYXJ5IG5leHQtaG9wDQo+IGZvcndhcmRpbmcgdXNlZCBk dXJpbmcgc3RhYmxlIG9wZXJhdGlvbi4iDQo+IE9uZSBvZiB0aGUgdHJlZSBtYXkgdXNlIHRoZSBw cmltYXJ5IG5leHQtaG9wIGFuZCBoZW5jZSBpcyBub3QgdGhhdA0KPiBzZXBhcmF0ZS4NCj4gDQo+ ID09PT09PT09DQo+IFtDQl0gIENoYW5nZWQgInNlcGFyYXRlIiB0byAiZGlzdGluY3QiIGFuZCBt b2RpZmllZCB3b3JkaW5nIHRvIGNsYXJpZnkuDQo+IE1vZGlmZWQgdGV4dDoNCj4gDQo+IE1SVC1G UlIgY3JlYXRlcyB0d28gYWx0ZXJuYXRlIGZvcndhcmRpbmcgdHJlZXMgd2hpY2ggYXJlIGRpc3Rp bmN0IGZyb20NCj4gdGhlIHByaW1hcnkgbmV4dC1ob3AgZm9yd2FyZGluZyB1c2VkIGR1cmluZyBz dGFibGUgb3BlcmF0aW9uLg0KPiA9PT09PT09PQ0KPiANCj4gLS0tDQo+ICJbVEktTEZBXSBhaW1z IHRvIHByb3ZpZGUiDQo+IEFsbCBGUlIgc29sdXRpb25zICJwcm92aWRlcyIgd2lsbCBUSS1MRkEg ImFpbXMgdG8gcHJvdmlkZSIgOy0pIEFsdGhvdWdoIFRJLUxGQQ0KPiBpcyBub3QgYSBXRyBkb2N1 bWVudCwgSU1ITyB0aGUgZG9jdW1lbnQgY291bGQgdXNlIHRoZSBzYW1lIGZvcm11bGF0aW9uDQo+ IGZvciBhbGwgRlJSIHNvbHV0aW9ucy4NCj4gDQo+ID09PT09PT0NCj4gW0NCXSBXYXMgaW4gdGhl IG5vdy1kZWxldGVkIGNvbXBhcmlzb24gc2VjdGlvbi4NCj4gPT09PT09PQ0KPiANCj4gLS0tDQo+ IMKnMS4xDQo+ICJBc3ltbWV0cmljIGxpbmsgY29zdHMgYXJlIGFsc28gYSBjb21tb24gYXNwZWN0 IG9mIG5ldHdvcmtzLiAgVGhlcmUNCj4gICAgYXJlIGF0IGxlYXN0IHRocmVlIGNvbW1vbiBjYXVz ZXMgZm9yIHRoZW0uICBGaXJzdCwgYW55IGJyb2FkY2FzdA0KPiAgICBpbnRlcmZhY2UgaXMgcmVw cmVzZW50ZWQgYnkgYSBwc2V1ZG8tbm9kZSBhbmQgaGFzIGFzeW1tZXRyaWMgbGluaw0KPiAgICBj b3N0cyB0byBhbmQgZnJvbSB0aGF0IHBzZXVkby1ub2RlLiAgU2Vjb25kLCB3aGVuIHJvdXRlcnMg Y29tZSB1cCBvcg0KPiAgICBhIGxpbmsgd2l0aCBMRFAgY29tZXMgdXAsIGl0IGlzIHJlY29tbWVu ZGVkIGluIFtSRkM1NDQzXSBhbmQNCj4gICAgW1JGQzY5ODddIHRoYXQgdGhlIGxpbmsgbWV0cmlj IGJlIHJhaXNlZCB0byB0aGUgbWF4aW11bSBjb3N0OyB0aGlzDQo+ICAgIG1heSBub3QgYmUgc3lt bWV0cmljIGFuZCBmb3IgW1JGQzY5ODddIGlzIG5vdCBleHBlY3RlZCB0byBiZS4gIg0KPiANCj4g R2l2ZW4gdGhlIHByZXZpb3VzIEZpZ3VyZSAxLCBJIGFzc3VtZSB0aGF0IHRoZSB0YXJnZXQgb2Yg dGhlIGNvbW1lbnQgaXMgVEktDQo+IExGQSBsaW5rIHByb3RlY3Rpb24gd2l0aCAyIGxhYmVscy4g SW4gdGhpcyBjYXNlLCAyIGNvbW1lbnRzOg0KPiAtIElJTk0sIHdoYXQgaXMgbmVlZGVkIChmb3Ig dGhlIHByb29mKSBpcyBzeW1tZXRyaWMgY29zdCBiZXR3ZWVuDQo+IF9mb3J3YXJkaW5nXyBub2Rl cy4gUHNldWRvLW5vZGUgd291bGQgbm90IGNvdW50L2JlIGFuIGlzc3VlLg0KPiAtIFRJLUxGQSBu ZWVkcyBTZWdtZW50IFJvdXRpbmcgaW4gd2hpY2ggY2FzZSBMRFAgd291bGQgbm90IGJlIHVzZWQu DQo+IEhlbmNlIGl0IGRvZXMgbm90IHNlZW0gZmFpciB0byBhc3N1bWUgdGhhdCBMRFAtSUdQIHN5 bmMgd291bGQgYmUgcHJlc2VudC4NCj4gDQo+ID09PT09PT0NCj4gW0NCXSBJIGRlbGV0ZWQgdGhp cyBwYXJhZ3JhcGguDQo+IA0KPiA9PT09PT09DQo+IA0KPiAtLS0NCj4gIldoZW4gYSBuZXR3b3Jr IG5lZWRzIHRvIHVzZSBhIG1pY3JvLWxvb3AgcHJldmVudGlvbiBtZWNoYW5pc20NCj4gICAgW1JG QzU3MTVdIHN1Y2ggYXMgT3JkZXJlZCBGSUJbUkZDNjk3Nl0gb3IgTmVhcnNpZGUNCj4gICAgVHVu bmVsaW5nW1JGQzU3MTVdLCB0aGVuIHRoZSB3aG9sZSBJR1AgYXJlYSBuZWVkcyB0byBoYXZlIGFs dGVybmF0ZXMNCj4gICAgYXZhaWxhYmxlIg0KPiANCj4gSSB3b3VsZCBwcm9wb3NlDQo+IA0KPiAi V2hlbiBhIG5ldHdvcmsgdG8gdXNlIE9yZGVyZWQgRklCW1JGQzY5NzZdIG9yIE5lYXJzaWRlDQo+ ICAgIFR1bm5lbGluZ1tSRkM1NzE1XSBhcyBhIG1pY3JvLWxvb3AgcHJldmVudGlvbiBtZWNoYW5p c20NCj4gICAgW1JGQzU3MTVdLCB0aGVuIHRoZSB3aG9sZSBJR1AgYXJlYSBuZWVkcyB0byBoYXZl IGFsdGVybmF0ZXMNCj4gICAgYXZhaWxhYmxlIg0KPiANCj4gTW90aXZhdGlvbjogdGhlIHJlcXVp cmVtZW50IGZvciBGUlIgY29tZXMgZnJvbSB0aGVzZSAyIHNwZWNpZmljIHNvbHV0aW9ucywNCj4g bm90IGZyb20gImEgbWljcm8tbG9vcCBwcmV2ZW50aW9uIG1lY2hhbmlzbSIuIEkgd29uJ3QgYXJn dWUgd2hldGhlciB0aGUNCj4gb3JpZ2luYWwgdGV4dCBpcyBmaW5lIGZyb20gYW4gZW5nbGlzaCBz dGFuZHBvaW50IChhcyBpdCB3ZWxsIGJleW9uZCBteSBza2lsbHMpLA0KPiBidXQgb25lIHJlYWRl ciBjb3VsZCBtaXNpbnRlcnByZXQgaXQuDQo+ID09PT09PT09PT09PT0NCj4gW0NCXSBBZ3JlZWQu ICBDaGFuZ2VzIGluOg0KPiBodHRwczovL2dpdGh1Yi5jb20vY2Jvd2Vycy9kcmFmdC1pZXRmLXJ0 Z3dnLW1ydC1mcnItDQo+IGFyY2hpdGVjdHVyZS9jb21taXQvZDYwMzFiYTZjY2YyMTBjZmMyNGE5 MGM1NWQwOGM4MDc3MzAwMDU0MQ0KPiA9PT09PT09PT09PT09DQo+IC0tLQ0KPiAiQURBRzogICBB bG1vc3QgRGlyZWN0ZWQgQWN5Y2xpYyBHcmFwaCAtIGEgZ3JhcGggdGhhdCwgaWYgYWxsIGxpbmtz IGluY29taW5nDQo+IHRvIHRoZSByb290IHdlcmUgcmVtb3ZlZCwgd291bGQgYmUgYSBEQUcuIg0K PiBJdCdzIG5vdCBjbGVhciB0byBtZSB3aGF0ICJ0aGUgcm9vdCIgaXMuIEl0IHNlZW1zIHRvIHJl ZmVyIHRvICJhIGdyYXBoIiBhbmQgSQ0KPiBjYW4ndCBmaW5kIGhvdyB0aGlzIHJvb3QgaXMgZGV0 ZXJtaW5lZC4gTWF5IGJlIHlvdSBtZWFuIDpzL2dyYXBoL0RBRyAgYnV0DQo+IGV2ZW4gaW4gdGhp cyBjYXNlLCBpdCdzIG5vdCBvYnZpb3VzIHRvIG1lIHRoYXQgdGhlcmUgaXMgYSBzaW5nbGUgInJv b3QiLiAoc29ycnkgaWYNCj4gdGhpcyBpcyBvYnZpb3VzIGZvciBldmVyeW9uZSBlbHNlLiBObyBu ZWVkIHRvIGV4cGxhaW4gaXQgdG8gbWUuIEknbSBqdXN0DQo+IGNoZWNraW5nIHRoYXQgdGhpcyBp cyB3ZWxsIGRlZmluZWQpDQo+ID09PT09PT09PT09PT09DQo+IFtDQl0gR29vZCBjYXRjaC4gIEkg aG9wZSB0aGlzIHZlcnNpb24gaXMgbW9yZSBjbGVhci4NCj4gICAgQURBRzogICBBbG1vc3QgRGly ZWN0ZWQgQWN5Y2xpYyBHcmFwaCAtIGEgZ3JhcGggd2l0aCBvbmUgbm9kZQ0KPiAgICAgICBkZXNp Z25hdGVkIGFzIHRoZSByb290LiAgVGhlIGdyYXBoIGhhcyB0aGUgcHJvcGVydHkgdGhhdCBpZiBh bGwNCj4gICAgICAgbGlua3MgaW5jb21pbmcgdG8gdGhlIHJvb3Qgd2VyZSByZW1vdmVkLCB0aGVu IHJlc3VsdGluZyBncmFwaA0KPiAgICAgICB3b3VsZCBiZSBhIERBRy4NCj4gPT09PT09PT09PT09 PT0NCj4gDQo+IC0tLQ0KPiDCpzYuMS4xLjENCj4gIkhvd2V2ZXIsIGl0DQo+ICAgIHJlZHVjZXMg dGhlIGxhYmVsIHNwYWNlIGZvciBvdGhlciB1c2VzLCBhbmQgaXQgaW5jcmVhc2VzIHRoZSBtZW1v cnkNCj4gICAgbmVlZGVkIHRvIHN0b3JlIHRoZSBsYWJlbHMgYW5kIHRoZSBjb21tdW5pY2F0aW9u IHJlcXVpcmVkIGJ5IExEUCB0bw0KPiAgICBkaXN0cmlidXRlIEZFQy1sYWJlbCBiaW5kaW5ncy4i DQo+IA0KPiBJdCBhbHNvIGluY3JlYXNlIHRoZSB0aW1lIG5lZWRlZCB0byBpbnN0YWxsIHRoZSBG UlIgZW50cmllcyBpbiB0aGUgRklCIGhlbmNlDQo+IHRoZSB0aW1lIG5lZWRlZCBiZWZvcmUgdGhl IG5leHQgZmFpbHVyZSBtYXkgYmUgcHJvdGVjdGVkLg0KPiA9PT09PT09PQ0KPiBbQ0JdICBBZGRl ZCB0aGUgZm9sbG93aW5nIHRleHQuDQo+IA0KPiAgICBJbiBnZW5lcmFsLCB0aGlzIGFwcHJvYWNo IHdpbGwgYWxzbw0KPiAgICBpbmNyZWFzZSB0aGUgdGltZSBuZWVkZWQgdG8gaW5zdGFsbCB0aGUg RlJSIGVudHJpZXMgaW4gdGhlIEZJQiBhbmQNCj4gICAgaGVuY2UgdGhlIHRpbWUgbmVlZGVkIGJl Zm9yZSB0aGUgbmV4dCBmYWlsdXJlIGNhbiBiZSBwcm90ZWN0ZWQuDQo+ID09PT09PT09DQo+IA0K PiAtLS0NCj4gW1JGQzczMDddIChMRFAgTVQpIGlzIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgZm9y IGJvdGggTERQIGFuZCBJUCB0cmFmZmljLg0KPiBJdCBtYXkgZXZlbnR1YWxseSBiZSBzZWVuIGFz IGEgX25vcm1hdGl2ZV8gcmVmZXJlbmNlLg0KPiBbQ0JdICBDaGFuZ2VkIFJGQzczMDcgdG8gbm9y bWF0aXZlLiAgQWxzbyB0b29rIHRoZSBvcHBvcnR1bml0eSB0byBtb3ZlDQo+IFJGQzUyODYgdG8g aW5mb3JtYXRpdmUuDQo+IA0KPiAtLS0NCj4gIkFsbCByb3V0ZXJzIGluIGFuIE1SVCBJc2xhbmQg TVVTVCBzdXBwb3J0IHRoZSBzYW1lIE1SVCBwcm9maWxlLiINCj4gDQo+IG9rLCBidXQgSU1ITyB0 aGlzIGlzIG1vcmUgYSBtYXR0ZXIgb2YgZGVmaW5pdGlvbiB0aGFuIGEgbWF0dGVyIG9mIGJlaGF2 aW9yDQo+IHRoYXQgTVVTVCBiZSBlbmZvcmNlZC4gU28gSSB3b3VsZCByYXRoZXIgaGF2ZSBhIGRl ZmluaXRpb24gb2YgYW4gTVJUDQo+IElzbGFuZC4gKGUuZy4gQW4gTVJUIElzbGFuZCBpcyBkZWZp bmVkIGFzIHRoZSBzZXQgb2Ygcm91dGVycyBzdXBwb3J0aW5nIHRoZQ0KPiBzYW1lIE1SVCBwcm9m aWxlLCBpbiB0aGUgc2FtZSBJR1AgYXJlYS9sZXZlbCBhbmQgdGhlIGJpLWRpcmVjdGlvbmFscyBs aW5rcw0KPiBpbnRlcmNvbm5lY3RpbmcgdGhvc2Ugcm91dGVycywiLg0KPiANCj4gPT09PT09PT09 PT09DQo+IFtDQl0gR29vZCBwb2ludC4gSSBtYWRlIHRoZSBmb2xsb3dpbmcgY2hhbmdlcw0KPiAN Cj4gICAgQXQgYSBoaWdoIGxldmVsLCBhbiBNUlQgSXNsYW5kIGlzIGRlZmluZWQgYXMgdGhlIHNl dCBvZiByb3V0ZXJzDQo+ICAgIHN1cHBvcnRpbmcgdGhlIHNhbWUgTVJUIHByb2ZpbGUsIGluIHRo ZSBzYW1lIElHUCBhcmVhL2xldmVsIGFuZCB0aGUNCj4gICAgYmktZGlyZWN0aW9uYWwgbGlua3Mg aW50ZXJjb25uZWN0aW5nIHRob3NlIHJvdXRlcnMuICBNb3JlIGRldGFpbGVkDQo+ICAgIGRlc2Ny aXB0aW9ucyBvZiB0aGVzZSBjcml0ZXJpYSBhcmUgZ2l2ZW4gYmVsb3cuDQo+IA0KPiA3LjEuICBJ R1AgQXJlYSBvciBMZXZlbA0KPiANCj4gICAgQWxsIGxpbmtzIGluIGFuIE1SVCBJc2xhbmQgYXJl IGJpZGlyZWN0aW9uYWwgYW5kIGJlbG9uZyB0byB0aGUgc2FtZQ0KPiAgICBJR1AgYXJlYSBvciBs ZXZlbC4gIC4uLi4uLg0KPiANCj4gNy4yLiAgU3VwcG9ydCBmb3IgYSBzcGVjaWZpYyBNUlQgcHJv ZmlsZQ0KPiANCj4gICAgQWxsIHJvdXRlcnMgaW4gYW4gTVJUIElzbGFuZCBzdXBwb3J0IHRoZSBz YW1lIE1SVCBwcm9maWxlLiAgLi4uLi4uLg0KPiA9PT09PT09PT09PT0NCj4gDQo+IC0tLQ0KPiDC pyA3LjIgIkEgZ2l2ZW4gcm91dGVyIGNhbiBzdXBwb3J0IG11bHRpcGxlIE1SVCBwcm9maWxlcyBh bmQgcGFydGljaXBhdGUgaW4NCj4gbXVsdGlwbGUgTVJUIElzbGFuZHMuIiBbLi4uXSAiTm90ZSB0 aGF0IGEgcm91dGVyIG1heSBhZHZlcnRpc2Ugc3VwcG9ydCBmb3INCj4gbXVsdGlwbGUgZGlmZmVy ZW50IE1SVCBwcm9maWxlcy4iDQo+IA0KPiBJTUhPIHRoZSBzZWNvbmQgc2VudGVuY2UgaXMgcmVk dW5kYW50IGFuZCBjb3VsZCBiZSByZW1vdmVkLg0KPiA9PT09PQ0KPiBbQ0JdIEFncmVlZC4NCj4g PT09PT0NCj4gLS0tDQo+IMKnOC4zICJ0aGUgbW9zdCBwcmVmZXJyZWQgR0FEQUcgUm9vdCBTZWxl Y3Rpb24gUHJpb3JpdHkNCj4gICAgICAgYWR2ZXJ0aXNlZCAoY29ycmVzcG9uZGluZyB0byB0aGUg bG93ZXN0IG51bWVyaWNhbCB2YWx1ZSBvZiBHQURBRw0KPiAgICAgICBSb290IFNlbGVjdGlvbiBQ cmlvcml0eSkiDQo+IA0KPiBEbyB5b3UgbWVhbiB0aGF0IHRoZSBfbW9zdCBwcmVmZXJyZWRfIGlz IHRoZSBub2RlIGFkdmVydGlzaW5nIHRoZSBfbG93ZXN0DQo+IHByaW9yaXR5Xz8gVGhpcyBkb2Vz IG5vdCBzZWVtIGludHVpdGl2ZSB0byBtZS4gSWYgc28sIElNSE8gdGhpcyBzaG91bGQgYmUNCj4g c3BlY2lmaWVkIGNsZWFybHkgc29tZXdoZXJlLCBub3QganVzdCBiZXR3ZWVuIGJyYWNrZXRzLglC dXQgSSB3b3VsZA0KPiByYXRoZXIgZmF2b3JpbmcgYSBpbnR1aXRpdmUgYmVoYXZpb3IgKGUuZy4g aWYgbG93ZXN0IG51bWVyaWNhbCB2YWx1ZSBpcw0KPiBwcmVmZXJlZCwgdXNlIHRoZSB3b3JkICJD b3N0IiBvciAiTWV0cmljIiByYXRoZXIgdGhhbiAiUHJpb3JpdHkiLiBJZiAiUHJpb3JpdHkiDQo+ IGlzIGtlcHQsIHByZWZlciB0aGUgaGlnaGVzdCB2YWx1ZS4NCj4gDQo+ID09PT09PT09PT09PT0N Cj4gW0NCXSAgSSBhZ3JlZSB0aGF0IHRoaXMgaXMgY291bnRlci1pbnR1aXRpdmUuICAgSSBsb29r ZWQgaW50byBjaGFuZ2luZyB0aGlzIGENCj4gd2hpbGUgYmFjaywgYnV0IEkgc3RvcHBlZCB3aGVu IEkgZm91bmQgb3RoZXIgZXhhbXBsZXMgb2YgbG93ZXIgbnVtZXJpY2FsDQo+IHByaW9yaXR5IHZh bHVlcyBiZWluZyB1c2VkIHRvIGluZGljYXRlIGhpZ2hlciBwcmVmZXJlbmNlLiBSRkMgMzIwOSAo UlNWUC1URSkNCj4gdXNlcyB0aGlzIGNvbnZlbnRpb24gZm9yIHNldHVwIHByaW9yaXR5IGZvciBS U1ZQIExTUHMuIDgwMi4xRCAoc3Bhbm5pbmcgdHJlZSkNCj4gdXNlcyBpdCBmb3IgYnJpZGdlIHBy aW9yaXR5Lg0KDQpbQnJ1bm9dICBBaC4uLg0KDQo+ICAgSSB0aGluayB0aGF0IGNoYW5naW5nIHRo ZSBhY3R1YWwgb3JkZXJpbmcgaW4gdGhlDQo+IGFsZ29yaXRobSBhdCB0aGlzIHBvaW50IGluIG5v dCBhIGdvb2QgaWRlYSBzaW5jZSBpdCB3aWxsIGNyZWF0ZSBjb25mdXNpb24uIA0KDQpbQnJ1bm9d ICsxDQoNCj4gSSBhbQ0KPiBub3Qgb3Bwb3NlZCB0byBjaGFuZ2luZyB0aGUgbmFtZSwgYnV0IEkg d291bGQgYWxzbyBuZWVkIHRvIHByb3BhZ2F0ZSB0aGF0DQo+IGNoYW5nZSBpbnRvIHRoZSBhbGdv cml0aG0gZHJhZnQgdGV4dCwgcHNldWRvLWNvZGUsIGFuZCBQeXRob24NCj4gaW1wbGVtZW50YXRp b24sIHNvIGlmIHdlIGNoYW5nZSB0aGUgbmFtZSwgSSBvbmx5IHdhbnQgZG8gaXQgb25jZS4NCg0K W0JydW5vXSBOb3RlIHRoYXQgSSdtIG5vdCBhc2tpbmcgZm9yIHRoZSBuYW1lIHRvIGJlIGNoYW5n ZWQuIEkganVzdCByYWlzZWQgdGhlIGNvbW1lbnQuDQoNCiA+IFNvbWVob3cgImNvc3QiIGFuZCAi bWV0cmljIiBkb27igJl0IHNlZW0gbGlrZSBnb29kIG9wdGlvbnMgYmVjYXVzZSB0aGVyZSBpcw0K PiBhbHJlYWR5IHRoZSBJR1AgY29zdCBvciBtZXRyaWMgaW4gdGhpcyBwcm9ibGVtIGRvbWFpbi4g QWxzbyBjb3N0cyBhbmQNCj4gbWV0cmljcyBhcmUgdHlwaWNhbGx5IGN1bXVsYXRpdmUsIHdoZXJl YXMgdGhpcyBpcyBub3QuICBNeSBwcmVmZXJlbmNlIGF0IHRoaXMNCj4gcG9pbnQgd291bGQgYmUg Zm9yIHNvbWV0aGluZyBuZXV0cmFsIGxpa2UgIkdBREFHIFJvb3QgU2VsZWN0aW9uIE51bWJlciIN Cj4gb3IgIkdBREFHIFJvb3QgU2VsZWN0aW9uIFZhbHVlIiBzbyB0aGF0IHRoZSB1c2VyIGlzIG5v dCBtaXNsZWQgaW50byBtYWtpbmcNCj4gYXNzdW1wdGlvbnMgYWJvdXQgaG93IHRoZSB2YWx1ZSBp cyB1c2VkLiAgQW5vdGhlciBvcHRpb24gd291bGQgYmUgIkdBREFHDQo+IFJvb3QgU2VsZWN0aW9u IFBlbmFsdHkiLg0KDQpbQnJ1bm9dIElmIHlvdSBmZWVsIHRoYXQgdGhpcyBpcyB0b28gbGF0ZSB0 byBjaGFuZ2UgdGhlIG5hbWUsIHBsZWFzZSBkb24ndC4NClJlZ2FyZGluZyBwb3NzaWJsZSBjaG9p Y2Ugb2YgbmFtZSwgSSBkb24ndCByZWFsbHkgaGF2ZSBhbiBvcGluaW9uLiBJIHdvdWxkIHRydXN0 IHlvdSBtb3JlIHRoYW4gbWUgZm9yIHRoZSBjaG9pY2Ugb2YgdGVybS4gTm9yIHRvIG1lbnRpb24g RW5nbGlzaCB0ZXJtLg0KKEkgd291bGQgZmVlbCB0aGF0ICJQZW5hbHR5IiBjb3VsZCBhbHNvIGJl IHVuZGVyc3Rvb2QgYXMgY3VtdWxhdGl2ZS4gZS5nLiBpbiB0aGUgY29udGV4dCBvZiBCR1Agcm91 dGUgRmxhcCBkYW1wZW5pbmcgUkZDMjQzOSkNCg0KIA0KPiBGb3IgdGhlIG1vbWVudCwgSSd2ZSB0 cmllZCB0byBhZGRyZXNzIHBvdGVudGlhbCBjb25mdXNpb24gd2hpbGUgbGVhdmluZyB0aGUNCj4g bmFtZSB0aGUgc2FtZSB3aXRoIHRoZSB0ZXh0IGJlbG93LCBidXQgd291bGQgYXBwcmVjaWF0ZSBm ZWVkYmFjayBvbiB0aGUNCj4gYWJvdmUgc3VnZ2VzdGlvbiBhcyB3ZWxsLg0KPiANCj4gICAgR0FE QUcgUm9vdCBTZWxlY3Rpb24gUG9saWN5OiAgIEFtb25nIHRoZSByb3V0ZXJzIGluIHRoZSBNUlQg SXNsYW5kDQo+ICAgICAgIHdpdGggdGhlIGxvd2VzdCBudW1lcmljYWwgdmFsdWUgYWR2ZXJ0aXNl ZCBmb3IgR0FEQUcgUm9vdA0KPiAgICAgICBTZWxlY3Rpb24gUHJpb3JpdHksIGFuIGltcGxlbWVu dGF0aW9uIE1VU1QgcGljayB0aGUgcm91dGVyIHdpdGgNCj4gICAgICAgdGhlIGhpZ2hlc3QgUm91 dGVyIElEIHRvIGJlIHRoZSBHQURBRyByb290LiAgTm90ZSB0aGF0IGEgbG93ZXINCj4gICAgICAg bnVtZXJpY2FsIHZhbHVlIGZvciBHQURBRyBSb290IFNlbGVjdGlvbiBQcmlvcml0eSBpbmRpY2F0 ZXMgYQ0KPiAgICAgICBoaWdoZXIgcHJlZmVyZW5jZSBmb3Igc2VsZWN0aW9uLg0KDQpbQnJ1bm9d IExvb2tzIGdvb2QgdG8gbWUuDQpUaGlzIGRlZmluaXRlbHkgYWRkcmVzc2VzIG15IGNvbW1lbnQu IFRoYW5rcw0KDQotLSBCcnVubw0KDQo+ID09PT09PT09PT09PT0NCj4gLS0NCj4gwqc2LjEuMS40 DQo+ICJJZiBhIHJvdXRlciBzdXBwb3J0cyBhIHByb2ZpbGUgdGhhdCBpbmNsdWRlcyB0aGUgTVJU IExEUCBMYWJlbCBvcHRpb24NCj4gICAgZm9yIE1SVCB0cmFuc2l0IGZvcndhcmRpbmcgbWVjaGFu aXNtLCB0aGVuIGl0IE1VU1Qgc3VwcG9ydCBvcHRpb24gMUEsDQo+ICAgIHdoaWNoIGVuY29kZXMg dG9wb2xvZ3ktc2NvcGVkIEZFQ3MgdXNpbmcgYSBzaW5nbGUgbGFiZWwuIg0KPiANCj4gb2suIEJ1 dCBpbiB0aGlzIGNvbmRpdGlvbiwgSSdtIG5vdCBzdXJlIHRvIHNlZSBhIHJlYXNvbiB3aHkgYW55 b25lIHdvdWxkDQo+IGltcGxlbWVudCBvcHRpb24gMUIgaW4gYWRkaXRpb24uIEluIHdoaWNoIGNh c2UsIGl0IG1heSBoYXZlIHNpbXBsaWZpZWQgdGhlDQo+IHNwZWMgdG8ganVzdCBtb3ZlIG9wdGlv biAxQiBpbiBhcHBlbmRpeCBhbmQgaGVuY2UgcmVtb3ZlIE1SVCBMRFAgbGFiZWwNCj4gb3B0aW9u cy4NCj4gPT09PT09PQ0KPiBbQ0JdICBJIG1vZGlmaWVkIHRoZSBleGlzdGluZyB0ZXh0IHRvIGNs YXJpZnkgdGhlIHJlYXNvbmluZy4gIFRoZSBtYWluIGNoYW5nZXMNCj4gYW5kIGFkZGVkIHRleHQg YXJlIGNvcGllZCBiZWxvdywgYnV0IHNlZSB0aGlzIGdpdGh1YiBkaWZmIGZvciB0aGUgY29tcGxl dGUNCj4gc2V0IG9mIGNoYW5nZXMuDQo+IA0KPiBodHRwczovL2dpdGh1Yi5jb20vY2Jvd2Vycy9k cmFmdC1pZXRmLXJ0Z3dnLW1ydC1mcnItDQo+IGFyY2hpdGVjdHVyZS9jb21taXQvMGY3ZGUyM2I1 MGFhZTA1NGRhYTE3YWU2MmE0MGU1MzY2YzY2OWNhZg0KPiANCj4gDQo+IDYuMS4xLjMuICBDb21w YXRpYmlsaXR5IG9mIE1SVCBMRFAgTGFiZWwgT3B0aW9ucyAxQSBhbmQgMUINCj4gDQo+ICAgIE1S VCB0cmFuc2l0IGZvcndhcmRpbmcgYmFzZWQgb24gTVJUIExEUCBMYWJlbCBvcHRpb25zIDFBIGFu ZCAxQiBjYW4NCj4gICAgY29leGlzdCBpbiB0aGUgc2FtZSBuZXR3b3JrLCB3aXRoIGEgcGFja2V0 IGJlaW5nIGZvcndhcmRlZCBhbG9uZyBhDQo+ICAgIHNpbmdsZSBNUlQgcGF0aCB1c2luZyB0aGUg c2luZ2xlIGxhYmVsIG9mIG9wdGlvbiAxQSBmb3Igc29tZSBob3BzIGFuZA0KPiAgICB0aGUgdHdv IGxhYmVsIHN0YWNrIG9mIG9wdGlvbiAxQiBmb3Igb3RoZXIgaG9wcy4gIEhvd2V2ZXIsIHRvDQo+ ICAgIHNpbXBsaWZ5IHRoZSBwcm9jZXNzIG9mIE1SVCBJc2xhbmQgZm9ybWF0aW9uIHdlIHJlcXVp cmUgdGhhdCBhbGwNCj4gICAgcm91dGVycyBpbiB0aGUgTVJUIElzbGFuZCBzdXBwb3J0IGF0IGxl YXN0IG9uZSBjb21tb24gZm9yd2FyZGluZw0KPiAgICBtZWNoYW5pc20uICBBcyBhbiBleGFtcGxl LCB0aGUgRGVmYXVsdCBNUlQgUHJvZmlsZSByZXF1aXJlcyBzdXBwb3J0DQo+ICAgIGZvciB0aGUg TVJUIExEUCBMYWJlbCBPcHRpb24gMUEgZm9yd2FyZGluZyBtZWNoYW5pc20uICBUaGlzIGVuc3Vy ZXMNCj4gICAgdGhhdCB0aGUgcm91dGVycyBpbiBhbiBNUlQgaXNsYW5kIHN1cHBvcnRpbmcgdGhl IERlZmF1bHQgTVJUIFByb2ZpbGUNCj4gICAgd2lsbCBiZSBhYmxlIHRvIGVzdGFibGlzaCBNUlQg Zm9yd2FyZGluZyBwYXRocyBiYXNlZCBvbiBNUlQgTERQIExhYmVsDQo+ICAgIE9wdGlvbiAxQS4g IEhvd2V2ZXIsIGFuIGltcGxlbWVudGF0aW9uIHN1cHBvcnRpbmcgT3B0aW9uIDFBIG1heSBhbHNv DQo+ICAgIHN1cHBvcnQgT3B0aW9uIDFCLiAgSWYgdGhlIHNjYWxpbmcgb3IgcGVyZm9ybWFuY2Ug Y2hhcmFjdGVyaXN0aWNzIGZvcg0KPiAgICB0aGUgdHdvIG9wdGlvbnMgZGlmZmVyIGluIHRoaXMg aW1wbGVtZW50YXRpb24sIHRoZW4gaXQgbWF5IGJlDQo+ICAgIGRlc2lyYWJsZSBmb3IgYSBwYWly IG9mIGFkamFjZW50IHJvdXRlcnMgdG8gdXNlIE9wdGlvbiAxQiBsYWJlbHMNCj4gICAgaW5zdGVh ZCBvZiB0aGUgT3B0aW9uIDFBIGxhYmVscy4gIElmIHRob3NlIHJvdXRlcnMgc3VjY2Vzc2Z1bGx5 DQo+ICAgIG5lZ290aWF0ZSB0aGUgdXNlIG9mIE9wdGlvbiAxQiBsYWJlbHMsIHRoZXkgYXJlIGZy ZWUgdG8gdXNlIHRoZW0uDQo+ICAgIFRoaXMgY2FuIG9jY3VyIHdpdGhvdXQgYW55IG9mIHRoZSBv dGhlciByb3V0ZXJzIGluIHRoZSBNUlQgSXNsYW5kDQo+ICAgIGJlaW5nIG1hZGUgYXdhcmUgb2Yg aXQuDQo+IA0KPiAgICBOb3RlIHRoYXQgdGhpcyBkb2N1bWVudCBvbmx5IGRlZmluZXMgdGhlIERl ZmF1bHQgTVJUIFByb2ZpbGUgd2hpY2gNCj4gICAgcmVxdWlyZXMgc3VwcG9ydCBmb3IgdGhlIE1S VCBMRFAgTGFiZWwgT3B0aW9uIDFBIGZvcndhcmRpbmcNCj4gICAgbWVjaGFuaXNtLg0KPiANCj4g Ni4xLjEuNC4gIFJlcXVpcmVkIHN1cHBvcnQgZm9yIE1SVCBMRFAgTGFiZWwgb3B0aW9ucw0KPiAN Cj4gICAgSWYgYSByb3V0ZXIgc3VwcG9ydHMgYSBwcm9maWxlIHRoYXQgaW5jbHVkZXMgdGhlIE1S VCBMRFAgTGFiZWwgT3B0aW9uDQo+ICAgIDFBIGZvciB0aGUgTVJUIHRyYW5zaXQgZm9yd2FyZGlu ZyBtZWNoYW5pc20sIHRoZW4gaXQgTVVTVCBzdXBwb3J0DQo+ICAgIG9wdGlvbiAxQSwgd2hpY2gg ZW5jb2RlcyB0b3BvbG9neS1zY29wZWQgRkVDcyB1c2luZyBhIHNpbmdsZSBsYWJlbC4NCj4gICAg VGhlIHJvdXRlciBNQVkgYWxzbyBzdXBwb3J0IG9wdGlvbiAxQi4NCj4gDQo+ICAgIElmIGEgcm91 dGVyIHN1cHBvcnRzIGEgcHJvZmlsZSB0aGF0IGluY2x1ZGVzIHRoZSBNUlQgTERQIExhYmVsIE9w dGlvbg0KPiAgICAxQiBmb3IgdGhlIE1SVCB0cmFuc2l0IGZvcndhcmRpbmcgbWVjaGFuaXNtLCB0 aGVuIGl0IE1VU1Qgc3VwcG9ydA0KPiAgICBvcHRpb24gMUIsIHdoaWNoIGVuY29kZXMgdGhlIHRv cG9sb2d5IGFuZCBGRUMgdXNpbmcgYSB0d28gbGFiZWwNCj4gICAgc3RhY2suICBUaGUgcm91dGVy IE1BWSBhbHNvIHN1cHBvcnQgb3B0aW9uIDFBLg0KPiANCj4gPT09PT09PT09PT09PT09PT09PT09 PQ0KPiAtLQ0KPiDCpzEwDQo+ICAiU2Vjb25kLCB0aGlzIGFsbG93cyBmYWlsdXJlcyB0aGF0IG1p Z2h0IGFwcGVhciBpbiBtdWx0aXBsZSBhcmVhcw0KPiAgICAoZS5nLiAgQUJSL0xCUiBmYWlsdXJl cykgdG8gYmUgc2VwYXJhdGVseSBpZGVudGlmaWVkIGFuZCByZXBhaXJlZA0KPiAgICBhcm91bmQu ICBUaGlyZCwgdGhlIHBhY2tldCBjYW4gYmUgZmFzdC1yZXJvdXRlZCBhZ2FpbiwgaWYgbmVjZXNz YXJ5LA0KPiAgICBkdWUgdG8gYSBmYWlsdXJlIGluIGEgZGlmZmVyZW50IGFyZWEuIg0KPiANCj4g SXQncyBub3Qgb2J2aW91cyB0byBtZSB3aHkgdGhlIHNlY29uZCBhbmQgdGhpcmQgcmVhc29ucyBh cmUgcmVhbGx5IGRpZmZlcmVudC4NCj4gPT09PT09PT09PQ0KPiBbQ0JdICBSZXdyb3RlIHRoZSBm b2xsb3dpbmcgdGV4dCB0byBjbGFyaWZ5Lg0KPiANCj4gICAgU2Vjb25kLCB0aGlzIGFsbG93cyBh IHNpbmdsZSByb3V0ZXIgZmFpbHVyZSB0aGF0IG1hbmlmZXN0cyBpdHNlbGYgaW4NCj4gICAgbXVs dGlwbGUgYXJlYXMgKGFzIHdvdWxkIGJlIHRoZSBjYXNlIHdpdGggYW4gQUJSL0xCUiBmYWlsdXJl KSB0byBiZQ0KPiAgICBzZXBhcmF0ZWx5IGlkZW50aWZpZWQgYW5kIHJlcGFpcmVkIGFyb3VuZC4g IFRoaXJkLCB0aGUgcGFja2V0IGNhbiBiZQ0KPiAgICBmYXN0LXJlcm91dGVkIGFnYWluLCBpZiBu ZWNlc3NhcnksIGR1ZSB0byBhIHNlY29uZCBkaXN0aW5jdCBmYWlsdXJlDQo+ICAgIGluIGEgZGlm ZmVyZW50IGFyZWEuDQo+ID09PT09PT09PT09DQo+IA0KPiAtLS0NCj4gwqcxMA0KPiAiICAgQW4g QUJSL0xCUiB0aGF0IHJlY2VpdmVzIGEgcGFja2V0IG9uIE1SVC1SZWQgb3IgTVJULUJsdWUgdG93 YXJkcw0KPiAgICBkZXN0aW5hdGlvbiBaIHNob3VsZCBjb250aW51ZSB0byBmb3J3YXJkIHRoZSBw YWNrZXQgYWxvbmcgTVJULVJlZCBvcg0KPiAgICBNUlQtQmx1ZSBvbmx5IGlmIHRoZSBiZXN0IHJv dXRlIHRvIFogaXMgaW4gdGhlIHNhbWUgYXJlYSBhcyB0aGUNCj4gICAgaW50ZXJmYWNlIHRoYXQg dGhlIHBhY2tldCB3YXMgcmVjZWl2ZWQgb24uDQo+IA0KPiBUaGlzIHNlZW1zIGEgYml0IE9TUEYg c3BlY2lmaWMuIFdoYXQgYWJvdXQgSVMtSVM/IEluIHBhcnRpY3VsYXIgd2hlbiBzb21lDQo+IHJv dXRlcnMgbWF5IGJlIGluIGJvdGggbGV2ZWxzLg0KPiANCj4gSWRlbSBpbiDCpzEwLjE6DQo+ICIg VG8gdGhvc2Ugcm91dGVycyBpbiB0aGUgc2FtZSBhcmVhIGFzIHRoZSBiZXN0IHJvdXRlIHRvIHRo ZQ0KPiAgICBkZXN0aW5hdGlvbiwgdGhlIEFCUi9MQlIgYWR2ZXJ0aXNlcyB0aGUgZm9sbG93aW5n IEZFQy1sYWJlbCBiaW5kaW5nczoiDQo+IA0KPiBIb3cgZG8gdGhpcyBhcHBseSB0byBJUy1JUyBM QlI/DQo+IA0KPiA9PT09PT09PT09DQo+IFtDQl0NCj4gSSBjcmVhdGVkIGFuIGFwcGVuZGl4IHRv IGV4cGxpY2l0bHkgZGVzY3JpYmUgdGhlIElTLUlTIGludGVyLWxldmVsIGZvcndhcmRpbmcNCj4g YmVoYXZpb3IuICBQbGVhc2Ugc2VlIHRoZSBsYXRlc3QgZHJhZnQgZm9yIHRoYXQgYXBwZW5kaXgu DQo+IA0KPiA9PT09PT09PT09DQo+IA0KPiAtLS0NCj4gICJUaGUgdXNlIG9mIHRoZSBSYWluYm93 LUZFQyBieSB0aGUgQUJSIGZvciBub24tYmVzdC1hcmVhIGFkdmVydGlzZW1lbnRzDQo+IGlzIFJF Q09NTUVOREVELiINCj4gDQo+ICBJIGRvbid0IHNlZSB0aGUgYmFzaXMgZm9yIHRoaXMgcmVjb21t ZW5kYXRpb24uIFRoaXMgY2hvaWNlIHNlZW1zIGRyaXZlbiBieQ0KPiBzcGVjaWZpYyBpbXBsZW1l bnRhdGlvbnMuIE90aGVyIGltcGxlbWVudGF0aW9ucyBtYXkgaGF2ZSBubyByZWFzb24gdG8NCj4g c2VuZCB0aGUgUmFpbmJvdy1GRUMuDQo+ICBJTU8sIGl0IHdvdWxkIGJlIGVub3VnaCB0byBzYXkg ImEgcm91dGVyIHRoYXQgc3VwcG9ydHMgdGhlIExEUCBMYWJlbCBNUlQNCj4gRm9yd2FyZGluZyBN ZWNoYW5pc20gTVVTVCBiZSBhYmxlIHRvIHJlY2VpdmUgYW5kIGNvcnJlY3RseSBpbnRlcnByZXQg dGhlDQo+IFJhaW5ib3ctRkVDLiIgd2hpY2ggaXMgYWxyZWFkeSBzYWlkLiBIZW5jZSBJIHdvdWxk IHByb3Bvc2U6DQo+IA0KPiAgT0xEOg0KPiAgICAgVGhlIHVzZSBvZiB0aGUgUmFpbmJvdy1GRUMg YnkgdGhlIEFCUiBmb3Igbm9uLWJlc3QtYXJlYQ0KPiAgICBhZHZlcnRpc2VtZW50cyBpcyBSRUNP TU1FTkRFRC4gIEFuIEFCUiBNQVkgYWR2ZXJ0aXNlIHRoZSBsYWJlbCBmb3INCj4gICAgdGhlIGRl ZmF1bHQgdG9wb2xvZ3kgaW4gc2VwYXJhdGUgTVJULUJsdWUgYW5kIE1SVC1SZWQgYWR2ZXJ0aXNl bWVudHMuDQo+ICAgIEhvd2V2ZXIsIGEgcm91dGVyDQo+IA0KPiAgTkVXOg0KPiAgICBBbiBBQlIg bWF5IGNob29zZSB0byBlaXRoZXIgYWR2ZXJ0aXNlIHRoZSBSYWluYm93LUZFQyBvciBhZHZlcnRp c2UNCj4gc2VwYXJhdGUgTVJULUJsdWUgYW5kIE1SVC1SZWQgYWR2ZXJ0aXNlbWVudHMuIFRoaXMg aXMgYSBsb2NhbCBjaG9pY2UuDQo+ICAgIEEgcm91dGVyDQo+IA0KPiBJbiB3aGljaCBjYXNlLCBz ZWN0aW9uIDEwLjEgd291bGQgbmVlZCB0byBiZSB1cGRhdGVkIHRvIHJlZmxlY3QgdGhpcy4NCj4g PT09PT09PT0NCj4gW0NCXSBBZ3JlZWQuICBDaGFuZ2VzIGNhcHR1cmVkIGluIHRoaXMgZGlmZi4N Cj4gaHR0cHM6Ly9naXRodWIuY29tL2Nib3dlcnMvZHJhZnQtaWV0Zi1ydGd3Zy1tcnQtZnJyLQ0K PiBhcmNoaXRlY3R1cmUvY29tbWl0L2U4ODRlMjI2ZjcyNTYwNzIxYTJhYjMzODgyMjQ4OTkzOTg2 NmIzYzcNCj4gDQo+ID09PT09PT09DQo+IA0KPiANCj4gLS0tDQo+IMKnMTYgSUFOQQ0KPiBJbiBk cmFmdC1oYWFzLWNvZGUtcG9pbnQtcmVzZXJ2YXRpb24tYmNwLCBKZWZmIHByb3Bvc2VkIHRvIHJl c2VydmUgdGhlIGxhc3QNCj4gY29kZSBwb2ludCAoMjU1KSB0byBhbGxvdyBmb3IgZnV0dXJlIGV4 dGVuc2lvbi4gV2hpbGUgSSdtIG5vdCBzdXJlIHRoaXMgd291bGQNCj4gYmUgbmVlZGVkIGZvciBN UlQgcHJvZmlsZXMsIHRoaXMgd291bGQgYWxzbyBjYXVzZSBubyBoYXJtLg0KPiA9PT09PT09PT0N Cj4gW0NCXSBHb29kIHBvaW50LiAgQWRkcmVzc2VkIGhlcmUuDQo+IA0KPiBodHRwczovL2dpdGh1 Yi5jb20vY2Jvd2Vycy9kcmFmdC1pZXRmLXJ0Z3dnLW1ydC1mcnItDQo+IGFyY2hpdGVjdHVyZS9j b21taXQvMTQ0NTUxNGVhYWRlNzZlN2E4NjA1ZWFhZTE4NzgwZTY5ZTEyN2VhZA0KPiANCj4gPT09 PT09PT09DQo+IA0KPiANCj4gTml0czoNCj4gLSBMRkEgaW1wb3NlcyBubyBhZGRpdGlvbmFsIGxh YmVscyBpbXBvc2VkIHRvbyBtYW55ICJpbXBvc2UiPw0KPiAtIDpzL0lTSVMvSVMtSVMNCj4gLSA6 cy9pbXBsbWVudGF0aW9ucy9pbXBsZW1lbnRhdGlvbnMNCj4gDQo+ID09PT09PT09PT09PT09DQo+ IFtDQl0gQWdyZWVkLg0KPiANCj4gPT09PT09PT09PT09PT0NCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IA0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMNCj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcw0KPiBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwN Cj4gdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4NCj4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUNCj4gdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLg0KPiANCj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCj4gaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLA0K PiB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+IElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlDQo+IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiBBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbg0KPiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4N Cj4gDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Fri Feb 12 07:42:16 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C9E1A039C; Fri, 12 Feb 2016 06:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Ai0LpozeuqSB; Fri, 12 Feb 2016 06:44:13 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA31A0397; Fri, 12 Feb 2016 06:44:13 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 4F0AF1B001A1; Fri, 12 Feb 2016 14:51:40 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Fri, 12 Feb 2016 14:44:12 -0000 Message-ID: <93d97b2202774864de937bf414502d8c.squirrel@erg.abdn.ac.uk> In-Reply-To: References: Date: Fri, 12 Feb 2016 14:44:12 -0000 From: gorry@erg.abdn.ac.uk To: "Andrew G. Malis" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: X-Mailman-Approved-At: Fri, 12 Feb 2016 07:42:14 -0800 Cc: "rtg-dir@ietf.org" , IETF Discussion , rtg-ads@ietf.org, tsvwg@ietf.org, IESG , draft-ietf-tsvwg-circuit-breaker.all@ietf.org Subject: Re: [RTG-DIR] [tsvwg] RtgDir review: draft-ietf-tsvwg-circuit-breaker-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:44:15 -0000 Thank you for sending your comments, I have tried to make changes that incorporate comments from the various area reviews, and expect to shortly release an ID revision (12) that has these improvements. Details of the points addressed are below. Gorry --- Summary: I have some minor concerns about this document that I think should be resolved before publication. Major Issues: No major issues found. Minor Issues: Page 3, first paragraph: There are no citations to the claim that non-congestion-controlled traffic "can form a significant proportion of the total traffic traversing a link". Sure, video is a major part of Internet traffic these days, but much Internet video is dynamically adaptive. One or more citations would be useful. -GF: Understood, but I want to consult on the most suitable reference. Section 4: There are so many issues that they should be numbered, so that they can be referred to individually (from another document, for example). -GF: Numbered. Page 11: In my opinion, the second and third requirements on this page should be "MUST"s rather than "SHOULD"s. -GF: Changed: A Circuit Breaker MUST be constructed so that it does not trigger under light or intermittent congestion. -GF: I did not change: “The default response to a trigger SHOULD disable all traffic that contributed to congestion.” - I query if it really important to dictate the “default” MUST? Page 12, discussion of "In-Band" near the bottom of the page: This paragraph implies that an in-band control method will always provide fate-sharing of the control and regular traffic. It may provide fate-sharing, but that is by no means assured. For example, the network may be using ECMP, or traffic tunnels for data but not control traffic. -GF: Added: “This fate-sharing property is weaker when some or all of the measured traffic is sent using a path that differs from the path taken by the control traffic (e.g., where traffic follows a different path de to use of equal-cost multipath routing, traffic engineering, or tunnels for specific types of traffic). ” Section 5: I'm not sure why Section 5 is a separate section, and not integrated into Section 3 as new subsections, which I think would be an improvement. -GF: I had contemplated this move, and have no preference. In the new revision I moved the text to section 3. Page 13, first paragraph: "presented in figure 2" -> "presented in figures 1 and 2”. -GF: done. Page 19, fourth paragraph: This paragraph states that "IP-based traffic is generally assumed to be congestion-controlled". This is true for TCP-based traffic, but I would not make such an assumption for all IP-based traffic. - GF: Rephrased a little, although the present protocol assumption is that UDP-based traffic needs to provide some form of congestion response, the reality is that this is not always the case. Nits: The abbreviation "CB" is defined early in the document, but is hardly if ever used thereafter, rather "Circuit Breaker" is almost always spelled out. It may be useful to actually use the abbreviation. -GF: done within the normative section, where the term is used a lot. Page 3, first paragraph, fifth line, "connection" -> "connections". -GF: done. Figure 1: Move the vertical line between the "Measure" and "Trigger" boxes one space to the right. -GF: Thanks for spotting, done. Page 10, fourth paragraph: "If necessary, MAY combine" -> "If necessary, a CB MAY combine". -GF: done. Page 11, fifth paragraph: "needs to be" -> "MUST" -GF: done. Page 12, second paragraph: There are two separate references to Section 8. One combined reference should be sufficient. -GF: done. Page 12, second to last paragraph: "in-Band" should have the "i" capitalized. -GF: done. Page 15, last paragraph: "tranport" -> "transport" -GF: done. Page 17, fifth paragraph: "Pseudo Wire" -> "PW" -GF: done. Regards, Andy From nobody Fri Feb 12 08:03:25 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D381A1F1D; Fri, 12 Feb 2016 08:03:23 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 RU701-uXTpcU; Fri, 12 Feb 2016 08:03:22 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 2D5451A2130; Fri, 12 Feb 2016 08:03:22 -0800 (PST) Received: by mail-ob0-x22b.google.com with SMTP id gc3so26245229obb.3; Fri, 12 Feb 2016 08:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yh4IMz+4Bmube+Ng4HEafgBokDG7NyRJqYcbb+aymGI=; b=rKyc1xGVpwteqUNRKXp1z17XeSb8TOO1tg5sbuig9pUuEzHu2yuS0pxCZHXUVYQDA8 I5xAhaH5VOEXGSGVnScydu1Qp0w/TIqrLkQPj/lpMkW70/mV/HshGCBtgwZ7kfTKetT/ b4jClyHGo9p3jj+uGJ+cSaRgvFmzyzWKwIijVHucq9/pTuyQgAvc5i5ZIUapyW41Bnwf Tu1pvls3jdoZCuk6AZPjaB3yjNL2O5q/ZR+jZqcuRW/fWWdN7Lh0Sv3EJqxXRyl/rWnG 8FVaaNv3VSi6wouhfypO/9rU2bMeuBj05oefQpm2J/UJctrdpA7nduAvTQkhD8jX8Dln 5pGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yh4IMz+4Bmube+Ng4HEafgBokDG7NyRJqYcbb+aymGI=; b=cduEIRukwLjxtDZGR82V4hkGbR+TPK4WcOIAZnW47Jwyhlye6D5abU2yUvrMSvmUSy Om0wfNzN3PYAVShFl+ZpCM/+f+RUd9Qa9y8YzWR4Vz7WCxTrGEuBGUfirN0XGikiQvzb Px1kusMNifqhkZ12ZGpyB5U+ZsF0x6iC4B4CJfWA6V+rRvRWlj0pUI49ID+QyObA5C7W jC5lcJxDT+Xtp6zK0Qps7KEz5z8WeNgvU+zyKr/RGwmee8nj4Fgz17Ck+8Lx32bcZ8Ct yXjCujCEY/yJLvFFADdBDtkT87AHuEBltrMHsgx8OcvSkT48yRrQTb9VKYKFFvvBbhUf gGuw== X-Gm-Message-State: AG10YOQG0NQHXjLagY80yIX+gG+mA2bf0Brm8p9gzXAPf4OoVPUisdE7nYMwYZZBnRWLFA/sV0s7DUTCw14oug== X-Received: by 10.182.135.132 with SMTP id ps4mr1959429obb.58.1455293001658; Fri, 12 Feb 2016 08:03:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.196.104 with HTTP; Fri, 12 Feb 2016 08:03:02 -0800 (PST) In-Reply-To: <93d97b2202774864de937bf414502d8c.squirrel@erg.abdn.ac.uk> References: <93d97b2202774864de937bf414502d8c.squirrel@erg.abdn.ac.uk> From: "Andrew G. Malis" Date: Fri, 12 Feb 2016 11:03:02 -0500 Message-ID: To: gorry@erg.abdn.ac.uk Content-Type: multipart/alternative; boundary=089e01177c17687a38052b94ce64 Archived-At: Cc: "rtg-dir@ietf.org" , IETF Discussion , "" , tsvwg@ietf.org, IESG , draft-ietf-tsvwg-circuit-breaker.all@ietf.org Subject: Re: [RTG-DIR] [tsvwg] RtgDir review: draft-ietf-tsvwg-circuit-breaker-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:03:23 -0000 --089e01177c17687a38052b94ce64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gorry, Thank you for sending your comments, I have tried to make changes that > incorporate comments from the various area reviews, and expect to shortly > release an ID revision (12) that has these improvements. Details of the > points addressed are below. > I=E2=80=99m glad to help. I noticed one new typo in your response, which ma= y only be in your email, but may be in the new text as well. > Page 12, discussion of "In-Band" near the bottom of the page: This > paragraph implies that an in-band control method will always provide > fate-sharing of the control and regular traffic. It may provide > fate-sharing, but that is by no means assured. For example, the network m= ay > be using ECMP, or traffic tunnels for data but not control traffic. > -GF: Added: =E2=80=9CThis fate-sharing property is weaker when some or al= l of the > measured traffic is sent using a path that differs from the path taken by > the control traffic (e.g., where traffic follows a different path de to > use of equal-cost multipath routing, traffic engineering, or tunnels for > specific types of traffic). =E2=80=9D > Change =E2=80=9Cpath de to=E2=80=9D to =E2=80=9Cpath due to=E2=80=9D. Cheers, Andy --089e01177c17687a38052b94ce64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gorry,

Thank you for sending y= our comments, I have tried to make changes that
incorporate comments from the various area reviews, and expect to shortly release an ID revision (12) that has these improvements. Details of the
points addressed are below.

I=E2= =80=99m glad to help. I noticed one new typo in your response, which may on= ly be in your email, but may be in the new text as well.
=C2=A0
Page 12, discussion of "In-Band"= ; near the bottom of the page: This
paragraph implies that an in-band control method will always provide
fate-sharing of the control and regular traffic. It may provide
fate-sharing, but that is by no means assured. For example, the network may=
be using ECMP, or traffic tunnels for data but not control traffic.
-GF: Added: =E2=80=9CThis fate-sharing property is weaker when some = or all of the
measured traffic is sent using a path that differs from the path taken by the control traffic (e.g., where traffic follows a different path de to
use of equal-cost multipath routing, traffic engineering, or tunnels for specific types of traffic). =E2=80=9D

Change =E2=80=9Cpath de to=E2=80=9D to =E2=80=9Cpath due to=E2=80=9D.

Cheers,
Andy


<= /div>
--089e01177c17687a38052b94ce64-- From nobody Sun Feb 21 07:16:40 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369921AC3B9; Sun, 21 Feb 2016 07:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.9 X-Spam-Level: X-Spam-Status: No, score=-99.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 nQtZYhdiZkOB; Sun, 21 Feb 2016 07:16:31 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A1E1A19EF; Sun, 21 Feb 2016 07:16:27 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u1LFGLZA012279; Sun, 21 Feb 2016 15:16:21 GMT Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u1LFGKeo012260 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 21 Feb 2016 15:16:20 GMT From: "Adrian Farrel" To: Date: Sun, 21 Feb 2016 15:16:20 -0000 Message-ID: <035501d16cba$d1e22270$75a66750$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFsusBMA+HKJS7XRCyLNR5ewj7ZvA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22144.007 X-TM-AS-Result: No--16.521-10.0-31-10 X-imss-scan-details: No--16.521-10.0-31-10 X-TMASE-MatchedRID: w4ZXfNBmUQJtcr/uuDMv3m7hbmASKcrpQPCWRE0Lo8JV84HrPxCfbDMB KS/l5ik348guxdxp7TO00HTgX5ZI96z75DRX+d9kKWuiyZLRI4AS12tj9Zvd87rfxlRjqBJ35n9 Ju4m2Mp06No0zrfmrme4f2crH8VUD15wawMdYTsUER9Ta+6BEXVHB9PagRph0axNXOJgeVJoNzL dljTPAqOoZNvP/JrWlUGL5XlDynpPz7QpRLPbE+gL09KI3I2Dpx3lyq2zCKQBnnK6mXN72mzzAK 7q1A+IiiIQo5l7Dn3+7Dh6bX2jMDKEQ9o4qffgB3fn7n/ZHGqaRPtwwl97omxjQD3m2MCf7Xtre j45hZxJv7NnqHFdQGWo4X8DALwjD2jlgrd+0SOZNCH0Dib0S0SNGSJ9zRuUNiJ71fA8tGWhKXyl 0HzE/Ot9BiiXFMq3uBAMtgS12Udip+DTe0bMYybdQIb8hCnY+XgaF+qHBQLLYWrp179pohqsFAr L5zddoxdMDEDSgbA8mXhHTnWfES/7yWVfBojhqlTsGW3DmpUve10cftpTCjdqqof+gfD6Rf150I YaeUG3qLc2AXzxLI9/4YGzn++U+iCZh7wWu558XKqR+w9a7UEvE+2pLwGbnRjHvrQ40NxaJ0ygp LlCV0D0qW6tkT+gcPz2YzwCg7k0mcIFfEYO7XJdc7I2df+msT1s1mQSVaBgj/BgXooqgw1aJ7oi 0z34nlj6yUeIBPW52vTmK3CwT42UlOh2o2oTOc2k2agnXN3yGLPZnwUyxvQlbhF7ZTanLUGiigf V1teBuCEgimCyJQ8+qaCwmdYVmusdjwtuTRGaeAiCmPx4NwHJnzNw42kCxxEHRux+uk8jpP8tMO yYmaA== Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-pals-rfc4447bis.all@ietf.org, pals@ietf.org Subject: [RTG-DIR] Routing Directorate review of draft-ietf-pals-rfc4447bis X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2016 15:16:35 -0000 Hello,=20 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 = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir=20 Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them as the draft advances, and = strive to resolve them through discussion or by updating the draft.=20 Thanks, Adrian =3D=3D=3D Document: draft-ietf-pals-rfc4447bis-03.txt=20 Reviewer: Adrian Farrel Review Date: 21 February 2016 IETF LC End Date: Not yet started Intended Status: Internet Standard =3D Summary =3D I have some minor concerns about this document that I think should be = resolved before publication.=20 =3D Comments =3D I'm OK to see 4447 being advanced to full standard, although I'm also a = little surprised that there was energy to do it. The work is largely mechanical. My comments are a mix of minor process = concerns (that your AD should be able to resolve), minor text = clarifications, and nits. It's been a while since I was concerned with LDP, but I have no reason = to doubt the integrity of this document. =3D Major Issues =3D No major issues found.=20 =3D Minor Issues =3D I believe that this document should be marked as obsoleting 4447 and=20 6723. It will result in a new RFC with a new number, so 4447 will no longer be relevant. And, as Section 1 says: a new section (6.3) on=20 control-word renegotiation by label request message has been added, obsoleting RFC 6723. By the way, it is section 7.3 (not 6.3) that you have added! [NB: Q16 of the Shepherd write-up seems a bit garbled on this front. Especially "Will publication of this document change the status of any existing RFCs?" seems to need a much clearer answer!] --- I'm not up to speed on the new process for advancing a specification to Internet-Standard when it has normative references that are not=20 similarly advanced/advancing. I do know that the process changed recently and I am sure that your AD can look it up. --- It might be a reasonable question to ask why some of the (informatively) referenced related PW RFCs (such as encapsulations) are not being advanced at the same time, especially those that are described as "companion documents". --- It seems unnecessary petty-fogging process, but the inclusion of section 7.3 seems to me to defeat the stability requirement for advancement to Internet Standard unless your claim here is that you are advancing 4447 and 6723 together in this single document. That might be fine. --- The Errata that have been deliberately disregarded need to be marked as Rejected. I think the ones that have been actioned could usefully be=20 marked as Verified or have a note added saying "fixed in RFCabcd". As far as I can tell: 3554 was not actioned 938 was done 86 was done 3555 was done 3115 no longer applies 3114 was done 3112 was done 1530 was done --- Because you (incorrectly) said that section 6.3 was new text, I gave it careful review. I think the text is in rather poor state: For example, in 6.3.1... Using the procedures outlined in this section, a simple label withdraw method MAY also be supported as a legacy means of signaling PW status and AC status. ...Since this is *the* specification now, what does "legacy" mean? Indeed, you end 6.3.1 with... The PW status signaling procedures described in this section MUST be fully implemented. ...which kind of implies ... hmm. I think you could rework 6.3.1 to handle this more gracefully and avoid the "clunk" of the 2nd para... Once the PW status negotiation procedures are completed and if they ...where we are surprised to hear about status negotiation. For example: OLD The PEs MUST send Label Mapping Messages to their peers as soon as the PW is configured and administratively enabled, regardless of the attachment circuit state. The PW label should not be withdrawn unless the operator administratively configures the pseudowire down (or the PW configuration is deleted entirely). Using the procedures outlined in this section, a simple label withdraw method MAY also be supported as a legacy means of signaling PW status and AC status. In any case, if the label-to-PW binding is not available the PW MUST be considered in the down state. Once the PW status negotiation procedures are completed and if they result in the use of the label withdraw method for PW status communication, and this method is not supported by one of the PEs, then that PE must send a Label Release Message to its peer with the following error: "Label Withdraw PW Status Method Not Supported" If the label withdraw method for PW status communication is selected for the PW, it will result in the Label Mapping Message being advertised only if the attachment circuit is active. The PW status signaling procedures described in this section MUST be fully implemented. NEW The PEs MUST send Label Mapping Messages to their peers as soon as the PW is configured and administratively enabled, regardless of the attachment circuit state. The PW label should not be withdrawn unless the operator administratively configures the pseudowire down (or the PW configuration is deleted entirely).=20 Section 6.3.2 describes a mechanism for signaling the status of the=20 PW and AC. Additionally, a simple label withdraw method MAY be used=20 to signal the PW status and AC status. In any case, if the label-to- PW binding is not available the PW MUST be considered to be in the=20 down state. The PEs negotiate which PW and AC status signaling mechanism to use by following the procedures in Section 6.3.3. If the PW negotiation procedures are completed and if they result in the use of the simple=20 label withdraw method for PW status communication, and if this method is not supported by one of the PEs then that PE must send a Label Release Message to its peer with the following error: "Label Withdraw PW Status Method Not Supported" If the label withdraw method for PW status communication is selected for the PW, it will result in the Label Mapping Message being advertised only if the AC is active. =20 The PW status signaling procedures described in Section 6.3.2 MUST be fully implemented. END --- Section 6.3.2 achieves ambiguity by stating... The general format of the Notification Message is: ...and then showing the specific case of "PW status". You can fix this by re-ordering and tweaking slightly, as follows. Note that the old text says: Since this notification does not refer to any particular message, the Message Id and Message Type fields are set to 0. ...but I think the Message Type is set to 0x0001 :-) OLD The Status TLV is transported to the remote PW peer via the LDP Notification message. The general format of the Notification Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status (TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWId FEC TLV or Generalized ID FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Grouping ID TLV (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Status TLV status code is set to 0x00000028, "PW status", to indicate that PW status follows. Since this notification does not refer to any particular message, the Message Id and Message Type fields are set to 0. NEW The Status TLV is transported to the remote PW peer via the LDP Notification message as described in [RFC5036]. =20 The Status TLV status code is set to 0x00000028, "PW status", to indicate that PW status follows. The format of the Notification Message for carrying the PW Status is as follows: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status (TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWId FEC TLV or Generalized ID FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Grouping ID TLV (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Since this notification does not refer to any particular message, the Message Id field is set to 0. END --- Section 8 could be tidied a little. The use of "in general" gives the IANA no way to know whether they should or should not update a reference.=20 Are you sure that you want to remove the nice, concise listing of code points that are present in RFC 4447? 8.1, 8.2, and 8.3 all say "new". I suggest deleting that word. And lastly, "IANA needs to..." is not what we say :-) "IANA is requested to..." is nicer. [NB: The Shepherd write-up seems to report all this wrongly at Q17] --- Shouldn't the whole of Section 10 be moved to an interop report somewhere? It's presence within the document seems somewhat temporally unstable. I understand that you want to write it down and record it somewhere, also that you probably developed it in the I-D as a useful=20 place for working text. For advice about how and where to do this you can look at RFC 5657. You seem to have answered the four points from 6410, but may be missing a little corroboration.=20 > The pseudowire technology was first deployed in 2001 and has been > widely deployed by many carriers. [RFC7079] documents the results of > a survey of PW implementations, with specific emphasis on Control > Word usage. [EANTC] documents a public multi-vendor interoperability > test of MPLS and Carrier Ethernet equipment, which included testing > of Ethernet, ATM and TDM pseudowires. 7079 is a slightly related piece of survey work, but the only mention of = LDP (which is the subject of *this* document) is to point out an issue with non-implementation. The EANTC reference really needs something that helps us find the report of the interop event. Possibly this is http://www.eantc.de/fileadmin/eantc/downloads/events/2007-2010/MPLSEWC09/= EANTC-MPLSEWC2009-WhitePaper-v1.0.pdf Looking at that paper, it definitely supports the claim of multiple interoperating implementations of 4447. We lack, however, any statements about "widespread deployment and=20 successful operational experience." > The errata against [RFC4447] are all editorial in nature and have > been addressed in this document. Good (except for those not addressed as above, and except that some of those errata are incorrectly marked as "Technical"). > All features in this specification have been implemented by multiple > vendors. How do we know this? Further, are all the features used? One point of this step in the=20 process is to prune out features that are unnecessary (and so complicate implementation and operation, and cost money). > There is no IPR filed against this document or its predecessor. This may be overly vague (you probably mean "No IPR disclosures have been made to the IETF related to this document, to RFC 4447 or RFC 6723, or to the Internet-Drafts that resulted in RFC 4447 and RFC 6723."). --- =3D Nits =3D In the Abstract, probably... OLD This document has been written to address errata in a previous version of this standard. NEW This document has been written to address errata in a previous version of this specification. END But, actually, I think you are missing the main purpose which is to advance the spec to full standard. On reflection, I think that this paragraph probably served well in the draft as it was being processed, but can be removed now. The equivalent=20 text obviously needs to be in the shepherd write-up. [ditto the paragraph in the introduction] --- Thank you for including Section 1. It's important and helpful. Three tiny points: Second para should probably s/However/Additionally/ The RFC Editor requires that section 1 is the Introduction. A simple solution is to swap sections 1 and 2, or to move the current section 2 to be the new section 1 and the current section 1 to be section 1.1. The text says "A note was added to clarify that the C-bit is part of=20 the FEC." I think you should s/was/has been/ and you could also usefully give a little hint as to where the note was added. = =20 --- Shouldn't you mention the inclusion of text referencing 7358? This is clearly a change to the original text. I wonder, however, whether what really want to do is take that part of 7358 that updated 4447 and simply write it here so that this spec has no need of that reference. Either way, you also need to take care about the stability requirement=20 for advancement. --- In 6.2.2.1 please note that IANA has "PW Interface Parameters TLV" not "Interface Parameters TLV". The is a good chance to make this consistent. --- In 6.2.2.2 and the rest of the document, please note that the IANA has "PW Group ID TLV" not "PW Grouping ID TLV". The is a good chance to make this consistent. --- 6.3.2 has a figure which claims to include a "PWId FEC TLV" or a "Generalized ID FEC TLV". However, 6.1 and 6.2 describe these as "elements" not TLVs and they show up in the Forwarding Equivalence Class (FEC) Type Name Space. I think you can clarify 6.3.2 by explaining that what is included here is "a FEC TLV containing either a PWId FEC element or a Generalized FEC element. Then, just after the figure you have "The PW FEC TLV" but it is just a "FEC TLV" --- In 7.3 you have "re-provisioned". I wonder whether you mean "re-configured". "Provisioning" has a context initial set-up, so re- provisioning suggests (to me?) re-initialization. --- In the first para of 7.3 you have "PW C-bit negotiation procedure" and "Control-Word negotiation procedures". Could you decide on a single name, and on whether it is singular or plural. --- 7.3 OLD -i. If local PE has previously sent a Label Mapping message, it MUST send a Label Withdraw message to remote PE and wait NEW -i. If the local PE has previously sent a Label Mapping message, = it MUST send a Label Withdraw message to the remote PE and wait END --- 7.3 OLD -ii. the local PE MUST send a label release message to the remote NEW -ii. The local PE MUST send a Label Release message to the remote END --- 7.3 s/negotaiation/negotiation/ s/renegotation/renegotiation/ --- 7.3 The above C-bit renegotiation process SHOULD NOT be interrupted until it is completed, or unpredictable results might occur. This is a bit odd. Normally the "or" that follows a "SHOULD" or "SHOULD NOT" explains the conditions under which you might want to vary the=20 "SHOULD".=20 But I'm struggling: interrupted by whom and by doing what? ---=20 Some of the formatting in the references seems to have been hit with a global change of /. /. / You might want to polish. --- The latest version of G.707 is dated January 2007. Is there any reason to not update the reference? --- Have a look at Section 8 of RFC 5036 for an example of a nice way to handle "legacy authors" and credits for past work. In any case, the RFC Editor will require that Section 15 is renamed=20 "Contributors". --- There are two trivial nits from idnits. From nobody Mon Feb 22 04:01:13 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE471A008E; Mon, 22 Feb 2016 04:01:08 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 3Zk9udATFh9F; Mon, 22 Feb 2016 04:01:01 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 9438C1A005B; Mon, 22 Feb 2016 04:01:01 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id x21so53151239oix.2; Mon, 22 Feb 2016 04:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Lgq0etj9IlZwyT9WcshiI5chcEaFtdNKvfhwsRhSqIc=; b=jBQFZ+WIaSI6KVOp8hNVfQYMk1oDD4t2t53ynOgc45OLlmzU6zTylqVsdZCp43ZhGf D4OAeP8tjjd3jdW2o+P9UCqiaPR5dQOu0Bi9Az153qMdHLJ2OdrPAZYVvfB2IAU+9CrW hHgeGBQ5zh1ySe7gncT0DFEraryJSNp4NbSwERUUWNx5lrsuF76xra78qRyj0G1kCzXz XL+0N+rIpKnNpAJT8BjE7OR0urd+53q07lM0wpPTcKHrDhvNtvG6Fur4eerxUNoHX95F /bxqGUC4ZsBMhSFxn1wnDa1+Vlay8XwijiD8avcIsSQ9ga2RqGJKxJcFWK75Lph6sM8b ZAkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Lgq0etj9IlZwyT9WcshiI5chcEaFtdNKvfhwsRhSqIc=; b=IqsRR4eHa7x2w/bX3Vv0e3ftZOAXuB8BAtv6tjTFVzD0aj1sLe5rWUStVMIwAMGOHb OElKolBSyVPWRwfzjSD64SAJon97mZH2h23DrJQYOzxxAzd0C4jTdPap7SJfwi9bJt8S V6JjKpJgdlMOzDLsbxPrp8479hXE9TAfNj6jihEy5h7oAFFRmNzNs0ceXWovuyNTfXs2 Of/a6fD9fYd/vw6Pb5DcflfaGxtxqtPFMO1IyaNS2f+CLkJEXfPlThTHJvzVWHqfiY70 JYXbp+H0wxbK5fvC/BX0H4CPAX+mmF7PWNmvsMckhD9fZ0vOPR199F74RbTcgvZachtN SQ3g== X-Gm-Message-State: AG10YOR9FnsORp4TFzY8ZDvxmfBtyPsKf3Mma4nMOzTblQ9WENkfyJIoBG4/sfdoLpuxRZCxG9c1npL31x/MyQ== X-Received: by 10.202.85.12 with SMTP id j12mr21863894oib.96.1456142460995; Mon, 22 Feb 2016 04:01:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.196.104 with HTTP; Mon, 22 Feb 2016 04:00:41 -0800 (PST) In-Reply-To: <035501d16cba$d1e22270$75a66750$@olddog.co.uk> References: <035501d16cba$d1e22270$75a66750$@olddog.co.uk> From: "Andrew G. Malis" Date: Mon, 22 Feb 2016 07:00:41 -0500 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113d2f8a21505a052c5a96e9 Archived-At: Cc: "" , "rtg-dir@ietf.org" , draft-ietf-pals-rfc4447bis.all@ietf.org, "pals@ietf.org" Subject: Re: [RTG-DIR] Routing Directorate review of draft-ietf-pals-rfc4447bis X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 12:01:08 -0000 --001a113d2f8a21505a052c5a96e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adrian, Thanks for the review! Cheers, Andy On Sun, Feb 21, 2016 at 10:16 AM, Adrian Farrel wrote= : > 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 o= f > the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see =E2=80=8B > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them as the draft advances, and > strive to resolve them through discussion or by updating the draft. > > Thanks, > Adrian > > =3D=3D=3D > > Document: draft-ietf-pals-rfc4447bis-03.txt > Reviewer: Adrian Farrel > Review Date: 21 February 2016 > IETF LC End Date: Not yet started > Intended Status: Internet Standard > > =3D Summary =3D > > I have some minor concerns about this document that I think should be > resolved before publication. > > =3D Comments =3D > > I'm OK to see 4447 being advanced to full standard, although I'm also a > little surprised that there was energy to do it. > > The work is largely mechanical. My comments are a mix of minor process > concerns (that your AD should be able to resolve), minor text > clarifications, and nits. > > It's been a while since I was concerned with LDP, but I have no reason to > doubt the integrity of this document. > > =3D Major Issues =3D > > No major issues found. > > =3D Minor Issues =3D > > I believe that this document should be marked as obsoleting 4447 and > 6723. It will result in a new RFC with a new number, so 4447 will no > longer be relevant. And, as Section 1 says: a new section (6.3) on > control-word renegotiation by label request message has been added, > obsoleting RFC 6723. > > By the way, it is section 7.3 (not 6.3) that you have added! > > [NB: Q16 of the Shepherd write-up seems a bit garbled on this front. > Especially "Will publication of this document change the status of any > existing RFCs?" seems to need a much clearer answer!] > > --- > > I'm not up to speed on the new process for advancing a specification to > Internet-Standard when it has normative references that are not > similarly advanced/advancing. I do know that the process changed > recently and I am sure that your AD can look it up. > > --- > > It might be a reasonable question to ask why some of the > (informatively) referenced related PW RFCs (such as encapsulations) > are not being advanced at the same time, especially those that are > described as "companion documents". > > --- > > It seems unnecessary petty-fogging process, but the inclusion of > section 7.3 seems to me to defeat the stability requirement for > advancement to Internet Standard unless your claim here is that you > are advancing 4447 and 6723 together in this single document. That > might be fine. > > --- > > The Errata that have been deliberately disregarded need to be marked as > Rejected. I think the ones that have been actioned could usefully be > marked as Verified or have a note added saying "fixed in RFCabcd". > > As far as I can tell: > > 3554 was not actioned > 938 was done > 86 was done > 3555 was done > 3115 no longer applies > 3114 was done > 3112 was done > 1530 was done > > --- > > Because you (incorrectly) said that section 6.3 was new text, I gave it > careful review. I think the text is in rather poor state: > > For example, in 6.3.1... > > Using the procedures > outlined in this section, a simple label withdraw method MAY also be > supported as a legacy means of signaling PW status and AC status. > > ...Since this is *the* specification now, what does "legacy" mean? > > Indeed, you end 6.3.1 with... > The PW status > signaling procedures described in this section MUST be fully > implemented. > ...which kind of implies ... hmm. > > I think you could rework 6.3.1 to handle this more gracefully and avoid > the "clunk" of the 2nd para... > > Once the PW status negotiation procedures are completed and if they > > ...where we are surprised to hear about status negotiation. > > For example: > > OLD > The PEs MUST send Label Mapping Messages to their peers as soon as > the PW is configured and administratively enabled, regardless of the > attachment circuit state. The PW label should not be withdrawn > unless the operator administratively configures the pseudowire down > (or the PW configuration is deleted entirely). Using the procedures > outlined in this section, a simple label withdraw method MAY also be > supported as a legacy means of signaling PW status and AC status. In > any case, if the label-to-PW binding is not available the PW MUST be > considered in the down state. > > Once the PW status negotiation procedures are completed and if they > result in the use of the label withdraw method for PW status > communication, and this method is not supported by one of the PEs, > then that PE must send a Label Release Message to its peer with the > following error: > > "Label Withdraw PW Status Method Not Supported" > > If the label withdraw method for PW status communication is selected > for the PW, it will result in the Label Mapping Message being > advertised only if the attachment circuit is active. The PW status > signaling procedures described in this section MUST be fully > implemented. > NEW > The PEs MUST send Label Mapping Messages to their peers as soon as > the PW is configured and administratively enabled, regardless of the > attachment circuit state. The PW label should not be withdrawn > unless the operator administratively configures the pseudowire down > (or the PW configuration is deleted entirely). > > Section 6.3.2 describes a mechanism for signaling the status of the > PW and AC. Additionally, a simple label withdraw method MAY be used > to signal the PW status and AC status. In any case, if the label-to- > PW binding is not available the PW MUST be considered to be in the > down state. > > The PEs negotiate which PW and AC status signaling mechanism to use > by following the procedures in Section 6.3.3. If the PW negotiation > procedures are completed and if they result in the use of the simple > label withdraw method for PW status communication, and if this method > is not supported by one of the PEs then that PE must send a Label > Release Message to its peer with the following error: > > "Label Withdraw PW Status Method Not Supported" > > If the label withdraw method for PW status communication is selected > for the PW, it will result in the Label Mapping Message being > advertised only if the AC is active. > > The PW status signaling procedures described in Section 6.3.2 MUST be > fully implemented. > END > > --- > > Section 6.3.2 achieves ambiguity by stating... > The general format of the Notification Message is: > ...and then showing the specific case of "PW status". > > You can fix this by re-ordering and tweaking slightly, as follows. > > Note that the old text says: > Since this notification does not > refer to any particular message, the Message Id and Message Type > fields are set to 0. > ...but I think the Message Type is set to 0x0001 :-) > > > OLD > The Status TLV is transported to the remote PW peer via the LDP > Notification message. The general format of the Notification Message > is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Notification (0x0001) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status (TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PWId FEC TLV or Generalized ID FEC TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Grouping ID TLV (Optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > The Status TLV status code is set to 0x00000028, "PW status", to > indicate that PW status follows. Since this notification does not > refer to any particular message, the Message Id and Message Type > fields are set to 0. > NEW > The Status TLV is transported to the remote PW peer via the LDP > Notification message as described in [RFC5036]. > > The Status TLV status code is set to 0x00000028, "PW status", to > indicate that PW status follows. The format of the Notification > Message for carrying the PW Status is as follows: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Notification (0x0001) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status (TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PWId FEC TLV or Generalized ID FEC TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Grouping ID TLV (Optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Since this notification does not refer to any particular message, > the Message Id field is set to 0. > END > > --- > > Section 8 could be tidied a little. > > The use of "in general" gives the IANA no way to know whether they > should or should not update a reference. > > Are you sure that you want to remove the nice, concise listing of code > points that are present in RFC 4447? > > 8.1, 8.2, and 8.3 all say "new". I suggest deleting that word. > > And lastly, "IANA needs to..." is not what we say :-) "IANA is requested > to..." is nicer. > > [NB: The Shepherd write-up seems to report all this wrongly at Q17] > > --- > > Shouldn't the whole of Section 10 be moved to an interop report > somewhere? It's presence within the document seems somewhat temporally > unstable. I understand that you want to write it down and record it > somewhere, also that you probably developed it in the I-D as a useful > place for working text. For advice about how and where to do this you > can look at RFC 5657. > > You seem to have answered the four points from 6410, but may be missing > a little corroboration. > > > The pseudowire technology was first deployed in 2001 and has been > > widely deployed by many carriers. [RFC7079] documents the results of > > a survey of PW implementations, with specific emphasis on Control > > Word usage. [EANTC] documents a public multi-vendor interoperability > > test of MPLS and Carrier Ethernet equipment, which included testing > > of Ethernet, ATM and TDM pseudowires. > > 7079 is a slightly related piece of survey work, but the only mention of > LDP (which is the subject of *this* document) is to point out an issue > with non-implementation. > > The EANTC reference really needs something that helps us find the report > of the interop event. Possibly this is > > http://www.eantc.de/fileadmin/eantc/downloads/events/2007-2010/MPLSEWC09/= EANTC-MPLSEWC2009-WhitePaper-v1.0.pdf > Looking at that paper, it definitely supports the claim of multiple > interoperating implementations of 4447. > > We lack, however, any statements about "widespread deployment and > successful operational experience." > > > The errata against [RFC4447] are all editorial in nature and have > > been addressed in this document. > > Good (except for those not addressed as above, and except that some of > those errata are incorrectly marked as "Technical"). > > > All features in this specification have been implemented by multiple > > vendors. > > How do we know this? > Further, are all the features used? One point of this step in the > process is to prune out features that are unnecessary (and so complicate > implementation and operation, and cost money). > > > There is no IPR filed against this document or its predecessor. > > This may be overly vague (you probably mean "No IPR disclosures have > been made to the IETF related to this document, to RFC 4447 or RFC 6723, > or to the Internet-Drafts that resulted in RFC 4447 and RFC 6723."). > > --- > > =3D Nits =3D > > In the Abstract, probably... > > OLD > This document has been written to address errata in a previous > version of this standard. > NEW > This document has been written to address errata in a previous > version of this specification. > END > > But, actually, I think you are missing the main purpose which is to > advance the spec to full standard. > > On reflection, I think that this paragraph probably served well in the > draft as it was being processed, but can be removed now. The equivalent > text obviously needs to be in the shepherd write-up. > > [ditto the paragraph in the introduction] > > --- > > Thank you for including Section 1. It's important and helpful. > > Three tiny points: > > Second para should probably s/However/Additionally/ > > The RFC Editor requires that section 1 is the Introduction. A simple > solution is to swap sections 1 and 2, or to move the current section 2 > to be the new section 1 and the current section 1 to be section 1.1. > > The text says "A note was added to clarify that the C-bit is part of > the FEC." I think you should s/was/has been/ and you could also usefully > give a little hint as to where the note was added. > > --- > > Shouldn't you mention the inclusion of text referencing 7358? This is > clearly a change to the original text. I wonder, however, whether what > really want to do is take that part of 7358 that updated 4447 and simply > write it here so that this spec has no need of that reference. > > Either way, you also need to take care about the stability requirement > for advancement. > > --- > > In 6.2.2.1 > please note that IANA has "PW Interface Parameters TLV" not "Interface > Parameters TLV". > > The is a good chance to make this consistent. > > --- > > In 6.2.2.2 and the rest of the document, please note that the IANA has > "PW Group ID TLV" not "PW Grouping ID TLV". > > The is a good chance to make this consistent. > > --- > > 6.3.2 has a figure which claims to include a "PWId FEC TLV" or a > "Generalized ID FEC TLV". However, 6.1 and 6.2 describe these as > "elements" not TLVs and they show up in the Forwarding Equivalence Class > (FEC) Type Name Space. > > I think you can clarify 6.3.2 by explaining that what is included here > is "a FEC TLV containing either a PWId FEC element or a Generalized FEC > element. > > Then, just after the figure you have "The PW FEC TLV" but it is just a > "FEC TLV" > > --- > > In 7.3 you have "re-provisioned". I wonder whether you mean > "re-configured". "Provisioning" has a context initial set-up, so re- > provisioning suggests (to me?) re-initialization. > > --- > > In the first para of 7.3 you have "PW C-bit negotiation procedure" and > "Control-Word negotiation procedures". > > Could you decide on a single name, and on whether it is singular or > plural. > > --- > > 7.3 > OLD > -i. If local PE has previously sent a Label Mapping message, it > MUST send a Label Withdraw message to remote PE and wait > NEW > -i. If the local PE has previously sent a Label Mapping message, = it > MUST send a Label Withdraw message to the remote PE and wait > END > > --- > > 7.3 > OLD > -ii. the local PE MUST send a label release message to the remote > NEW > -ii. The local PE MUST send a Label Release message to the remote > END > > --- > > 7.3 > s/negotaiation/negotiation/ > s/renegotation/renegotiation/ > > --- > > 7.3 > > The above C-bit renegotiation process SHOULD NOT be interrupted until > it is completed, or unpredictable results might occur. > > This is a bit odd. Normally the "or" that follows a "SHOULD" or "SHOULD > NOT" explains the conditions under which you might want to vary the > "SHOULD". > > But I'm struggling: interrupted by whom and by doing what? > > --- > > Some of the formatting in the references seems to have been hit with a > global change of /. /. / You might want to polish. > > --- > > The latest version of G.707 is dated January 2007. Is there any reason > to not update the reference? > > --- > > Have a look at Section 8 of RFC 5036 for an example of a nice way to > handle "legacy authors" and credits for past work. > > In any case, the RFC Editor will require that Section 15 is renamed > "Contributors". > > --- > > There are two trivial nits from idnits. > > --001a113d2f8a21505a052c5a96e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adrian,

Thanks for the review!

Cheers,
Andy

On Sun, Feb 21, 2016 at 10:16 AM, Adrian = Farrel <adrian@olddog.co.uk> wrote:
Hello,

I have been selected as the Routing Directorate reviewer for this draft. Th= e 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 re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see =E2=80=8Bh= ttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them as the draft advances, and strive= to resolve them through discussion or by updating the draft.

Thanks,
Adrian

=3D=3D=3D

Document: draft-ietf-pals-rfc4447bis-03.txt
Reviewer: Adrian Farrel
Review Date: 21 February 2016
IETF LC End Date: Not yet started
Intended Status: Internet Standard

=3D Summary =3D

I have some minor concerns about this document that I think should be resol= ved before publication.

=3D Comments =3D

I'm OK to see 4447 being advanced to full standard, although I'm al= so a little surprised that there was energy to do it.

The work is largely mechanical. My comments are a mix of minor process conc= erns (that your AD should be able to resolve), minor text clarifications, a= nd nits.

It's been a while since I was concerned with LDP, but I have no reason = to doubt the integrity of this document.

=3D Major Issues =3D

No major issues found.

=3D Minor Issues =3D

I believe that this document should be marked as obsoleting 4447 and
6723. It will result in a new RFC with a new number, so 4447 will no
longer be relevant. And, as Section 1 says: a new section (6.3) on
control-word renegotiation by label request message has been added,
obsoleting RFC 6723.

By the way, it is section 7.3 (not 6.3) that you have added!

[NB: Q16 of the Shepherd write-up seems a bit garbled on this front.
Especially "Will publication of this document change the status of any=
existing RFCs?" seems to need a much clearer answer!]

---

I'm not up to speed on the new process for advancing a specification to=
Internet-Standard when it has normative references that are not
similarly advanced/advancing. I do know that the process changed
recently and I am sure that your AD can look it up.

---

It might be a reasonable question to ask why some of the
(informatively) referenced related PW RFCs (such as encapsulations)
are not being advanced at the same time, especially those that are
described as "companion documents".

---

It seems unnecessary petty-fogging process, but the inclusion of
section 7.3 seems to me to defeat the stability requirement for
advancement to Internet Standard unless your claim here is that you
are advancing 4447 and 6723 together in this single document. That
might be fine.

---

The Errata that have been deliberately disregarded need to be marked as
Rejected. I think the ones that have been actioned could usefully be
marked as Verified or have a note added saying "fixed in RFCabcd"= .

As far as I can tell:

3554 was not actioned
938 was done
86 was done
3555 was done
3115 no longer applies
3114 was done
3112 was done
1530 was done

---

Because you (incorrectly) said that section 6.3 was new text, I gave it
careful review. I think the text is in rather poor state:

For example, in 6.3.1...

=C2=A0 =C2=A0Using the procedures
=C2=A0 =C2=A0outlined in this section, a simple label withdraw method MAY a= lso be
=C2=A0 =C2=A0supported as a legacy means of signaling PW status and AC stat= us.

...Since this is *the* specification now, what does "legacy" mean= ?

Indeed, you end 6.3.1 with...
=C2=A0 =C2=A0The PW status
=C2=A0 =C2=A0signaling procedures described in this section MUST be fully =C2=A0 =C2=A0implemented.
...which kind of implies ... hmm.

I think you could rework 6.3.1 to handle this more gracefully and avoid
the "clunk" of the 2nd para...

=C2=A0 =C2=A0Once the PW status negotiation procedures are completed and if= they

...where we are surprised to hear about status negotiation.

For example:

OLD
=C2=A0 =C2=A0The PEs MUST send Label Mapping Messages to their peers as soo= n as
=C2=A0 =C2=A0the PW is configured and administratively enabled, regardless = of the
=C2=A0 =C2=A0attachment circuit state.=C2=A0 The PW label should not be wit= hdrawn
=C2=A0 =C2=A0unless the operator administratively configures the pseudowire= down
=C2=A0 =C2=A0(or the PW configuration is deleted entirely).=C2=A0 Using the= procedures
=C2=A0 =C2=A0outlined in this section, a simple label withdraw method MAY a= lso be
=C2=A0 =C2=A0supported as a legacy means of signaling PW status and AC stat= us.=C2=A0 In
=C2=A0 =C2=A0any case, if the label-to-PW binding is not available the PW M= UST be
=C2=A0 =C2=A0considered in the down state.

=C2=A0 =C2=A0Once the PW status negotiation procedures are completed and if= they
=C2=A0 =C2=A0result in the use of the label withdraw method for PW status =C2=A0 =C2=A0communication, and this method is not supported by one of the = PEs,
=C2=A0 =C2=A0then that PE must send a Label Release Message to its peer wit= h the
=C2=A0 =C2=A0following error:

=C2=A0 =C2=A0"Label Withdraw PW Status Method Not Supported"

=C2=A0 =C2=A0If the label withdraw method for PW status communication is se= lected
=C2=A0 =C2=A0for the PW, it will result in the Label Mapping Message being<= br> =C2=A0 =C2=A0advertised only if the attachment circuit is active.=C2=A0 The= PW status
=C2=A0 =C2=A0signaling procedures described in this section MUST be fully =C2=A0 =C2=A0implemented.
NEW
=C2=A0 =C2=A0The PEs MUST send Label Mapping Messages to their peers as soo= n as
=C2=A0 =C2=A0the PW is configured and administratively enabled, regardless = of the
=C2=A0 =C2=A0attachment circuit state.=C2=A0 The PW label should not be wit= hdrawn
=C2=A0 =C2=A0unless the operator administratively configures the pseudowire= down
=C2=A0 =C2=A0(or the PW configuration is deleted entirely).

=C2=A0 =C2=A0Section 6.3.2 describes a mechanism for signaling the status o= f the
=C2=A0 =C2=A0PW and AC.=C2=A0 Additionally, a simple label withdraw method = MAY be used
=C2=A0 =C2=A0to signal the PW status and AC status.=C2=A0 In any case, if t= he label-to-
=C2=A0 =C2=A0PW binding is not available the PW MUST be considered to be in= the
=C2=A0 =C2=A0down state.

=C2=A0 =C2=A0The PEs negotiate which PW and AC status signaling mechanism t= o use
=C2=A0 =C2=A0by following the procedures in Section 6.3.3.=C2=A0 If the PW = negotiation
=C2=A0 =C2=A0procedures are completed and if they result in the use of the = simple
=C2=A0 =C2=A0label withdraw method for PW status communication, and if this= method
=C2=A0 =C2=A0is not supported by one of the PEs then that PE must send a La= bel
=C2=A0 =C2=A0Release Message to its peer with the following error:

=C2=A0 =C2=A0"Label Withdraw PW Status Method Not Supported"

=C2=A0 =C2=A0If the label withdraw method for PW status communication is se= lected
=C2=A0 =C2=A0for the PW, it will result in the Label Mapping Message being<= br> =C2=A0 =C2=A0advertised only if the AC is active.

=C2=A0 =C2=A0The PW status signaling procedures described in Section 6.3.2 = MUST be
=C2=A0 =C2=A0fully implemented.
END

---

Section 6.3.2 achieves ambiguity by stating...
=C2=A0 =C2=A0The general format of the Notification Message is:
...and then showing the specific case of "PW status".

You can fix this by re-ordering and tweaking slightly, as follows.

Note that the old text says:
=C2=A0 =C2=A0Since this notification does not
=C2=A0 =C2=A0refer to any particular message, the Message Id and Message Ty= pe
=C2=A0 =C2=A0fields are set to 0.
...but I think the Message Type is set to 0x0001 :-)


OLD
=C2=A0 =C2=A0The Status TLV is transported to the remote PW peer via the LD= P
=C2=A0 =C2=A0Notification message.=C2=A0 The general format of the Notifica= tion Message
=C2=A0 =C2=A0is:

=C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A03
=C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|0|=C2=A0 =C2=A0Notification (0x0001)=C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 Message Length=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= br> =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Message ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Status (TLV)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 PW Status TLV=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PWId FEC TLV or Gene= ralized ID FEC TLV=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PW Gro= uping ID TLV (Optional)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+



=C2=A0 =C2=A0The Status TLV status code is set to 0x00000028, "PW stat= us", to
=C2=A0 =C2=A0indicate that PW status follows.=C2=A0 Since this notification= does not
=C2=A0 =C2=A0refer to any particular message, the Message Id and Message Ty= pe
=C2=A0 =C2=A0fields are set to 0.
NEW
=C2=A0 =C2=A0The Status TLV is transported to the remote PW peer via the LD= P
=C2=A0 =C2=A0Notification message as described in [RFC5036].

=C2=A0 =C2=A0The Status TLV status code is set to 0x00000028, "PW stat= us", to
=C2=A0 =C2=A0indicate that PW status follows.=C2=A0 The format of the Notif= ication
=C2=A0 =C2=A0Message for carrying the PW Status is as follows:


=C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A03
=C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|0|=C2=A0 =C2=A0Notification (0x0001)=C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 Message Length=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= br> =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Message ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Status (TLV)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 PW Status TLV=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PWId FEC TLV or Gene= ralized ID FEC TLV=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PW Gro= uping ID TLV (Optional)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+


=C2=A0 =C2=A0Since this notification does not refer to any particular messa= ge,
=C2=A0 =C2=A0the Message Id field is set to 0.
END

---

Section 8 could be tidied a little.

The use of "in general" gives the IANA no way to know whether the= y
should or should not update a reference.

Are you sure that you want to remove the nice, concise listing of code
points that are present in RFC 4447?

8.1, 8.2, and 8.3 all say "new". I suggest deleting that word.
And lastly, "IANA needs to..." is not what we say :-) "IANA = is requested
to..." is nicer.

[NB: The Shepherd write-up seems to report all this wrongly at Q17]

---

Shouldn't the whole of Section 10 be moved to an interop report
somewhere? It's presence within the document seems somewhat temporally<= br> unstable. I understand that you want to write it down and record it
somewhere, also that you probably developed it in the I-D as a useful
place for working text. For advice about how and where to do this you
can look at RFC 5657.

You seem to have answered the four points from 6410, but may be missing
a little corroboration.

>=C2=A0 The pseudowire technology was first deployed in 2001 and has bee= n
>=C2=A0 widely deployed by many carriers. [RFC7079] documents the result= s of
>=C2=A0 a survey of PW implementations, with specific emphasis on Contro= l
>=C2=A0 Word usage.=C2=A0 [EANTC] documents a public multi-vendor intero= perability
>=C2=A0 test of MPLS and Carrier Ethernet equipment, which included test= ing
>=C2=A0 of Ethernet, ATM and TDM pseudowires.

7079 is a slightly related piece of survey work, but the only mention of LDP (which is the subject of *this* document) is to point out an issue
with non-implementation.

The EANTC reference really needs something that helps us find the report of the interop event. Possibly this is
http://www.eantc.de/fileadmin/eantc/downloads/events/2007-2010/= MPLSEWC09/EANTC-MPLSEWC2009-WhitePaper-v1.0.pdf
Looking at that paper, it definitely supports the claim of multiple
interoperating implementations of 4447.

We lack, however, any statements about "widespread deployment and
successful operational experience."

>=C2=A0 The errata against [RFC4447] are all editorial in nature and hav= e
>=C2=A0 been addressed in this document.

Good (except for those not addressed as above, and except that some of
those errata are incorrectly marked as "Technical").

>=C2=A0 All features in this specification have been implemented by mult= iple
>=C2=A0 vendors.

How do we know this?
Further, are all the features used? One point of this step in the
process is to prune out features that are unnecessary (and so complicate implementation and operation, and cost money).

>=C2=A0 There is no IPR filed against this document or its predecessor.<= br>
This may be overly vague (you probably mean "No IPR disclosures have been made to the IETF related to this document, to RFC 4447 or RFC 6723, or to the Internet-Drafts that resulted in RFC 4447 and RFC 6723.").
---

=3D Nits =3D

In the Abstract, probably...

OLD
=C2=A0 =C2=A0This document has been written to address errata in a previous=
=C2=A0 =C2=A0version of this standard.
NEW
=C2=A0 =C2=A0This document has been written to address errata in a previous=
=C2=A0 =C2=A0version of this specification.
END

But, actually, I think you are missing the main purpose which is to
advance the spec to full standard.

On reflection, I think that this paragraph probably served well in the
draft as it was being processed, but can be removed now. The equivalent
text obviously needs to be in the shepherd write-up.

[ditto the paragraph in the introduction]

---

Thank you for including Section 1. It's important and helpful.

Three tiny points:

Second para should probably s/However/Additionally/

The RFC Editor requires that section 1 is the Introduction. A simple
solution is to swap sections 1 and 2, or to move the current section 2
to be the new section 1 and the current section 1 to be section 1.1.

The text says "A note was added to clarify that the C-bit is part of the FEC." I think you should s/was/has been/ and you could also useful= ly
give a little hint as to where the note was added.

---

Shouldn't you mention the inclusion of text referencing 7358? This is clearly a change to the original text. I wonder, however, whether what
really want to do is take that part of 7358 that updated 4447 and simply write it here so that this spec has no need of that reference.

Either way, you also need to take care about the stability requirement
for advancement.

---

In 6.2.2.1
please note that IANA has "PW Interface Parameters TLV" not "= ;Interface
Parameters TLV".

The is a good chance to make this consistent.

---

In 6.2.2.2 and the rest of the document, please note that the IANA has
"PW Group ID TLV" not "PW Grouping ID TLV".

The is a good chance to make this consistent.

---

6.3.2 has a figure which claims to include a "PWId FEC TLV" or a<= br> "Generalized ID FEC TLV". However, 6.1 and 6.2 describe these as<= br> "elements" not TLVs and they show up in the Forwarding Equivalenc= e Class
(FEC) Type Name Space.

I think you can clarify 6.3.2 by explaining that what is included here
is "a FEC TLV containing either a PWId FEC element or a Generalized FE= C
element.

Then, just after the figure you have "The PW FEC TLV" but it is j= ust a
"FEC TLV"

---

In 7.3 you have "re-provisioned". I wonder whether you mean
"re-configured". "Provisioning" has a context initial s= et-up, so re-
provisioning suggests (to me?) re-initialization.

---

In the first para of 7.3 you have "PW C-bit negotiation procedure"= ; and
"Control-Word negotiation procedures".

Could you decide on a single name, and on whether it is singular or
plural.

---

7.3
OLD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -i. If local PE has previously sent a Label Map= ping message, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST send a Label Withdraw messag= e to remote PE and wait
NEW
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -i. If the local PE has previously sent a Label= Mapping message, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST send a Label Withdraw messag= e to the remote PE and wait
END

---

7.3
OLD
=C2=A0 =C2=A0 =C2=A0 =C2=A0-ii. the local PE MUST send a label release mess= age to the remote
NEW
=C2=A0 =C2=A0 =C2=A0 =C2=A0-ii. The local PE MUST send a Label Release mess= age to the remote
END

---

7.3
s/negotaiation/negotiation/
s/renegotation/renegotiation/

---

7.3

=C2=A0 =C2=A0The above C-bit renegotiation process SHOULD NOT be interrupte= d until
=C2=A0 =C2=A0it is completed, or unpredictable results might occur.

This is a bit odd. Normally the "or" that follows a "SHOULD&= quot; or "SHOULD
NOT" explains the conditions under which you might want to vary the "SHOULD".

But I'm struggling: interrupted by whom and by doing what?

---

Some of the formatting in the references seems to have been hit with a
global change of /. /.=C2=A0 / You might want to polish.

---

The latest version of G.707 is dated January 2007. Is there any reason
to not update the reference?

---

Have a look at Section 8 of RFC 5036 for an example of a nice way to
handle "legacy authors" and credits for past work.

In any case, the RFC Editor will require that Section 15 is renamed
"Contributors".

---

There are two trivial nits from idnits.


--001a113d2f8a21505a052c5a96e9-- From nobody Mon Feb 22 07:21:05 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92FB1B3566; Mon, 22 Feb 2016 07:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.523 X-Spam-Level: X-Spam-Status: No, score=0.523 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, FSL_HELO_BARE_IP_2=1.499, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=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 VU33Ev6ql0Dy; Mon, 22 Feb 2016 07:20:58 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 52E5A1B3470; Mon, 22 Feb 2016 07:20:58 -0800 (PST) Received: by mail-pa0-x22d.google.com with SMTP id fl4so92749939pad.0; Mon, 22 Feb 2016 07:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:references:in-reply-to:to:cc :mime-version:content-type:content-transfer-encoding; bh=luAIcWdy+7w9fULbhEpdF+nkHpOz+qHp5qzB1JEXDc8=; b=gXl+GSGdMj/giX1kTgmDHUjefdMM8ZhbEKJspjPFM2WefdCRoPUO2zUnAo8aSGZTxe JmUmwE+wUMHZKfzITqH9QnSNxR007Gz6xHYtXF7XQf3tyNERe1L9+ujf0h8AQLXBzfI6 Z/dPmbbgyvae/mdErV7ElG7MUXFcTpUER5YRnmoIwoGOWN7Sjz0PY5lwWk0YAMysdEyN hGk65/pzoOcjYQ2Jiar0eH7cLPcq0fyNEsuzy6HMOsY7j8zi1j4tOjDwyKiGNGHCCnau lXI1mqToMusHvHJ5RndfBGrz1tJX+yNzo+Ngo0FUL8d2eG/7zCebjYbrCZO7XWr1c97+ IBhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:references :in-reply-to:to:cc:mime-version:content-type :content-transfer-encoding; bh=luAIcWdy+7w9fULbhEpdF+nkHpOz+qHp5qzB1JEXDc8=; b=RGoUATPyx3relcCmU8KhqXu6fu4QaWI+jYAcmaGoFcs/kT+Bts7Pn61gKf3jJ+vM0u bUs0yDv6ozRFOZVzRuqkZTae0/gRKZQ7q4IXpTEdTHEuKhTI+KeyQzhekaVoa1LFlvyE BTo7NP4aPYPuJY4clW2gtmrLWwFnb7lS5w+QHkh8shRWMMlvuVrlZXRqPqJkwa69NtUx aXNzKRWSTzoI/QI0FBV8utzwhtT5y2soFgGlnHPImd8KwEfCFQToRjpzV380zGrd7bxH 1ccnUbZf63kF1d2TVDeRgYcH3B4Dfuz8mBVze139IrOWrSDhgpbMDCRrjLDIlFbKL0AW PARw== X-Gm-Message-State: AG10YOTgXj/EQWQ5Lsj1aWmvVoTG1pNQUGyD9xBj6OYEtJ/V2rBq45xdOZqq+KPUc7HsaQ== X-Received: by 10.66.55.6 with SMTP id n6mr39346986pap.35.1456154457987; Mon, 22 Feb 2016 07:20:57 -0800 (PST) Received: from 192.168.1.100 ([103.251.128.68]) by smtp.gmail.com with ESMTPSA id s197sm37627586pfs.62.2016.02.22.07.20.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 07:20:56 -0800 (PST) From: Lizhong Jin Message-ID: <611203F2-3053-4316-9BE8-70307E661216@gmail.com> Date: Mon, 22 Feb 2016 23:20:51 +0800 References: <035501d16cba$d1e22270$75a66750$@olddog.co.uk> In-Reply-To: <035501d16cba$d1e22270$75a66750$@olddog.co.uk> To: "adrian@olddog.co.uk" X-Mailer: NetEase iOS Mail 4.7.1.673 [iPhone 6S Plus iOS9.2.1] MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-pals-rfc4447bis.all@ietf.org" , "pals@ietf.org" Subject: [RTG-DIR] =?utf-8?q?Re=EF=BC=9A_Routing_Directorate_review_of_dra?= =?utf-8?q?ft-ietf-pals-rfc4447bis?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 15:21:01 -0000
Hi,
I read the old version of 4447bis draft be= fore, but did not find the merging of 6723. In current version, it is mor= e of merging 4447 and 6723 as one draft, which I believe is a better way.= R=46C6723 solves a technical bug of R=46C4447. I give some inline commen= ts below for Adrian's review regarding 6723.

Regards
Lizhong
=E5= =9C=A82016=E5=B9=B402=E6=9C=8821=E6=97=A5 23:16=EF=BC=8CAdrian =46arrel =E5=86=99=E9=81=93:
Hello, =20

I have been selected as the Routing Directorate reviewer for this dra= ft. The Routing Directorate seeks to review all routing or routing-relate= d drafts as they pass through IET=46 last call and IESG review. The purpo= se of the review is to provide assistance to the Routing ADs. =46or more = information about the Routing Directorate, please see =E2=80=8Bhttp://tra= c.tools.ietf.org/area/rtg/trac/wiki/RtgDir =20

Although these comments are primarily for the use of the Routing ADs,= it would be helpful if you could consider them as the draft advances, an= d strive to resolve them through discussion or by updating the draft. =20

Thanks,
Adrian

=3D=3D=3D

Document: draft-ietf-pals-rfc4447bis-03.txt =20
Reviewer: Adrian =46arrel
Review Date: 21 =46ebruary 2016
IET=46 LC End Date: Not yet started
Intended Status: Internet Standard

=3D Summary =3D

I have some minor concerns about this document that I think should be= resolved before publication. =20

=3D Comments =3D

I'm OK to see 4447 being advanced to full standard, although I'm also= a little surprised that there was energy to do it.

The work is largely mechanical. My comments are a mix of minor proces= s concerns (that your AD should be able to resolve), minor text clarifica= tions, and nits.

It's been a while since I was concerned with LDP, but I have no reaso= n to doubt the integrity of this document.

=3D Major Issues =3D

No major issues found. =20

=3D Minor Issues =3D

I believe that this document should be marked as obsoleting 4447 and = =20
6723. It will result in a new R=46C with a new number, so 4447 will n= o
longer be relevant. And, as Section 1 says: a new section (6.3) on =20
control-word renegotiation by label request message has been added,
obsoleting R=46C 6723.

By the way, it is section 7.3 (not 6.3) that you have added=21

=5BNB: Q16 of the Shepherd write-up seems a bit garbled on this front= .
Especially =22Will publication of this document change the status of = any
existing R=46Cs=3F=22 seems to need a much clearer answer=21=5D

---

I'm not up to speed on the new process for advancing a specification = to
Internet-Standard when it has normative references that are not =20
similarly advanced/advancing. I do know that the process changed
recently and I am sure that your AD can look it up.

---

It might be a reasonable question to ask why some of the
(informatively) referenced related PW R=46Cs (such as encapsulations)=
are not being advanced at the same time, especially those that are
described as =22companion documents=22.

---

It seems unnecessary petty-fogging process, but the inclusion of
section 7.3 seems to me to defeat the stability requirement for
advancement to Internet Standard unless your claim here is that you
are advancing 4447 and 6723 together in this single document. That
might be fine. 
=5BLizhong=5D similar feeling from me. It se= ems to combine 4447 and 6723 into one draft. If that is the intention, I = suggest to list the 6723 authors in this draft. 

---

The Errata that have been deliberately disregarded need to be marked = as
Rejected. I think the ones that have been actioned could usefully be = =20
marked as Verified or have a note added saying =22fixed in R=46Cabcd=22= .

As far as I can tell:

3554 was not actioned
938 was done
86 was done
3555 was done
3115 no longer applies
3114 was done
3112 was done
1530 was done

---

Because you (incorrectly) said that section 6.3 was new text, I gave = it
careful review. I think the text is in rather poor state:

=46or example, in 6.3.1...

  Using the procedures
  outlined in this section, a simple label withdraw method= MAY also be
  supported as a legacy means of signaling PW status and A= C status.

...Since this is *the* specification now, what does =22legacy=22 mean= =3F

Indeed, you end 6.3.1 with...
  The PW status
  signaling procedures described in this section MUST be f= ully
  implemented.
...which kind of implies ... hmm.

I think you could rework 6.3.1 to handle this more gracefully and avo= id
the =22clunk=22 of the 2nd para...

  Once the PW status negotiation procedures are completed = and if they

...where we are surprised to hear about status negotiation.

=46or example:

OLD
  The PEs MUST send Label Mapping Messages to their peers = as soon as
  the PW is configured and administratively enabled, regar= dless of the
  attachment circuit state.  The PW label should not = be withdrawn
  unless the operator administratively configures the pseu= dowire down
  (or the PW configuration is deleted entirely).  Usi= ng the procedures
  outlined in this section, a simple label withdraw method= MAY also be
  supported as a legacy means of signaling PW status and A= C status.  In
  any case, if the label-to-PW binding is not available th= e PW MUST be
  considered in the down state.

  Once the PW status negotiation procedures are completed = and if they
  result in the use of the label withdraw method for PW st= atus
  communication, and this method is not supported by one o= f the PEs,
  then that PE must send a Label Release Message to its pe= er with the
  following error:

  =22Label Withdraw PW Status Method Not Supported=22

  If the label withdraw method for PW status communication= is selected
  for the PW, it will result in the Label Mapping Message = being
  advertised only if the attachment circuit is active. &nb= sp;The PW status
  signaling procedures described in this section MUST be f= ully
  implemented.
NEW
  The PEs MUST send Label Mapping Messages to their peers = as soon as
  the PW is configured and administratively enabled, regar= dless of the
  attachment circuit state.  The PW label should not = be withdrawn
  unless the operator administratively configures the pseu= dowire down
  (or the PW configuration is deleted entirely). =20

  Section 6.3.2 describes a mechanism for signaling the st= atus of the =20
  PW and AC.  Additionally, a simple label withdraw m= ethod MAY be used =20
  to signal the PW status and AC status.  In any case= , if the label-to-
  PW binding is not available the PW MUST be considered to= be in the =20
  down state.

  The PEs negotiate which PW and AC status signaling mecha= nism to use
  by following the procedures in Section 6.3.3.  If t= he PW negotiation
  procedures are completed and if they result in the use o= f the simple =20
  label withdraw method for PW status communication, and i= f this method
  is not supported by one of the PEs then that PE must sen= d a Label
  Release Message to its peer with the following error:

  =22Label Withdraw PW Status Method Not Supported=22

  If the label withdraw method for PW status communication= is selected
  for the PW, it will result in the Label Mapping Message = being
  advertised only if the AC is active.
  
  The PW status signaling procedures described in Section = 6.3.2 MUST be
  fully implemented.
END

---

Section 6.3.2 achieves ambiguity by stating...
  The general format of the Notification Message is:
...and then showing the specific case of =22PW status=22.

You can fix this by re-ordering and tweaking slightly, as follows.

Note that the old text says:
  Since this notification does not
  refer to any particular message, the Message Id and Mess= age Type
  fields are set to 0.
...but I think the Message Type is set to 0x0001 :-)


OLD
  The Status TLV is transported to the remote PW peer via = the LDP
  Notification message.  The general format of the No= tification Message
  is:

   0         =           1   = ;            =     2         = ;          3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C0=7C   Notification (0x0001)   &n= bsp; =7C      Message Length   &n= bsp;       =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C         &nbs= p;            = ; Message ID          &= nbsp;           &n= bsp;       =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C         &nbs= p;            = ; Status (TLV)          = ;            =       =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C         &nbs= p;            = ;PW Status TLV          &nbs= p;            = ;     =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C         &nbs= p; PWId =46EC TLV or Generalized ID =46EC TLV    &nbs= p;         =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C         &nbs= p;     PW Grouping ID TLV (Optional)   = ;            =     =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+



  The Status TLV status code is set to 0x00000028, =22PW s= tatus=22, to
  indicate that PW status follows.  Since this notifi= cation does not
  refer to any particular message, the Message Id and Mess= age Type
  fields are set to 0.
NEW
  The Status TLV is transported to the remote PW peer via = the LDP
  Notification message as described in =5BR=46C5036=5D.
  
  The Status TLV status code is set to 0x00000028, =22PW s= tatus=22, to
  indicate that PW status follows.  The format of the= Notification
  Message for carrying the PW Status is as follows:
  

   0         =           1   = ;            =     2         = ;          3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C0=7C   Notification (0x0001)   &n= bsp; =7C      Message Length   &n= bsp;       =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C         &nbs= p;            = ; Message ID          &= nbsp;           &n= bsp;       =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C         &nbs= p;            = ; Status (TLV)          = ;            =       =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C         &nbs= p;            = ;PW Status TLV          &nbs= p;            = ;     =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C         &nbs= p; PWId =46EC TLV or Generalized ID =46EC TLV    &nbs= p;         =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
  =7C         &nbs= p;     PW Grouping ID TLV (Optional)   = ;            =     =7C
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+


  Since this notification does not refer to any particular= message,
  the Message Id field is set to 0.
END

---

Section 8 could be tidied a little.

The use of =22in general=22 gives the IANA no way to know whether the= y
should or should not update a reference. =20

Are you sure that you want to remove the nice, concise listing of cod= e
points that are present in R=46C 4447=3F

8.1, 8.2, and 8.3 all say =22new=22. I suggest deleting that word.

And lastly, =22IANA needs to...=22 is not what we say :-) =22IANA is = requested
to...=22 is nicer.

=5BNB: The Shepherd write-up seems to report all this wrongly at Q17=5D=

---

Shouldn't the whole of Section 10 be moved to an interop report
somewhere=3F It's presence within the document seems somewhat tempora= lly
unstable. I understand that you want to write it down and record it
somewhere, also that you probably developed it in the I-D as a useful= =20
place for working text. =46or advice about how and where to do this y= ou
can look at R=46C 5657.

You seem to have answered the four points from 6410, but may be missi= ng
a little corroboration. =20

>  The pseudowire technology was first deployed in 2001 and h= as been
>  widely deployed by many carriers. =5BR=46C7079=5D document= s the results of
>  a survey of PW implementations, with specific emphasis on = Control
>  Word usage.  =5BEANTC=5D documents a public multi-ven= dor interoperability
>  test of MPLS and Carrier Ethernet equipment, which include= d testing
>  of Ethernet, ATM and TDM pseudowires.

7079 is a slightly related piece of survey work, but the only mention= of =20
LDP (which is the subject of *this* document) is to point out an issu= e
with non-implementation.

The EANTC reference really needs something that helps us find the rep= ort
of the interop event. Possibly this is
http://www.eantc.de/fileadmin/eantc/downloads/events/2007-2010/MPLSEW= C09/EANTC-MPLSEWC2009-WhitePaper-v1.0.pdf
Looking at that paper, it definitely supports the claim of multiple
interoperating implementations of 4447.

We lack, however, any statements about =22widespread deployment and =20
successful operational experience.=22

>  The errata against =5BR=46C4447=5D are all editorial in na= ture and have
>  been addressed in this document.

Good (except for those not addressed as above, and except that some o= f
those errata are incorrectly marked as =22Technical=22).

>  All features in this specification have been implemented b= y multiple
>  vendors.

How do we know this=3F
=46urther, are all the features used=3F One point of this step in the= =20
process is to prune out features that are unnecessary (and so complic= ate
implementation and operation, and cost money).

>  There is no IPR filed against this document or its predece= ssor.

This may be overly vague (you probably mean =22No IPR disclosures hav= e
been made to the IET=46 related to this document, to R=46C 4447 or R=46= C 6723,
or to the Internet-Drafts that resulted in R=46C 4447 and R=46C 6723.= =22).

---

=3D Nits =3D

In the Abstract, probably...

OLD
  This document has been written to address errata in a pr= evious
  version of this standard.
NEW
  This document has been written to address errata in a pr= evious
  version of this specification.
END

But, actually, I think you are missing the main purpose which is to
advance the spec to full standard.

On reflection, I think that this paragraph probably served well in th= e
draft as it was being processed, but can be removed now. The equivale= nt =20
text obviously needs to be in the shepherd write-up.

=5Bditto the paragraph in the introduction=5D

---

Thank you for including Section 1. It's important and helpful.

Three tiny points:

Second para should probably s/However/Additionally/

The R=46C Editor requires that section 1 is the Introduction. A simpl= e
solution is to swap sections 1 and 2, or to move the current section = 2
to be the new section 1 and the current section 1 to be section 1.1.

The text says =22A note was added to clarify that the C-bit is part o= f =20
the =46EC.=22 I think you should s/was/has been/ and you could also u= sefully
give a little hint as to where the note was added.
           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;        
---

Shouldn't you mention the inclusion of text referencing 7358=3F This = is
clearly a change to the original text. I wonder, however, whether wha= t
really want to do is take that part of 7358 that updated 4447 and sim= ply
write it here so that this spec has no need of that reference.

Either way, you also need to take care about the stability requiremen= t =20
for advancement.

---

In 6.2.2.1
please note that IANA has =22PW Interface Parameters TLV=22 not =22In= terface
Parameters TLV=22.

The is a good chance to make this consistent.

---

In 6.2.2.2 and the rest of the document, please note that the IANA ha= s
=22PW Group ID TLV=22 not =22PW Grouping ID TLV=22.

The is a good chance to make this consistent.

---

6.3.2 has a figure which claims to include a =22PWId =46EC TLV=22 or = a
=22Generalized ID =46EC TLV=22. However, 6.1 and 6.2 describe these a= s
=22elements=22 not TLVs and they show up in the =46orwarding Equivale= nce Class
(=46EC) Type Name Space.

I think you can clarify 6.3.2 by explaining that what is included her= e
is =22a =46EC TLV containing either a PWId =46EC element or a General= ized =46EC
element.

Then, just after the figure you have =22The PW =46EC TLV=22 but it is= just a
=22=46EC TLV=22

---

In 7.3 you have =22re-provisioned=22. I wonder whether you mean
=22re-configured=22. =22Provisioning=22 has a context initial set-up,= so re-
provisioning suggests (to me=3F) re-initialization.
=5BLizhong=5D re-configured is fine here.
---

In the first para of 7.3 you have =22PW C-bit negotiation procedure=22= and
=22Control-Word negotiation procedures=22.

Could you decide on a single name, and on whether it is singular or
plural.
=5BLizhong=5D Could use control-word negotiation procedures in both place= s.
---

7.3
OLD
       -i. If local PE has previo= usly sent a Label Mapping message, it
           MU= ST send a Label Withdraw message to remote PE and wait
NEW
       -i. If the local PE has pr= eviously sent a Label Mapping message, it
           MU= ST send a Label Withdraw message to the remote PE and wait
END

---

7.3
OLD
      -ii. the local PE MUST send a la= bel release message to the remote
NEW
      -ii. The local PE MUST send a La= bel Release message to the remote
END

---

7.3
s/negotaiation/negotiation/
s/renegotation/renegotiation/

---

7.3

  The above C-bit renegotiation process SHOULD NOT be inte= rrupted until
  it is completed, or unpredictable results might occur.

This is a bit odd. Normally the =22or=22 that follows a =22SHOULD=22 = or =22SHOULD
NOT=22 explains the conditions under which you might want to vary the= =20
=22SHOULD=22. =20

But I'm struggling: interrupted by whom and by doing what=3F
=5BLizhong=5D there is not this sentence in 6723. The implementation shou= ld treat above procedure as atomic.

--- =20

Some of the formatting in the references seems to have been hit with = a
global change of /. /.  / You might want to polish.

---

The latest version of G.707 is dated January 2007. Is there any reaso= n
to not update the reference=3F

---

Have a look at Section 8 of R=46C 5036 for an example of a nice way t= o
handle =22legacy authors=22 and credits for past work.

In any case, the R=46C Editor will require that Section 15 is renamed= =20
=22Contributors=22.

---

There are two trivial nits from idnits.