From nobody Sat Oct 1 06:16:11 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0E812B0C8; Sat, 1 Oct 2016 06:16:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147532777013.4211.16107945443678515329.idtracker@ietfa.amsl.com> Date: Sat, 01 Oct 2016 06:16:10 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-shared-ring-protection-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 13:16:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Shared-Ring protection (MSRP) mechanism for ring topology Authors : Weiqiang Cheng Lei Wang Han Li Huub van Helvoort Jie Dong Filename : draft-ietf-mpls-tp-shared-ring-protection-03.txt Pages : 47 Date : 2016-10-01 Abstract: This document describes requirements, architecture and solutions for MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switch (RPS) Protocol that is used to coordinate the protection behavior of the nodes on MPLS ring. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-tp-shared-ring-protection-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-shared-ring-protection-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 4 03:07:31 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CB312977D; Tue, 4 Oct 2016 03:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC_vYAJ8rBca; Tue, 4 Oct 2016 03:07:25 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE72412977F; Tue, 4 Oct 2016 03:07:24 -0700 (PDT) Received: from [192.168.1.3] (unknown [49.146.59.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B8E5C18013E4; Tue, 4 Oct 2016 12:07:21 +0200 (CEST) From: Loa Andersson To: "mpls@ietf.org" , "mpls-chairs@ietf.org" , Deborah A Brungard Message-ID: <2c9816af-7f9f-aad1-d1b6-0eee0aed4118@pi.nu> Date: Tue, 4 Oct 2016 18:07:17 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] My apologies X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 10:07:29 -0000 Working Group, I've relocated to the Philippines for the winter. Earlier this has been done quite smoothly, bu this year I have had problems with my Internet access. The problems were quite easy to fix once they were located, but it took to steps, removing an anti-virus program that came with Windows 10 and that I don't wanted to have. Made one of my chat programs work so I could share screen with my support back in Sweden and find a a very odd network setting. In total this has caused an interrupt from Thu Sep 27 to Wed Oct 4. Anyhow - everything works now and I've slowly started to dig out from under a mail mountain. I know that there are things that I should have done, and will get to them asap - I guess within the week. The mail backlog is about 1k, but most is easy to fix. Though if you think I completely dropped something, let me know! /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Oct 4 06:33:50 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2321812986B; Tue, 4 Oct 2016 06:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PLztMxJ8m7L; Tue, 4 Oct 2016 06:33:46 -0700 (PDT) Received: from owl2.lab.dtag.de (unknown [194.25.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id D3F0B129859; Tue, 4 Oct 2016 06:33:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id 53856CD362; Tue, 4 Oct 2016 15:33:45 +0200 (CEST) Received: from TSUNAMI-Boggart-33.lab.DTAG.de (o-Boggart.lab.dtag.de [62.153.176.78]) by owl2.lab.dtag.de (Postfix) with ESMTPSA id 1C5B9CD2FE; Tue, 4 Oct 2016 15:33:45 +0200 (CEST) From: Martin Horneffer To: "John G. Scudder" , spring@ietf.org References: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> Message-ID: <418b17b3-1a88-9a32-0c90-f22c58aa62fd@lab.dtag.de> Date: Tue, 4 Oct 2016 15:33:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] WG adoption requested for draft-psarkar-spring-mpls-anycast-segments X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 13:33:49 -0000 As an operator and as co-author I strongly support WG adoption of this document. IMO it is essential to make the SPRING architecture for the MPLS dataplane complete. Also I am not aware of any IPR. BR, Martin Horneffer Am 24.07.16 um 14:39 schrieb John G. Scudder: > Dear WG (and cc MPLS, please include SPRING in replies), > > As we discussed at our meeting, working group adoption has been requested for draft-psarkar-spring-mpls-anycast-segments. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. > > We will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. Also, the length of the author list for this document exceeds the maximum recommended. Assuming the document is adopted, the authors should be prepared to correct this when submitting as a WG document, ideally by reducing the list to simply the active editor(s) and making use of the "contributors" section for the full list. > > Thanks, > > --Bruno and John > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Tue Oct 4 09:08:43 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 885A7127ABE; Tue, 4 Oct 2016 09:08:42 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147559732254.12976.1771898133278173726.idtracker@ietfa.amsl.com> Date: Tue, 04 Oct 2016 09:08:42 -0700 Archived-At: Cc: mpls@ietf.org, mpls-chairs@ietf.org, draft-ietf-mpls-rfc4379bis@ietf.org Subject: [mpls] Last Call: (Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 16:08:42 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-10-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. This document obsoletes RFCs 4379, 6424, 6829, and 7537. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2826/ From nobody Wed Oct 5 11:39:26 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C12F1293FC; Wed, 5 Oct 2016 11:11:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147569107219.28074.10763369347350609389.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2016 11:11:12 -0700 Archived-At: X-Mailman-Approved-At: Wed, 05 Oct 2016 11:39:25 -0700 Cc: itu-t-liaison@iab.org, Multiprotocol Label Switching Discussion List , Common Control and Measurement Plane Discussion List , JP Vasseur , naotaka.morita@ntt-at.co.jp, Path Computation Element Discussion List , Jonathan Hardwick Subject: [mpls] New Liaison Statement, "LS on SG15 OTNT Standardization Work Plan" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 18:11:12 -0000 Title: LS on SG15 OTNT Standardization Work Plan Submission Date: 2016-10-05 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1494/ Please reply by 2017-05-31 From: "Hiroshi Ota" To: n.leymann@telekom.de, loa@pi.nu, swallow.ietf@gmail.com, jonathan.hardwick@metaswitch.com, jpv@cisco.com, julien.meuric@orange.com, daniele.ceccarelli@ericsson.com, zhangfatai@huawei.com Cc: Alvaro Retana ,Deborah Brungard ,Julien Meuric ,Multiprotocol Label Switching Discussion List ,Scott Mansfield ,Jonathan Hardwick ,Fatai Zhang ,George Swallow ,Path Computation Element Discussion List ,JP Vasseur ,John Drake ,Alia Atlas ,Daniele Ceccarelli ,Loa Andersson ,Common Control and Measurement Plane Discussion List ,itu-t-liaison@iab.org,Nicolai Leymann , Response Contacts: naotaka.morita@ntt-at.co.jp Technical Contacts: Purpose: For comment Body: Thank you for your review and comments on “Optical Transport Networks & Technologies Standardization Work Plan.” Attached is Issue 22, the latest version updated by the SG15 meeting in September 2016. Editor of the document thanks you for your continued support and the information provided. In this issue (Issue 22), the document is split into two parts to separate up-to-date snapshot-type information and comprehensive database-type information. • Part 1 (newly introduced) provides highlights of relevant SDOs’ activity. • Part 2 updated. Splitting the document into the two parts is intended to make this information more useful and attractive to the potential readers. ITU-T SG15 is considering more effective way to provide the information and more efficient way to maintain and update it. For example for Part 1, setting up the template for reporting. For Part 2, automated production based on database is under consideration. Any comments, not only the correction/update of the information but also the ways to provide the information are highly appreciated. Attachment: OTNT Standardization Work Plan, Issue 22 (TD611/PLEN R1) Attachments: SG15-LS367-td605r1P-Annex-A-1 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-05-itu-t-sg-15-mpls-ccamp-pce-ls-on-sg15-otnt-standardization-work-plan-attachment-1.pdf From nobody Wed Oct 5 19:00:02 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0072B129440; Wed, 5 Oct 2016 19:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlzQZ0pd7CRb; Wed, 5 Oct 2016 18:59:58 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02AD129404; Wed, 5 Oct 2016 18:59:57 -0700 (PDT) Received: from [192.168.1.3] (unknown [49.146.59.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1927E18013E2; Thu, 6 Oct 2016 03:59:54 +0200 (CEST) References: <147569006317.28203.18147454126004317363.idtracker@ietfa.amsl.com> To: "mpls@ietf.org" From: Loa Andersson X-Forwarded-Message-Id: <147569006317.28203.18147454126004317363.idtracker@ietfa.amsl.com> Message-ID: <09983b5e-ab6d-b81a-a31c-13cfdec45ba4@pi.nu> Date: Thu, 6 Oct 2016 09:59:49 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <147569006317.28203.18147454126004317363.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls-chairs@ietf.org" Subject: [mpls] Fwd: NomCom 2016: Call for Nominations Deadlines X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 02:00:01 -0000 Folks, If you not already sent in your nominations please do so prior to the deadline on October 8. /Loa -------- Forwarded Message -------- Subject: NomCom 2016: Call for Nominations Deadlines Date: Wed, 05 Oct 2016 10:54:23 -0700 From: NomCom Chair 2016 Reply-To: ietf@ietf.org To: IETF Announcement List CC: ietf@ietf.org All - A reminder to submit your nominations for the open positions listed below before the October 8, 2016 closing deadline. Please note the following exceptions: Operations, Transport, and Internet. Area nominations for OPS/TSV/INT will remain open until October 15, 2016. While we have several nominations for each of these three areas we have only a limited number of acceptances. The NomCom would like to have at a minimum a "hot spare" for each of these positions as past experience has shown that circumstances can (and may) change before our process closes and we need to have a deep enough bench to manage for all possible outcomes. Please pass this announcement on! Original Announcement: The 2016-17 Nominating Committee (Nomcom) is seeking nominations from now until October 8, 2016. The open positions being considered by this year's Nomcom can be found at the end of this email and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2016/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2016 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2016/nominate/ {Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ } If you are unable to use the web form, nominations may instead be made by email to nomcom-16@ietf.org. If using email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you are nominating someone other than yourself, please tell us if we may tell the nominee that you were the one who made the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! Willing nominees will be asked to fill out a questionnaire specific to the position for which they are nominated. The questionnaires will be available on September 2, 2016 and have a submission deadline of October 13, 2016. NomCom 2016-17 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. Additionally, the nomination form asks if we may share your own name with the nominee. In all other ways, the confidentiality requirements of BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. There is a field on the form you can mark in order to allow the Nomcom to tell the nominee that you were the one who made the nomination. This defaults to “no” - so if you don't mark the field we won’t tell. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before October 8, 2016. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission, as it is easier to decline the nomination than put one in late. The Nomcom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. The list of people and posts whose terms end with the March 2017 IETF meeting, and thus the positions for which this Nomcom is responsible, follows: IAOC Lou Berger IAB Ralph Droms* Russ Housley* Robert Sparks Andrew Sullivan Dave Thaler* Suzanne Woolf IESG Jari Arkko (GEN)* Deborah Brungard (RTG) Ben Campbell (ART) Spencer Dawkins (TSV) Stephen Farrell (SEC)* Joel Jaeggli (OPS)* Terry Manderson (INT) Alvaro Retana (RTG) *- have indicated that they do not intend to accept a renomination. This information is always up to date on https://datatracker.ietf.org/nomcom/2016/ Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB, IESG, and IAOC, under individual tabs at: https://datatracker.ietf.org/nomcom/2016/requirements/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom-16@ietf.org. Thank you for your help in identifying qualified nominees! Lucy Lynch Nomcom Chair 2016-17 nomcom-chair-2016@ietf.org llynch@civil-tongue.net -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Oct 6 01:09:12 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064EF1294C1; Thu, 6 Oct 2016 01:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7Qm0y3FQOie; Thu, 6 Oct 2016 01:09:10 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC8B129554; Thu, 6 Oct 2016 01:09:09 -0700 (PDT) Received: from [192.168.1.3] (unknown [49.146.59.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2478118013E2; Thu, 6 Oct 2016 10:09:06 +0200 (CEST) To: "mpls@ietf.org" References: <06102f2d-8f1d-aac6-9d34-10a27d600bf8@pi.nu> From: Loa Andersson Message-ID: Date: Thu, 6 Oct 2016 16:09:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <06102f2d-8f1d-aac6-9d34-10a27d600bf8@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 08:09:11 -0000 Working Group, authors, We are past the closing date for this wglc. I'm reluctant to close the last call. The reason is that I received some comments off-line that I'd like to hear feed back on. 1. Existing solution mechanism(s) ------------------------------ It is said that even though we have no existing implementations of m:n, there are existing solutions mechanisms that meet the requirements. I would like to have this verified if possible. 2. Not an update of 5654 --------------------- This is probably correct, this document adds two new requirements, but does in no way change RFC 5654. 3. Document structure ------------------ IESG members has recently expressed opinions that we should not publish small stand alone document with a small number of use cases or requirements, thes should rather be kept with the working and published as appendices to the solutions document. I would like to hear comments on this. 4. The document need to be liaised to ITU-T SG15 --------------------------------------------- I agree with this, normally we liaise wg consensus texts, and the document could be liaised when the wglc closes. To hear the feedback on this I will keep the wglc open for another week starting today. /Loa mpls wg co-chair On 18/09/2016 18:39, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-tp-mfp-use-case-and-requirements-02. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There were no IPR disclosures against this document. > > All the authors and contributors have stated on the working group > mailing list that they are not aware of any IPRs that relates to this > document. > > This working group last call ends Oct 2, 2016. > > > /Loa > for the MPLS wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Oct 6 04:37:25 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE39112960D; Thu, 6 Oct 2016 04:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.618 X-Spam-Level: X-Spam-Status: No, score=-5.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It9PDfdsnuvK; Thu, 6 Oct 2016 04:37:21 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6409812960C; Thu, 6 Oct 2016 04:37:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id CD5AA101562; Thu, 6 Oct 2016 13:37:19 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_WrMEjjYEIk; Thu, 6 Oct 2016 13:37:19 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id AB70C101581; Thu, 6 Oct 2016 13:37:11 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.55]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0319.002; Thu, 6 Oct 2016 13:37:11 +0200 From: Rolf Winter To: Loa Andersson , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements Thread-Index: AQHSEZj7spx1qqSFskizzMzQwxEY9qCbDRGAgABZJvA= Date: Thu, 6 Oct 2016 11:37:10 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295DAF1196AD@PALLENE.office.hd> References: <06102f2d-8f1d-aac6-9d34-10a27d600bf8@pi.nu> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.200] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 11:37:24 -0000 SGksDQoNCnBsZWFzZSBzZWUgaW5saW5lLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxvYUBwaS5udV0gDQpTZW50OiBEb25uZXJzdGFn LCA2LiBPa3RvYmVyIDIwMTYgMTA6MDkNClRvOiBtcGxzQGlldGYub3JnDQpDYzogbXBscy1jaGFp cnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy10cC1tZnAtdXNlLWNhc2UtYW5kLXJlcXVpcmVt ZW50c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRy YWZ0LWlldGYtbXBscy10cC1tZnAtdXNlLWNhc2UtYW5kLXJlcXVpcmVtZW50cw0KDQpXb3JraW5n IEdyb3VwLCBhdXRob3JzLA0KDQpXZSBhcmUgcGFzdCB0aGUgY2xvc2luZyBkYXRlIGZvciB0aGlz IHdnbGMuIEknbSByZWx1Y3RhbnQgdG8gY2xvc2UgdGhlIGxhc3QgY2FsbC4gVGhlIHJlYXNvbiBp cyB0aGF0IEkgcmVjZWl2ZWQgc29tZSBjb21tZW50cyBvZmYtbGluZSB0aGF0IEknZCBsaWtlIHRv IGhlYXIgZmVlZCBiYWNrIG9uLg0KDQoxLiBFeGlzdGluZyBzb2x1dGlvbiBtZWNoYW5pc20ocykN CiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBJdCBpcyBzYWlkIHRoYXQg ZXZlbiB0aG91Z2ggd2UgaGF2ZSBubyBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YNCiAgICBt Om4sIHRoZXJlIGFyZSBleGlzdGluZyBzb2x1dGlvbnMgbWVjaGFuaXNtcyB0aGF0IG1lZXQgdGhl DQogICAgcmVxdWlyZW1lbnRzLg0KICAgIEkgd291bGQgbGlrZSB0byBoYXZlIHRoaXMgdmVyaWZp ZWQgaWYgcG9zc2libGUuDQoNCjIuIE5vdCBhbiB1cGRhdGUgb2YgNTY1NA0KICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KICAgIFRoaXMgaXMgcHJvYmFibHkgY29ycmVjdCwgdGhpcyBkb2N1bWVu dCBhZGRzIHR3byBuZXcgcmVxdWlyZW1lbnRzLA0KICAgIGJ1dCBkb2VzIGluIG5vIHdheSBjaGFu Z2UgUkZDIDU2NTQuDQoNCi0tLSBSVw0KVGhpcyBpcyB0aGUgdGV4dCBjb25jZXJuaW5nIHVwZGF0 ZXMgb2YgUkZDIGluIFJGQzIyMjMgKGl0IGhhcyByZWNlbnRseSBiZWVuIG9ic29sZXRlZCBieSBS RkMgNzMyMiwgYnV0IHRleHQgcmVnYXJkaW5nIHRoZSByZWFzb25pbmcgYmVoaW5kIHVwZGF0ZXMg aGFzIGJhc2ljYWxseSB2YW5pc2hlZCB0aGVyZSBhcyBmYXIgYXMgSSBjYW4gdGVsbCk6DQoNClVw ZGF0ZXMNCg0KICAgICAgVG8gYmUgdXNlZCBhcyBhIHJlZmVyZW5jZSBmcm9tIGEgbmV3IGl0ZW0g dGhhdCBjYW5ub3QgYmUgdXNlZA0KICAgICAgYWxvbmUgKGkuZS4sIG9uZSB0aGF0IHN1cHBsZW1l bnRzIGEgcHJldmlvdXMgZG9jdW1lbnQpLCB0byByZWZlcg0KICAgICAgdG8gdGhlIHByZXZpb3Vz IGRvY3VtZW50LiAgVGhlIG5ld2VyIHB1YmxpY2F0aW9uIGlzIGEgcGFydCB0aGF0DQogICAgICB3 aWxsIHN1cHBsZW1lbnQgb3IgYmUgYWRkZWQgb24gdG8gdGhlIGV4aXN0aW5nIGRvY3VtZW50OyBl LmcuLCBhbg0KICAgICAgYWRkZW5kdW0sIG9yIHNlcGFyYXRlLCBleHRyYSBpbmZvcm1hdGlvbiB0 aGF0IGlzIHRvIGJlIGFkZGVkIHRvDQogICAgICB0aGUgb3JpZ2luYWwgZG9jdW1lbnQuDQoNCkkg dGhpbmsgdGhpcyBtYWtlcyB0aGlzIGRvY3VtZW50IGFuIHVwZGF0ZSBhcyBpdCBjb250YWlucyBh biBhZGRlbmR1bSBlc3NlbnRpYWxseS4gT3IgdGhlIG90aGVyIHdheSByb3VuZCwgaWYgeW91IHJl YWQgNTY1NCwgdGhlcmUgaXMgbm8gd2F5IHRoZSByZWFkZXIgY2FuIHRlbGwgdGhlcmUgYXJlIG1v cmUgcmVxdWlyZW1lbnRzLiBBbiB1cGRhdGUgd2lsbCBtYWtlIHRoYXQgY2xlYXIuDQotLS0NCg0K My4gRG9jdW1lbnQgc3RydWN0dXJlDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgSUVTRyBt ZW1iZXJzIGhhcyByZWNlbnRseSBleHByZXNzZWQgb3BpbmlvbnMgdGhhdCB3ZSBzaG91bGQgbm90 DQogICAgcHVibGlzaCBzbWFsbCBzdGFuZCBhbG9uZSBkb2N1bWVudCB3aXRoIGEgc21hbGwgbnVt YmVyIG9mIHVzZSBjYXNlcw0KICAgIG9yIHJlcXVpcmVtZW50cywgdGhlcyBzaG91bGQgcmF0aGVy IGJlIGtlcHQgd2l0aCB0aGUgd29ya2luZyBhbmQNCiAgICBwdWJsaXNoZWQgYXMgYXBwZW5kaWNl cyB0byB0aGUgc29sdXRpb25zIGRvY3VtZW50Lg0KICAgIEkgd291bGQgbGlrZSB0byBoZWFyIGNv bW1lbnRzIG9uIHRoaXMuDQoNCi0tLSBSVw0KSSBjYW4gdW5kZXJzdGFuZCB0aGlzIGFuZCB1c3Vh bGx5IEkgd291bGQgYWdyZWUuIEJ1dCB0aGVuLCBnaXZlbiB0aGUgYWJvdmUgdGhhdCBzb2x1dGlv biBkb2N1bWVudCB3b3VsZCBuZWVkIHRvIHVwZGF0ZSBSRkM1NjU0IGFuZCB0aGF0IHdvdWxkIGJl IHN0cmFuZ2UsIGhhdmluZyBhIHNvbHV0aW9uIGRvY3VtZW50IHVwZGF0ZSBhIHJlcXVpcmVtZW50 cyBkb2N1bWVudC4gSXQgd291bGQgbWl4IHR3byB0aGluZ3MgSSBiZWxpZXZlIHNob3VsZCBiZSBz ZXBhcmF0ZS4gWW91IHVuZm9ydHVuYXRlbHkgY2Fubm90IHJlc3RyaWN0IGFuIHVwZGF0ZSBvZiBh biBSRkMgdG8gYSBzZWN0aW9uIG9mIGEgZGlmZmVyZW50IFJGQy4NCg0KLS0tDQoNCjQuIFRoZSBk b2N1bWVudCBuZWVkIHRvIGJlIGxpYWlzZWQgdG8gSVRVLVQgU0cxNQ0KICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIEkgYWdyZWUgd2l0aCB0aGlz LCBub3JtYWxseSB3ZSBsaWFpc2Ugd2cgY29uc2Vuc3VzIHRleHRzLCBhbmQgdGhlDQogICAgZG9j dW1lbnQgY291bGQgYmUgbGlhaXNlZCB3aGVuIHRoZSB3Z2xjIGNsb3Nlcy4NCg0KLS0tIFJXDQoN ClllcywgdGhhdCBzaG91bGQgYmUgZG9uZS4NCg0KQmVzdCwNCg0KUm9sZg0KDQotLS0NCg0KVG8g aGVhciB0aGUgZmVlZGJhY2sgb24gdGhpcyBJIHdpbGwga2VlcCB0aGUgd2dsYyBvcGVuIGZvciBh bm90aGVyIHdlZWsgc3RhcnRpbmcgdG9kYXkuDQoNCi9Mb2ENCm1wbHMgd2cgY28tY2hhaXINCg0K T24gMTgvMDkvMjAxNiAxODozOSwgTG9hIEFuZGVyc3NvbiB3cm90ZToNCj4gV29ya2luZyBHcm91 cCwNCj4NCj4gVGhpcyBpcyB0byBpbml0aWF0ZSBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIG9uIA0KPiBkcmFmdC1pZXRmLW1wbHMtdHAtbWZwLXVzZS1jYXNlLWFuZC1yZXF1aXJl bWVudHMtMDIuDQo+DQo+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHMgd2cg bWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnKS4NCj4NCj4gVGhlcmUgd2VyZSBubyBJUFIgZGlz Y2xvc3VyZXMgYWdhaW5zdCB0aGlzIGRvY3VtZW50Lg0KPg0KPiBBbGwgdGhlIGF1dGhvcnMgYW5k IGNvbnRyaWJ1dG9ycyBoYXZlIHN0YXRlZCBvbiB0aGUgd29ya2luZyBncm91cCANCj4gbWFpbGlu ZyBsaXN0IHRoYXQgdGhleSBhcmUgbm90IGF3YXJlIG9mIGFueSBJUFJzIHRoYXQgcmVsYXRlcyB0 byB0aGlzIA0KPiBkb2N1bWVudC4NCj4NCj4gVGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBl bmRzIE9jdCAyLCAyMDE2Lg0KPg0KPg0KPiAvTG9hDQo+IGZvciB0aGUgTVBMUyB3ZyBjaGFpcnMN Cg0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBs b2FAbWFpbDAxLmh1YXdlaS5jb20NClNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAg ICAgICAgICAgbG9hQHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAg cGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== From nobody Thu Oct 6 08:42:26 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB3E1296CE; Thu, 6 Oct 2016 08:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xzi0LFDht4Ge; Thu, 6 Oct 2016 08:42:20 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CCA1296DA; Thu, 6 Oct 2016 08:42:18 -0700 (PDT) Received: from [192.168.1.3] (unknown [49.146.59.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 65D0918013E2; Thu, 6 Oct 2016 17:42:15 +0200 (CEST) To: Rolf Winter , "mpls@ietf.org" References: <06102f2d-8f1d-aac6-9d34-10a27d600bf8@pi.nu> <791AD3077F94194BB2BDD13565B6295DAF1196AD@PALLENE.office.hd> From: Loa Andersson Message-ID: <7ffc307b-495b-1b4e-32d0-63b56e842351@pi.nu> Date: Thu, 6 Oct 2016 23:42:09 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <791AD3077F94194BB2BDD13565B6295DAF1196AD@PALLENE.office.hd> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 15:42:25 -0000 Rolf, On 06/10/2016 19:37, Rolf Winter wrote: > Hi, > > please see inline. > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Donnerstag, 6. Oktober 2016 10:09 > To: mpls@ietf.org > Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org > Subject: Re: working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements > > Working Group, authors, > > We are past the closing date for this wglc. I'm reluctant to close the last call. The reason is that I received some comments off-line that I'd like to hear feed back on. > > 1. Existing solution mechanism(s) > ------------------------------ > It is said that even though we have no existing implementations of > m:n, there are existing solutions mechanisms that meet the > requirements. > I would like to have this verified if possible. > > 2. Not an update of 5654 > --------------------- > This is probably correct, this document adds two new requirements, > but does in no way change RFC 5654. > > --- RW > This is the text concerning updates of RFC in RFC2223 (it has recently been obsoleted by RFC 7322, but text regarding the reasoning behind updates has basically vanished there as far as I can tell): > > Updates > > To be used as a reference from a new item that cannot be used > alone (i.e., one that supplements a previous document), to refer > to the previous document. The newer publication is a part that > will supplement or be added on to the existing document; e.g., an > addendum, or separate, extra information that is to be added to > the original document. > > I think this makes this document an update as it contains an addendum essentially. Or the other way round, if you read 5654, there is no way the reader can tell there are more requirements. An update will make that clear. > --- I think your reading is correct - and I very much appreciated a model where w developed things in a series of document - I guess MPLS-TP and sub-projeccts are what comes to mind. But the description of updating is obsoleted, i.e. it is history we can't use to support our arguments. And according to the new orthodoxy and addendum is not an update. /Loa > > 3. Document structure > ------------------ > IESG members has recently expressed opinions that we should not > publish small stand alone document with a small number of use cases > or requirements, thes should rather be kept with the working and > published as appendices to the solutions document. > I would like to hear comments on this. > > --- RW > I can understand this and usually I would agree. But then, given the above that solution document would need to update RFC5654 and that would be strange, having a solution document update a requirements document. It would mix two things I believe should be separate. You unfortunately cannot restrict an update of an RFC to a section of a different RFC. > > --- > > 4. The document need to be liaised to ITU-T SG15 > --------------------------------------------- > I agree with this, normally we liaise wg consensus texts, and the > document could be liaised when the wglc closes. > > --- RW > > Yes, that should be done. > > Best, > > Rolf > > --- > > To hear the feedback on this I will keep the wglc open for another week starting today. > > /Loa > mpls wg co-chair > > On 18/09/2016 18:39, Loa Andersson wrote: >> Working Group, >> >> This is to initiate a two week working group last call on >> draft-ietf-mpls-tp-mfp-use-case-and-requirements-02. >> >> Please send your comments to the mpls wg mailing list (mpls@ietf.org). >> >> There were no IPR disclosures against this document. >> >> All the authors and contributors have stated on the working group >> mailing list that they are not aware of any IPRs that relates to this >> document. >> >> This working group last call ends Oct 2, 2016. >> >> >> /Loa >> for the MPLS wg chairs > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Oct 6 09:00:07 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223DC12970B; Thu, 6 Oct 2016 09:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPeX9w6-BoOB; Thu, 6 Oct 2016 09:00:03 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86E51296F7; Thu, 6 Oct 2016 09:00:02 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u96FtrbF038351; Thu, 6 Oct 2016 12:00:01 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 25wrg471q8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Oct 2016 11:59:59 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u96Fxv36032029; Thu, 6 Oct 2016 11:59:58 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u96FxhQb031636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Oct 2016 11:59:48 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 6 Oct 2016 15:59:34 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.232]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0301.000; Thu, 6 Oct 2016 11:59:34 -0400 From: "BRUNGARD, DEBORAH A" To: Rolf Winter , Loa Andersson , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements Thread-Index: AQHSH8YIEP2oEr8aPUa8kWqppIHFtKCbiWwA Date: Thu, 6 Oct 2016 15:59:33 +0000 Message-ID: References: <06102f2d-8f1d-aac6-9d34-10a27d600bf8@pi.nu> <791AD3077F94194BB2BDD13565B6295DAF1196AD@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295DAF1196AD@PALLENE.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.152.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-06_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610060278 Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 16:00:05 -0000 Hi, I agree with Loa on this is not an update of RFC5654. RFC5654 is a document= reflecting ITU-T requirements for MPLS-TP. This draft is not a result of a= request by ITU-T. The document is building on RFC6372, but it doesn't necessarily "update" RF= C6372. RFC6372 covers a wide range of mechanisms. An implementer of RFC6372= does not have to also implement this document unless they want to support = this extra capability. So this capability is not required for any of those = existing requirements, it's only needed if one wants this capability, so th= e requirements can stand on their own. Note, RFC6372 did not update RFC5654= . I'm recommending to hold this document in the WG until a solution document = is initiated. By doing a solution document, it will help determine if these= requirements and the resulting solution are an update for any of the exist= ing solution documents. As the document only has two requirements, it can be part of an appendix to= a solution document. PCE recently did such a document: https://www.ietf.org/id/draft-ietf-pce-pcep-service-aware-13.txt Of more concern, I've not seen any mailing list discussion on this document= or any solution document proposed indicating interest by the WG, I strongl= y encourage the list be used as progress a solution document. Working in pa= rallel on requirements and a solution is always the best approach. Requirem= ents documents do not need to be published as RFCs, especially these very s= hort type of documents. The IETF Chair summarized this in his May blog on t= he IESG retreat: https://www.ietf.org/blog/2016/05/ Thanks, Deborah > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Rolf Winter > Sent: Thursday, October 06, 2016 7:37 AM > To: Loa Andersson ; mpls@ietf.org > Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and- > requirements@ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mfp-use= -case- > and-requirements >=20 > Hi, >=20 > please see inline. >=20 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Donnerstag, 6. Oktober 2016 10:09 > To: mpls@ietf.org > Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and- > requirements@ietf.org > Subject: Re: working group last call on draft-ietf-mpls-tp-mfp-use-case-a= nd- > requirements >=20 > Working Group, authors, >=20 > We are past the closing date for this wglc. I'm reluctant to close the la= st call. > The reason is that I received some comments off-line that I'd like to hea= r feed > back on. >=20 > 1. Existing solution mechanism(s) > ------------------------------ > It is said that even though we have no existing implementations of > m:n, there are existing solutions mechanisms that meet the > requirements. > I would like to have this verified if possible. >=20 > 2. Not an update of 5654 > --------------------- > This is probably correct, this document adds two new requirements, > but does in no way change RFC 5654. >=20 > --- RW > This is the text concerning updates of RFC in RFC2223 (it has recently be= en > obsoleted by RFC 7322, but text regarding the reasoning behind updates ha= s > basically vanished there as far as I can tell): >=20 > Updates >=20 > To be used as a reference from a new item that cannot be used > alone (i.e., one that supplements a previous document), to refer > to the previous document. The newer publication is a part that > will supplement or be added on to the existing document; e.g., an > addendum, or separate, extra information that is to be added to > the original document. >=20 > I think this makes this document an update as it contains an addendum > essentially. Or the other way round, if you read 5654, there is no way th= e > reader can tell there are more requirements. An update will make that cle= ar. > --- >=20 > 3. Document structure > ------------------ > IESG members has recently expressed opinions that we should not > publish small stand alone document with a small number of use cases > or requirements, thes should rather be kept with the working and > published as appendices to the solutions document. > I would like to hear comments on this. >=20 > --- RW > I can understand this and usually I would agree. But then, given the abov= e that > solution document would need to update RFC5654 and that would be strange, > having a solution document update a requirements document. It would mix > two things I believe should be separate. You unfortunately cannot restric= t an > update of an RFC to a section of a different RFC. >=20 > --- >=20 > 4. The document need to be liaised to ITU-T SG15 > --------------------------------------------- > I agree with this, normally we liaise wg consensus texts, and the > document could be liaised when the wglc closes. >=20 > --- RW >=20 > Yes, that should be done. >=20 > Best, >=20 > Rolf >=20 > --- >=20 > To hear the feedback on this I will keep the wglc open for another week > starting today. >=20 > /Loa > mpls wg co-chair >=20 > On 18/09/2016 18:39, Loa Andersson wrote: > > Working Group, > > > > This is to initiate a two week working group last call on > > draft-ietf-mpls-tp-mfp-use-case-and-requirements-02. > > > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > > > There were no IPR disclosures against this document. > > > > All the authors and contributors have stated on the working group > > mailing list that they are not aware of any IPRs that relates to this > > document. > > > > This working group last call ends Oct 2, 2016. > > > > > > /Loa > > for the MPLS wg chairs >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Oct 6 12:27:28 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A2D12966C; Thu, 6 Oct 2016 12:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLljFU8zzLw7; Thu, 6 Oct 2016 12:27:14 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 703CE129762; Thu, 6 Oct 2016 12:27:13 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id b201so68780663wmb.0; Thu, 06 Oct 2016 12:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=+j+jXepg38MunTo1BBMiwNaLCrdwHJRfYPBuyxL+j9k=; b=rBikWEiOGwmixJH1JRo4BeHSY4Uqf4Bu82i6V8vxK21+cBAVyMtXZLYcKRhqx3QmO6 2fLOzEcQ2o6tOX4p0xrk/uWmbTwUvd9k2sBUy8Ge+JYTjXPhGX4VJfEpR8Jr1awIEm2V n0zF6ZiJ8V/61/EGbq8uQlPP+8vhvI11syC2H4OnihX+hFGrog8XQwgWHArdxBoM7z7M S1n+V5EqgbgqdU8qxRrpBb42isV1j+9+9Rf9c2O+DzvyfTZay7thvl5nYhmQ+dz+EJAz SlJH1xCOhBO/FASkGLkxOcq4AV+Eij7qAmvzQAZuN+QdwuuLLWzOGZDk+9UcTB2Oz5A1 Eyrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=+j+jXepg38MunTo1BBMiwNaLCrdwHJRfYPBuyxL+j9k=; b=LzGNyk4PpL9oVrs3qOl/mBg38jVSkAh8wRJL8ubfpLaadaD5tjlzSrqRvZ+kjPDPFq 21pWeZpD0hThXdeLBqrN/hlmxdzfvQRDOkLAbPtTahOyzM2tJdBClmwVFhOFtmxs6pXW rS0rbA1MXK4lfAez/iNiMAZYjw28NflqHZWyvDhh+xsTkRLbKef/whQyrni9GqO2Oi6F CiAZicTwoBtVK/5btDr0a6E7+qa8o7rX3hbx8pNzrwsYq6lKGv9dEF8a1AH5lPXE/QyT XSna0x6SVNmZ8qGFDzlNZu2FvhIxHrTwmo7OqQmxokA9QOOLlch7SHnl7E2SZR+mVFwT rB2A== X-Gm-Message-State: AA6/9RkDRT1KusSBXmTlNWyui1MhYwoqkqPz4JDoGEdGV0UADfhCOqvOXBQVnDSdNli8KA== X-Received: by 10.194.116.225 with SMTP id jz1mr3333573wjb.224.1475782031529; Thu, 06 Oct 2016 12:27:11 -0700 (PDT) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id 142sm16566104wmh.12.2016.10.06.12.27.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Oct 2016 12:27:10 -0700 (PDT) References: <48E1A67CB9CA044EADFEAB87D814BFF64A883507@eusaamb107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF64A886D22@eusaamb107.ericsson.se> To: Eric Gray , "mpls@ietf.org" From: Huub van Helvoort Message-ID: <4d229ad5-d6c4-264a-9afc-8235c0f9e0d2@gmail.com> Date: Thu, 6 Oct 2016 21:27:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF64A886D22@eusaamb107.ericsson.se> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-mpls-tp-shared-ring-protection@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Working Group Last Call for draft-ietf-mpls-tp-shared-ring-protection-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 19:27:16 -0000
Hello Eric,

You wrote:
The below is my comments (as document shepherd) for the Working Group Last Call on 
this draft.

Comments:

I support progression of this document after addressing a number of issues.

As you may have noticed we, the editors/authors, have addressed your issues
and uploaded a new version of the draft (see below).

The main updates are:
-1- reduction of the number of authors to 5
-2- the referencing to RFC5654 has been improved
-3- the concern regarding the presence of different protection modes is
removed by including a statement that all nodes in the ring MUST be
provisioned in the same protection mode.
To detect possible misconfiguration two bits are used in the RPS PDU
that identify the protection switching mode which allows detection of
any mis-configuration during provisioning.

If you agree with these updates the document can be progressed.

Best regards, Huub.


-------- Forwarded Message --------
Subject: [mpls] I-D Action: draft-ietf-mpls-tp-shared-ring-protection-03.txt
Date: Sat, 01 Oct 2016 06:16:10 -0700
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: mpls@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : Shared-Ring protection (MSRP) mechanism for ring topology
        Authors         : Weiqiang Cheng
                          Lei Wang
                          Han Li
                          Huub van Helvoort
                          Jie Dong
	Filename        : draft-ietf-mpls-tp-shared-ring-protection-03.txt
	Pages           : 47
	Date            : 2016-10-01

Abstract:
   This document describes requirements, architecture and solutions for
   MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point-
   to-point (P2P) services.  The MSRP mechanism is described to meet the
   ring protection requirements as described in RFC 5654.  This document
   defines the Ring Protection Switch (RPS) Protocol that is used to
   coordinate the protection behavior of the nodes on MPLS ring.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-tp-shared-ring-protection-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-shared-ring-protection-03


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

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

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



-- 
================================================================
Always remember that you are unique...just like everyone else...
From nobody Thu Oct 6 12:48:56 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EDE1204D9; Thu, 6 Oct 2016 11:35:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: , , , , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147577891437.23856.18399358705756112916.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2016 11:35:14 -0700 Archived-At: X-Mailman-Approved-At: Thu, 06 Oct 2016 12:48:55 -0700 Cc: netmod@ietf.org, joelja@bogus.com, teas@ietf.org, kwatsen@juniper.net, itu-t-liaison@iab.org, ccamp@ietf.org, vbeeram@juniper.net, rbonica@juniper.net, chair@ietf.org, lime@ietf.org, mpls@ietf.org, Kam.Lam@nokia.com, bclaise@cisco.com Subject: [mpls] New Liaison Statement, "LS on Generic and Transport Technology Specific Management Information Models" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 18:35:14 -0000 Title: LS on Generic and Transport Technology Specific Management Information Models Submission Date: 2016-10-06 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1495/ From: "Hiroshi Ota" To: cpignata@cisco.com,rbonica@juniper.net,daniele.ceccarelli@ericsson.com,zhangfatai@huawei.com,bclaise@cisco.com,joelja@bogus.com,j.schoenwaelder@jacobs-university.de, tnadeau@lucidvision.com,n.leymann@telekom.de,loa@pi.nu,swallow.ietf@gmail.com Cc: joelja@bogus.com,db3546@att.com,mpls@ietf.org,bclaise@cisco.com,chair@ietf.org,ccamp@ietf.org,n.leymann@telekom.de,rbonica@juniper.net,Scott.Mansfield@Ericsson.com,zhangfatai@huawei.com,swallow.ietf@gmail.com,teas@ietf.org,jdrake@juniper.net,kwatsen@juniper.net,loa@pi.nu,aretana@cisco.com,daniele.ceccarelli@ericsson.com,vbeeram@juniper.net,netmod@ietf.org,akatlas@gmail.com,cpignata@cisco.com,lberger@labn.net,itu-t-liaison@iab.org,lime@ietf.org,akatlas@gmail.com,aretana@cisco.com,db3546@att.com,vbeeram@juniper.net,lberger@labn.net Response Contacts: Kam.Lam@nokia.com, scott.mansfield@ericsson.com Technical Contacts: Purpose: For information Body: At this SG15 plenary meeting, we have initiated the approval process of four information model Recommendations, namely -G.7711/Y.1702 “Generic protocol-neutral information model for transport resources” Revision -G.874.1 “Optical transport network (OTN): Protocol neutral management information model for the network element view” Revision -G.8052/Y.1346 “Protocol-neutral management information model for the Ethernet transport capable network element” Revision -New G.8152/Y.1375, “Protocol-neutral management information model for the MPLS-TP transport network element” The latest drafts of these documents are provided herewith for your information. Attachments: - TD617 R1/P - TD618 R1/P - TD619 R1/P - TD620 R1/P Attachments: TD617 R1/P https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-06-itu-t-sg-15-mpls-ops-rtg-ccamp-netmod-lime-teas-ls-on-generic-and-transport-technology-specific-management-information-models-attachment-1.docx TD618 R1/P https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-06-itu-t-sg-15-mpls-ops-rtg-ccamp-netmod-lime-teas-ls-on-generic-and-transport-technology-specific-management-information-models-attachment-2.docx TD619 R1/P https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-06-itu-t-sg-15-mpls-ops-rtg-ccamp-netmod-lime-teas-ls-on-generic-and-transport-technology-specific-management-information-models-attachment-3.docx TD620 R1/P https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-06-itu-t-sg-15-mpls-ops-rtg-ccamp-netmod-lime-teas-ls-on-generic-and-transport-technology-specific-management-information-models-attachment-4.docx From nobody Thu Oct 6 14:32:00 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08D0129795; Thu, 6 Oct 2016 14:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVi7a7Nz4N0Q; Thu, 6 Oct 2016 14:31:57 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09A712974C; Thu, 6 Oct 2016 14:31:56 -0700 (PDT) Received: from [192.168.1.3] (unknown [49.146.59.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B9C831802BA8; Thu, 6 Oct 2016 23:31:53 +0200 (CEST) To: huubatwork@gmail.com, Eric Gray , "mpls@ietf.org" References: <48E1A67CB9CA044EADFEAB87D814BFF64A883507@eusaamb107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF64A886D22@eusaamb107.ericsson.se> <4d229ad5-d6c4-264a-9afc-8235c0f9e0d2@gmail.com> From: Loa Andersson Message-ID: <36d0a520-8dd0-7876-da2d-d39d391a926a@pi.nu> Date: Fri, 7 Oct 2016 05:31:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4d229ad5-d6c4-264a-9afc-8235c0f9e0d2@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-mpls-tp-shared-ring-protection@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Working Group Last Call for draft-ietf-mpls-tp-shared-ring-protection-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 21:32:00 -0000 Eric, FWIW I've checked and my rather nitty comments has all been addressed. /Loa On 07/10/2016 03:27, Huub van Helvoort wrote: > Hello Eric, > > You wrote: >> The below is my comments (as document shepherd) for the Working Group Last Call on >> this draft. >> >> Comments: >> >> I support progression of this document after addressing a number of issues. > > As you may have noticed we, the editors/authors, have addressed your issues > and uploaded a new version of the draft (see below). > > The main updates are: > -1- reduction of the number of authors to 5 > -2- the referencing to RFC5654 has been improved > -3- the concern regarding the presence of different protection modes is > removed by including a statement that all nodes in the ring MUST be > provisioned in the same protection mode. > To detect possible misconfiguration two bits are used in the RPS PDU > that identify the protection switching mode which allows detection of > any mis-configuration during provisioning. > > If you agree with these updates the document can be progressed. > > Best regards, Huub. > > > -------- Forwarded Message -------- > Subject: [mpls] I-D Action: > draft-ietf-mpls-tp-shared-ring-protection-03.txt > Date: Sat, 01 Oct 2016 06:16:10 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: mpls@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching of the IETF. > > Title : Shared-Ring protection (MSRP) mechanism for ring topology > Authors : Weiqiang Cheng > Lei Wang > Han Li > Huub van Helvoort > Jie Dong > Filename : draft-ietf-mpls-tp-shared-ring-protection-03.txt > Pages : 47 > Date : 2016-10-01 > > Abstract: > This document describes requirements, architecture and solutions for > MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point- > to-point (P2P) services. The MSRP mechanism is described to meet the > ring protection requirements as described in RFC 5654. This document > defines the Ring Protection Switch (RPS) Protocol that is used to > coordinate the protection behavior of the nodes on MPLS ring. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mpls-tp-shared-ring-protection-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-shared-ring-protection-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > -- > ================================================================ > Always remember that you are unique...just like everyone else... > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Oct 6 15:07:59 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1F81297C7; Thu, 6 Oct 2016 15:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXfJDIVd9X7T; Thu, 6 Oct 2016 15:07:56 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C081297C5; Thu, 6 Oct 2016 15:07:55 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u96M7rnx028190; Thu, 6 Oct 2016 23:07:53 +0100 Received: from 950129200 (dsl-dp-81-140-96-139.in-addr.broadbandscope.com [81.140.96.139]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u96M7qOL028173 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 6 Oct 2016 23:07:52 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <06102f2d-8f1d-aac6-9d34-10a27d600bf8@pi.nu> In-Reply-To: Date: Thu, 6 Oct 2016 23:07:47 +0100 Message-ID: <06a901d2201e$12ce3fa0$386abee0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK0/R6o8szGqdVj3raAMHmGHFIAXQMmeXiKnr0HewA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22622.003 X-TM-AS-Result: No--11.792-10.0-31-10 X-imss-scan-details: No--11.792-10.0-31-10 X-TMASE-MatchedRID: HXSqh3WYKfstDLX17eHj6PHkpkyUphL9u2rcU2ygxCDYWrp179pohrsI asnPqvyQrJyq/fekmDBtGMMKNqG38lb0g0laGDcNxZQoGMRGhhPSL+EVfOJR08KU6ZmOGPnBBmu ncLfaVPc8yGHImE3RAOHOVX2NBpVf5IbHc8losXVoMLOoNHsM9hkqnRJng/51Blt4RZwvTdWLt7 XQF21r7dJlwYRUdC04j93XWqHveBLGUecy8W1eaolD2T5imTkJt+hhn8Iy6GWbKItl61J/ycnjL TA/UDoAxpQ77C1A1tqOhzOa6g8KrXarqnueDk7zvWrzvRngerUM2J3gYW/wYa7mvt/4aAgz+7gv 7Rkxc1c= Archived-At: Cc: mpls-chairs@ietf.org, draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 22:07:58 -0000 Hej Loa, > 1. Existing solution mechanism(s) > ------------------------------ > It is said that even though we have no existing implementations of > m:n, there are existing solutions mechanisms that meet the > requirements. > I would like to have this verified if possible. It all slightly depends on the precise intent of the document. I think it is talking about m:n end-to-end protection of LSPs. This is very distinct from m:n protection resource sharing within a network: a problem that requires quite a lot more coordination to solve well since the various head ends need to be updated about the protection status (a problem that does not exist in end-to-end protection). The text is a bit coy, referring to "protection entity" and "working entity." That may be intended to save some words, but it doesn't help us know exactly what problem is being solved. The only figure shows LSPs across a protection domain with end-to-end protection, so my assumption may be right. Now, given this, the requirements in the document are clear but do not seem (to me) to need more protocol work. Maybe there could be an applicability statement written (by people who want to ship or deploy this function) showing how the existing tools can do the job. Or maybe it is an exercise for the reader :-) A middle step might be to write protocol requirements (A needs to detect foo. A needs to tell Z bar. Etc.) so that it can be more easily seen which bits of protocol can be used to do the job. [BTW, the document doesn't distinguish between unidirectional and bidirectional LSPs and that, surely, changes the coordination that is needed.] Cheers, Adrian From nobody Fri Oct 7 00:43:35 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0766C12953D for ; Fri, 7 Oct 2016 00:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3M1l4EFzb5C for ; Fri, 7 Oct 2016 00:43:32 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233AD129539 for ; Fri, 7 Oct 2016 00:43:32 -0700 (PDT) Received: from [192.168.1.3] (unknown [49.146.59.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4B530180158A; Fri, 7 Oct 2016 09:43:28 +0200 (CEST) To: "mpls@ietf.org" , "mpls@ietf.org" , Deborah A Brungard From: Loa Andersson Message-ID: Date: Fri, 7 Oct 2016 15:43:23 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Implementation poll for draft-ietf-mpls-residence-time X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 07:43:34 -0000 Working Group, We are currently preparing on the Document Shepherd Write-Up for draft-ietf-mpls-residence-time. One question we have to answer in the Shepherd Write-Up is if we are aware of existing implementations or intentions to implement the specification. This is to start the Implementation Poll. If you have or are aware of existing implementations of or intentions to implement draft-ietf-mpls-residence-time please send this information to the working group mailing list or directly to the working group chairs. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Oct 7 08:28:25 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B037712966D; Fri, 7 Oct 2016 08:28:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Nicolai Leymann" , "Loa Andersson" , "George Swallow" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147585410267.8951.10341148746106651169.idtracker@ietfa.amsl.com> Date: Fri, 07 Oct 2016 08:28:22 -0700 Archived-At: Cc: Multiprotocol Label Switching Discussion List , itu-t-liaison@iab.org, jessy.rouyer@nokia.com, naotaka.morita@ntt-at.co.jp Subject: [mpls] New Liaison Statement, "LS - Initiation of the approval process for G.8101 revision, G.8113.1 and G.8121 series corrigenda" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 15:28:23 -0000 Title: LS - Initiation of the approval process for G.8101 revision, G.8113.1 and G.8121 series corrigenda Submission Date: 2016-10-07 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1496/ From: "Hiroshi Ota" To: Nicolai Leymann ,Loa Andersson ,George Swallow Cc: Alvaro Retana ,Deborah Brungard ,Multiprotocol Label Switching Discussion List ,Scott Mansfield ,George Swallow ,John Drake ,Alia Atlas ,Loa Andersson ,itu-t-liaison@iab.org,Nicolai Leymann , Response Contacts: naotaka.morita@ntt-at.co.jp, jessy.rouyer@nokia.com, alessandro.dalessandro@telecomitalia.it Technical Contacts: Purpose: For information Body: ITU-T SG15 wishes to inform the IETF MPLS WG that ITU-T SG15 has initiated at our September 2016 closing plenary meeting the final approval processes for the following documents: • Revision of Recommendation ITU-T G.8101 (2015) Terms and definitions for MPLS transport profile • Corrigendum 1 to Recommendation ITU-T G.8113.1/Y.1372.1 (2016) Operations, administration and maintenance mechanisms for MPLS-TP in packet transport networks • Corrigendum 1 to Recommendation ITU-T G.8121/Y.1381 (2016) Characteristics of MPLS-TP equipment functional blocks • Corrigendum 1 to Recommendation ITU-T G.8121.1/Y.1381.1 (2016) Characteristics of MPLS-TP equipment functional blocks supporting ITU-T G.8113.1/Y.1372.1 OAM mechanisms • Corrigendum 1 to Recommendation ITU-T G.8121.2/Y.1381.2 (2016) Characteristics of MPLS-TP equipment functional blocks supporting ITU-T G.8113.2/Y.1372.2 OAM mechanisms These corrigenda fix issues that were first identified in, or agreed to be addressed based on contributions to this meeting. The consented documents are attached. Attachments: TD621/P R1, TD674/P, TD677P, TD678/P and TD679/P. Attachments: oLS376 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-07-itu-t-sg-15-mpls-ls-initiation-of-the-approval-process-for-g8101-revision-g81131-and-g8121-series-corrigenda-attachment-1.pdf TD674/P https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-07-itu-t-sg-15-mpls-ls-initiation-of-the-approval-process-for-g8101-revision-g81131-and-g8121-series-corrigenda-attachment-2.pdf TD677P https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-07-itu-t-sg-15-mpls-ls-initiation-of-the-approval-process-for-g8101-revision-g81131-and-g8121-series-corrigenda-attachment-3.pdf TD678/P https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-07-itu-t-sg-15-mpls-ls-initiation-of-the-approval-process-for-g8101-revision-g81131-and-g8121-series-corrigenda-attachment-4.pdf TD679/P https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-07-itu-t-sg-15-mpls-ls-initiation-of-the-approval-process-for-g8101-revision-g81131-and-g8121-series-corrigenda-attachment-5.pdf From nobody Fri Oct 7 17:53:22 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1BD1295DD; Fri, 7 Oct 2016 17:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hovXqhpD9Wm; Fri, 7 Oct 2016 17:53:19 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 43C60129604; Fri, 7 Oct 2016 17:53:14 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id b201so70474600wmb.0; Fri, 07 Oct 2016 17:53:14 -0700 (PDT) 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; bh=Ba00RPDfJCJ/ddEcj/h2syhz2BpJlIYiQziwwIVoDhA=; b=J8Ok6RPMy0R4AOZ+snNDGGAIUylPgKpTiGkjYW4WhafJond6L4vZCJtHRGQDyTpnad JJlYTAm581XUyWWQtySvMRgVBDjhHMFEUyWcw93EN7HIsFPBfjl9dE3EWLSFBl5AGIxX b0CQxlojxAduXHaIK3zY2gXTvY47EDPey8R+5gBe22MlGdzvwlzAxPpo9kSOE1emTkeC U4f3o5pxXdPAdwUdc4JhbqI+LsULi1Q8XZVbImwgVl6bm3xRTq/6MUJhAmMirlPZXWl3 R4DPhnXf9tF0QXqmrIU0BxDWgK83O0SFLGI9+mLRn/S5meqAU7SqkJ+297NrEsp+ubXO oDxw== 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; bh=Ba00RPDfJCJ/ddEcj/h2syhz2BpJlIYiQziwwIVoDhA=; b=A6a8dqMY9F7WJNOs6XjjdXO8/pNVWovZUAzb9AZ1yPhjuLUUTkgK7K4uaOUflVWKEx LzjhKxy2VEuNUcVyFLOXe/iCQQM+j3Iqq4h4te0OYw2ICRzReQhMX9AiZ6R+FKl3WyGT amlCgrC8FKhWY6fALo+V8FyOQPRkmUMkTTR1NtgiLtmxZgwsAIIuMejS9tqA502urWBO 48I28t9giQum3s5Gt7kL8lh0PYvndzCcaloULaBIhimVMxtDZ0IkBykHOj6sYR6LeFOe VkP9FBZMl+YwftP+ugYEoCqWC3NuhN8zPMXvhsQ4sBdCaPhJp5ksQBtJ9XQPfZM6yROW 9msw== X-Gm-Message-State: AA6/9RkdZADJV7GHPptgK+2DGmBEIN7rCAWzTXbH+abJUJob/7P7dJZxkDeJbdariMNYV54tPY1JfT5998SqcA== X-Received: by 10.28.38.131 with SMTP id m125mr880042wmm.133.1475887992849; Fri, 07 Oct 2016 17:53:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.181.133 with HTTP; Fri, 7 Oct 2016 17:53:12 -0700 (PDT) From: Joan Cucchiara Date: Fri, 7 Oct 2016 20:53:12 -0400 Message-ID: To: Loa Andersson , mpls@ietf.org, draft-ietf-mpls-tp-linear-protection-mib@ietf.org, mpls-chairs@ietf.org, mib-doctors@ietf.org Content-Type: multipart/alternative; boundary=94eb2c03f04e8acd11053e4ff3bc Archived-At: Cc: Benoit Claise Subject: [mpls] MIB Dr. review of draft-ietf-tp-linear-mib-09 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 00:53:21 -0000 --94eb2c03f04e8acd11053e4ff3bc Content-Type: text/plain; charset=UTF-8 Authors, Thank you for addressing the comments so thoroughly, and especially for clarifying the example in section 7. Much appreciated. The MIB compiles with smilint and smicngPRO. Comments are below. Thank you, -Joan Comments: ---------------- 1) Section 6.1 Relationship to the MPLS OAM Maintenance Identifiers MIB Module "The mplsLpsMeConfigTable entry is extended by the entry in the mplsOamIdMeTable defined in [RFC7697]." The above statement is backwards....think the intention is to say something like: Entries in the mplsOamIdMeTable [RFC7697] are extended by entries in the mplsLspMeConfigTable. 2) later in this same section, section 6.1 "An entry of this table is related to a single entry in mplsOamIdMeTable." The above is confusing because you've already discuss the sparse augments relationship. Please remove the above sentence. MIB Module ------------ 3) mplsLpsConfigIndexNext - please rename to mplsLpsConfigDomainIndexNext. Since this scalar is only used for the mplsLpsConfigDomainIndex index's values, the name should reflect that. NOTE: this name change should be propagated elsewhere in the draft. Please do a search and replace. 4) mplsLpsConfigDomainIndex (editorial) "Managers should..." s/Managers/Operators/ 5) mplsLpsConfigCommand Why is there NO DEVAL? Wouldn't "noCmd" be an appropriate DEFVAL? 6) mplsLpsConfigRowStatus DESCRIPTION clause RowStatus objects reflect the status of the Row, not a determination of whether or not values are "appropriate". Please remove the last sentence of this DESCRIPTION: "...An entry may not exist in the active state unless all objects in the entry have an appropriate value." 7) mplsLpsConfigDomainIndex and mplsLpsMeConfigDomain Since MIBs often get stripped out of RFCs, the relationship between the mplsLpsConfigDomainIndex and the mplsLpsMeConfigDomain needs to be included in the MIB Module itself. Both DESCRIPTION clauses need to be updated to describe the relationship between these objects. Verbage such as "When the value of mplsLpsConfigDomainIndex is the same as the value of mplsLpsMeConfigDomain, that means..." and then explain what this means. 8) mplsLpsMeConfigDomain DESCRIPTION (editorial) "This object holds the value of protection domain index wherein this ME included in. s/included in/is included/ --- --94eb2c03f04e8acd11053e4ff3bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Authors,

Thank you for addressing the comments= so thoroughly, and especially for
clarifying the example in section 7.= =C2=A0=C2=A0=C2=A0 Much appreciated.

The MIB compiles with smi= lint and smicngPRO.=C2=A0=C2=A0 Comments are below.

Thank you,<= br>-Joan

Comments:
----------------

1) Section 6.1 Relatio= nship to the MPLS OAM Maintenance Identifiers MIB Module

=C2=A0=C2= =A0 "The mplsLpsMeConfigTable entry is extended by the entry in the=C2=A0=C2=A0 mplsOamIdMeTable defined in [RFC7697]."

The above= statement is backwards....think the intention is to say something like:Entries in the mplsOamIdMeTable [RFC7697] are extended by entries in the m= plsLspMeConfigTable.

2) later in this same section, section 6.1
<= br>=C2=A0=C2=A0 "An entry of this table is related to a single entry i= n mplsOamIdMeTable."

The above is confusing because you've = already discuss the sparse augments relationship.=C2=A0 Please remove
t= he above sentence.


MIB Module
------------
3)=C2=A0 mplsLp= sConfigIndexNext=C2=A0 -=C2=A0=C2=A0 please rename to mplsLpsConfigDomainIn= dexNext.
Since this scalar is only used for the mplsLpsConfigDomainIndex= index's values, the name should reflect that.
NOTE:=C2= =A0 this name change should be propagated elsewhere in the draft.=C2=A0 Ple= ase do a search and replace.

4) mplsLpsConfigDomainIndex= =C2=A0 (editorial)
=C2=A0 "Managers should..."

s/Manage= rs/Operators/


5) mplsLpsConfigCommand
Why is there NO DEVAL?= =C2=A0=C2=A0 Wouldn't "noCmd" be an appropriate DEFVAL?

6) mplsLpsConfigRowStatus DESCRIPTION clause

RowStatus objects= reflect the status of the Row, not a determination of whether or not value= s
are "appropriate".=C2=A0 Please remove the last sentence of = this DESCRIPTION:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &= quot;...An entry may not exist in the active state unless all
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 objects in the entry have an = appropriate value."


7)=C2=A0 mplsLpsConfigDomainIndex and m= plsLpsMeConfigDomain

Since MIBs often get stripped out of RFCs, the= relationship between the mplsLpsConfigDomainIndex and
the mplsLpsMeConf= igDomain needs to be included in the MIB Module itself.=C2=A0
=C2=A0Both DESCRIPTION clauses need to be updated to describe the relationship b= etween these objects.=C2=A0=C2=A0 Verbage such as "When the
value o= f mplsLpsConfigDomainIndex is the same as the value of mplsLpsMeConfigDomai= n, that means..." and then explain what
this means.
<= /div>

8)=C2=A0 mplsLpsMeConfigDomain DESCRIPTION (editorial)
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "This object holds the v= alue of protection domain index wherein
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 this ME included in.

s/included in/is incl= uded/

---


--94eb2c03f04e8acd11053e4ff3bc-- From nobody Mon Oct 10 05:57:09 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA6F129655; Mon, 10 Oct 2016 05:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR8bfPqXAr1P; Mon, 10 Oct 2016 05:57:02 -0700 (PDT) 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 73A26129654; Mon, 10 Oct 2016 05:57:01 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id BF1843B4DBD; Mon, 10 Oct 2016 14:56:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D533E4C066; Mon, 10 Oct 2016 14:56:58 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0319.002; Mon, 10 Oct 2016 14:56:58 +0200 From: To: "rtg-ads@ietf.org" , "draft-ietf-mpls-app-aware-tldp@tools.ietf.org" Thread-Topic: Routing directorate review of draft-ietf-mpls-app-aware-tldp Thread-Index: AdIi7dh8VGkZp01cSgGEMHttNglx1Q== Date: Mon, 10 Oct 2016 12:56:57 +0000 Message-ID: <2864_1476104219_57FB901B_2864_354_1_53C29892C857584299CBF5D05346208A0F9FC3B9@OPEXCLILM21.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F9FC3B9OPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: "mpls@ietf.org" , "rtg-dir@ietf.org" Subject: [mpls] Routing directorate review of draft-ietf-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 12:57:07 -0000 --_000_53C29892C857584299CBF5D05346208A0F9FC3B9OPEXCLILM21corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcj4NCg0KQWx0aG91Z2ggdGhlc2UgY29t bWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdv dWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkg b3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2 ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBk cmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbXBscy1hcHAtYXdhcmUtdGxkcC0wNS50eHQ8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW1wbHMtYXBwLWF3YXJlLXRsZHAt MDUudHh0Pg0KUmV2aWV3ZXI6IEJydW5vIERlY3JhZW5lDQpSZXZpZXcgRGF0ZTogMjAxNi8xMC8x MA0KSUVURiBMQyBFbmQgRGF0ZTogbm90IHN0YXJ0ZWQgKEFGQUlLKQ0KSW50ZW5kZWQgU3RhdHVz OiBQcm9wb3NlZCBTdGFuZGFyZA0KDQpTdW1tYXJ5Og0KSSBoYXZlIHNpZ25pZmljYW50IGNvbmNl cm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgYW5kIHJlY29tbWVuZCB0aGF0IHRoZSBSb3V0aW5nIEFE cyBkaXNjdXNzIHRoZXNlIGlzc3VlcyBmdXJ0aGVyIHdpdGggdGhlIGF1dGhvcnMuDQpDb21tZW50 czoNCkRyYWZ0IGlzIHdlbGwgcmVhZGFibGUuIEJ1dCBJIGZlZWwgdGhhdCBpdCBjb3VsZCBiZSBl dmVuIG1vcmUgcHJlY2lzZSBvbiBub3JtYXRpdmUgYmVoYXZpb3JzIChjZiBtaW5vciBjb21tZW50 cykuDQoNClByZWxpbWluYXJ5IGluZm86DQotIEknbSBub3QgYSBMRFAgZXhwZXJ0LiBVbmZvcnR1 bmF0ZWx5LCB0aGlzIG1heSBiZWNvbWUgYXBwYXJlbnQgaW4gdGhlIGJlbG93IGNvbW1lbnRzLiBT byB5b3UgYXJlIHdlbGNvbWUgdG8gZGlzYWdyZWUgYW5kIHByb3ZpZGUgdGhlIGluZm9ybWF0aW9u IGFuZCByZWFzb25pbmcgdGhhdCBJIG1heSBiZSBtaXNzaW5nLg0KLSBHaXZlbiB0aGF0IHRoZSBy ZXF1aXJlZCBJQU5BIGNvZGUgcG9pbnRzIGhhdmUgbm90IGJlZW4gcHJlLWFsbG9jYXRlZCwgSSBh bSBhc3N1bWluZyB0aGF0IG5vIGltcGxlbWVudGF0aW9uIG9mIHRoaXMgZG9jdW1lbnQgZXhpc3Rz LiBIZW5jZSBJJ20gbm90IHJlc3RyaWN0aW5nIG15IGNvbW1lbnRzIHRvIG1pbm9yIGNvbW1lbnRz Lg0KDQoNCk1ham9yIElzc3VlOg0KQWJzdHJhY3QgYW5kIFNoZXBoZXJkIFdyaXRlLVVwIGRlZmlu ZXMgdGhlIGdvYWwgb2YgdGhlIHNvbHV0aW9uIGFzIGFkdmVydGlzaW5nIHRoZSBwdXJwb3NlIGZv ciBzZW5kaW5nIHRoaXMgdExEUCBzZXNzaW9uIHJlcXVlc3QgdG8gdGhlIHRMRFAgcmVjZWl2ZXIs IHN1Y2ggdGhhdCB0aGUgcmVjZWl2ZXIgaGFzIGVub3VnaCBpbmZvcm1hdGlvbiB0byBkZWNpZGUg dG8gZWl0aGVyIGFjY2VwdCBvciBkZW55IGl0Lg0KSSBkb24ndCBmZWVsIHRoYXQgdGhlIHNvbHV0 aW9uIHBlcmZlY3RseSBtYXRjaGVzIHRoaXMgcHVycG9zZS4gRmlyc3QgdGhlIHNvbHV0aW9uIHJl cXVpcmVzIHRoYXQgYm90aCBlbmRzIG9mIHRoZSB0TERQIHNlc3Npb24gbmVnb3RpYXRlIHRoZSBf c2FtZV8gc2V0IG9mIGFwcGxpY2F0aW9ucy4gSSBkb24ndCBzZWUgd2h5IHRoaXMgaXMgbmVlZGVk IHRvIGFjaGlldmUgdGhlIGFib3ZlIGdvYWwuIFBsdXMgSSBmaW5kIHRoaXMgcHJvYmxlbWF0aWMg Zm9yIHNvbWUgYXBwbGljYXRpb25zIHdpdGggYXN5bW1ldHJpYyByZXF1aXJlbWVudHMgKGUuZy4g UkxGQSksIGluIHBhcnRpY3VsYXIgZm9yIGluY3JlbWVudGFsIGRlcGxveW1lbnQgb2YgZnV0dXJl IGFzeW1tZXRyaWMgYXBwbGljYXRpb24uIChtb3JlIGNvbW1lbnRzIG9uIHRoaXMgaW4gdGhlIG1p bm9yIGlzc3VlcykNCkluIGFkZGl0aW9uLCBJIGRvbid0IHNlZSBob3cgdGhlIGFkZGl0aW9uYWwg RkVDIGZpbHRlcmluZyBoZWxwcyBmdWxmaWxsaW5nIHRoaXMgZ29hbC4gSSBhbHNvIGZpbmQgaXQg cmVkdW5kYW50IHdpdGggUkZDIDc0NzMuIEkgYWxzbyBkb24ndCB0aGluayB0aGF0IHRoaXMgRkVD IGZpbHRlcmluZyBzaG91bGQgYmUgc3ltbWV0cmljYWwgKGUuZy4gUkxGQSBhcHBsaWNhdGlvbiku DQpJbiBzaG9ydCwgSSB3b3VsZCBoYXZlIG1hZGUgdGhlIFRBSSBhZHZlcnRpc2VtZW50IGFzeW1t ZXRyaWMsIGFuZCByZW1vdmVkIHRoZSBGRUMgZmlsdGVyaW5nLg0KDQpGaW5hbGx5LCBpZiB0aGUg Z29hbCBpcyB0byBhbGxvdyB0aGUgcmVjZWl2ZXIgdG8gbGltaXQgaW5jb21pbmcgdExEUCBzZXNz aW9ucywgcHJlc3VtYWJseSBmb3Igc2NhbGFiaWxpdHkgcHVycG9zZSwgaWYgb25lIGFwcGxpY2F0 aW9uIGlzIGFsbG93ZWQgYW5kIGhlbmNlIHRoZSB0TERQIHNlc3Npb24gaXMgc2V0IHVwLCB3aGF0 IHdvdWxkIGJlIHRoZSByZWFzb24gdG8gbGltaXQgdGhlIGFwcGxpY2F0aW9ucyBleGNoYW5nZWQg b3ZlciB0aGlzIHNlc3Npb24/IElPVywgd2h5IGxpbWl0aW5nIHRoZSBhcHBsaWNhdGlvbnMgdG8g dGhlIGludGVyc2VjdGlvbiBvZiBib3RoIGFkdmVydGlzZWQgYW5kIHJlY2VpdmVkIHNldCBvZiBh cHBsaWNhdGlvbj8gTm90ZSB0aGF0IMKnNS4zIGxpZ2h0bHkgcmVmZXJzIHRvIHRoaXMgcHJvYmxl bSwgYnV0IGluIGEgdmVyeSBhcHBsaWNhdGlvbiBzcGVjaWZpYyB3YXkgKGFuZCBub3QgcmVhbGx5 IG5vcm1hdGl2ZSksIHdoaWxlIHRoZSBjb25zZXF1ZW5jZXMgY291bGQgcHJvYmFibHkgYmUgbWFk ZSBnZW5lcmFsLiBFc3BlY2lhbGx5IGdpdmVuIHRoZSBwcmUtZXhpc3RlbmNlIG9mIFJGQyA3NDcz IHdoaWNoIGNhbiBiZSB1c2VkIHRvIGxpbWl0IHRoZSBGRUMgYWR2ZXJ0aXNlbWVudHMuDQoNCg0K TWlub3IgSXNzdWVzOg0Kwqc2ICJTZWN1cml0eSBjb25zaWRlcmF0aW9ucyINClRBQyBuZWdvdGlh dGlvbiBzZWVtcyB0byBhbGxvdyBhbiBlbnRpdHkgdG8gcmVtb3RlbHkgZGlzY292ZXIgdGhlIHRh cmdldGVkIExEUCBhcHBsaWNhdGlvbnMgcnVubmluZyBvbiBhIHJlbW90ZSBub2RlLiBUaGlzIGlz IGEgbmV3IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gd2hpY2ggc2hvdWxkIHByb2JhYmx5IGJlIGRp c2N1c3NlZC4NCg0KQWxzbywgZ2l2ZW4gdGhhdCBtdWx0aXBsZSBhcHBsaWNhdGlvbnMgbWFwcyB0 byB0aGUgc2FtZSBGRUMsIHR3byBwZWVycyBpbiBkaWZmZXJlbnQgQVNlcyBjb3VsZCB0cnkgdG8g Y2hlYXQsIGJ5IHN1Y2Nlc3NpdmVseSB0cnlpbmcgbXVsdGlwbGUgYXBwbGljYXRpb25zIG1hcHBp bmcgdG8gdGhlIHNhbWUgRkVDLiAoZS5nLiBpZiBJIHdhbnQgSVB2NCBGRUMgbWFwcGluZywgSSB3 b3VsZCB0cnkgd2l0aCAiTERQdjQgVHVubmVsaW5nIiwgdGhlbiAiTERQdjQgUmVtb3RlIExGQSIs IHRoZW4gIklQdjQgaW50cmEtYXJlYSBGRUNzIiwgdGhlbiBwb3NzaWJseSAiTERQIHNlc3Npb24g UHJvdGVjdGlvbiIpLiBUaGlzIGlzIGFsc28gbm90IGRpc2N1c3NlZC4NCi0tLS0NCg0Kwqc3ICJJ QU5BIENvbnNpZGVyYXRpb25zIg0KIjB4MDAwMSAtIDB4MUZGRiAgQXZhaWxhYmxlIGZvciBhc3Np Z25tZW50IGJ5IElFVEYgY29uc2Vuc3VzIg0KQWNjb3JkaW5nIHRvIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1MjI2I3NlY3Rpb24tNC4xICJJRVRGIFJldmlldyIgaXMgdGhlIG5ldyBu YW1lIGZvciAiSUVURiBjb25zZW5zdXMiDQoNCiIweDdGRkYgLSAweEZGRkUgIEF2YWlsYWJsZSBm b3IgdmVuZG9yIHNwZWNpZmljIHByaXZhdGUgdXNlIg0KDQotIFRoaXMgbG9vayBsaWtlIGEgdmVy eSBsYXJnZSByYW5nZSBmb3IgYSBwcml2YXRlIHVzZSAoaGFsZiBvZiB0aGUgcmVnaXN0cnkpDQot ICJ2ZW5kb3Igc3BlY2lmaWMgcHJpdmF0ZSB1c2UiIGlzIG5vdCBhIFdlbGwtS25vd24gSUFOQSBQ b2xpY3kgYXMgZGVmaW5lZCBpbiAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyMjYj c2VjdGlvbi00LjEgLiBJcyB0aGVyZSBhbnkgZGVmaW5pdGlvbiBvZiB0aGlzIFBvbGljeSBvciBz aG91bGQgeW91IGRlc2NyaWJlIGl0PyBIb3cgaXMgY29kZS1wb2ludCBjb2xsaXNpb24gc3VwcG9z ZWQgdG8gYmUgYXZvaWRlZCBpbiBkZXBsb3ltZW50cz8gKEknbSBndWVzc2luZyB0aGF0IHRoaXMg aXMgY29taW5nIGZyb20gUkZDIDUwMzYgSUFOQSBzZWN0aW9uLCBidXQgUkZDNTAzNiBzZWVtcyB0 byBoYXZlIGEgInZlbmRvci1JRCIgZmllbGQgdG8gZGlmZmVyZW50aWF0ZSB2ZW5kb3JzLCB3aGlj aCBpcyBub3QgdGhlIGNhc2Ugb2YgdGhpcyBkb2N1bWVudC4pDQpPbiBteSBzaWRlLCBJJ2QgcmF0 aGVyIHByb3Zpc2lvbiAyIHZlcnkgc21hbGwgcG9vbHMgZm9yIGV4cGVyaW1lbnRhbCBhbmQgcHJp dmF0ZS11c2UuIChpLmUuIHByaXZhdGUgdG8gdGhlIHVzZXIvIHRoZSBuZXR3b3JrIHByb3ZpZGVy LikNCg0KLS0tLQ0KDQrCpzEgIkludHJvZHVjdGlvbiINCiJBcHBsaWNhdGlvbnMgc3VjaCBhcyBS ZW1vdGUgTEZBIGFuZCBCR1AgYXV0byBkaXNjb3ZlcmVkIHBzZXVkb3dpcmUgYXV0b21hdGljYWxs eSBpbml0aWF0ZSBhc3ltbWV0cmljIGV4dGVuZGVkIGRpc2NvdmVyeSB0byBhbnkgTFNSIGluIGEg bmV0d29yayBiYXNlZCBvbiBsb2NhbCBzdGF0ZSBvbmx5LiINCkkgYWdyZWUgdGhhdCBSZW1vdGUg TEZBIGlzIGFzeW1tZXRyaWMuDQpJJ3ZlIG5vdCBiZWVuIGZvbGxvd2luZyB0aGUgd29yayBvbiBC R1AgYXV0by1kaXNjb3ZlcnksIGJ1dCBJIHdvdWxkIGhhdmUgYSBwcmlvcmkgYXNzdW1lZCB0aGF0 IGJvdGggdExEUCBlbmQgcG9pbnRzIGFyZSBydW5uaW5nIEJHUCBhdXRvZGlzY292ZXJ5IGFuZCBo ZW5jZSB0aGUgZGlzY292ZXJ5IGlzIHN5bW1ldHJpYy4NCi0tLS0NCg0KwqcyLjEgIkVuY29kaW5n Ig0KDQoiVGFyZ2V0ZWQgQXBwbGljYXRpb24gSWRlbnRpZmllciAoVEEtSWQpOiBhIDE2IGJpdCBU YXJnZXRlZCBBcHBsaWNhdGlvbiBJZGVudGlmaWVyIHZhbHVlLiINCkFjY29yZGluZyB0byB0aGUg ZmlndXJlIGp1c3QgYWJvdmUsIHRoZSBmaWVsZCBzZWVtcyB0byBvbmx5IGhhdmUgMTUgYml0cy4g KEFzIGJpdCAwIGlzIHVzZWQgZm9yIHRoZSBFLWJpdCkuIElmIHNvIHRoZSBJQU5BIHJlZ2lzdHJ5 IHdvdWxkIGFsc28gbmVlZCB0byBiZSBtb2RpZmllZC4gT3RoZXJ3aXNlLCB0aGUgZmlndXJlIG5l ZWRzIHRvIGJlIGZpeGVkLg0KDQotLS0tDQrCpzIuMiAiUHJvY2VkdXJlcyINCiJUaGUgVEFDIFRM VidzIENhcGFiaWxpdHkgZGF0YSBNVVNUIGNvbnNpc3RzIG9mIG5vbmUsIG9uZSBvciBtb3JlIFRB RSINCjpzL01VU1QvTUFZICAgPyAob3RoZXJ3aXNlLCBJdCdzIG5vdCBjbGVhciB0byBtZSB3aGF0 IGlzIHRoZSBtYW5kYXRlZCBiZWhhdmlvciBzaW5jZSBhbGwgcG9zc2libGUgYmVoYXZpb3JzIHNl ZW1zIGFsbG93ZWQpDQoNCi0tLS0NCsKnMQ0KDQoiRm9yIGFuIGFwcGxpY2F0aW9uIHN1Y2ggYXMg RkVDIDEyOA0KICAgcHNldWRvd2lyZSwgdGhlIHJlbW90ZSBMU1IgaXMgY29uZmlndXJlZCB3aXRo IHRoZSBzb3VyY2UgTFNSIGFkZHJlc3MNCiAgIHNvIHRoYXQgaXQgY2FuIHVzZSB0aGF0IGluZm9y bWF0aW9uIHRvIGFjY2VwdCBvciBpZ25vcmUgZ2l2ZW4gdExEUA0KICAgSGVsbG8uDQoNCiAgIEFw cGxpY2F0aW9ucyBzdWNoIGFzIFJlbW90ZSBMRkEgYW5kIEJHUCBhdXRvIGRpc2NvdmVyZWQgcHNl dWRvd2lyZQ0KICAgYXV0b21hdGljYWxseSBpbml0aWF0ZSBhc3ltbWV0cmljIGV4dGVuZGVkIGRp c2NvdmVyeSB0byBhbnkgTFNSIGluIGENCiAgIG5ldHdvcmsgYmFzZWQgb24gbG9jYWwgc3RhdGUg b25seS4gV2l0aCB0aGVzZSBhcHBsaWNhdGlvbnMsIHRoZQ0KICAgcmVtb3RlIExTUiBpcyBub3Qg ZXhwbGljaXRseSBjb25maWd1cmVkIHdpdGggdGhlIHNvdXJjZSBMU1IgYWRkcmVzcy4NCiAgIFNv IHRoZSByZW1vdGUgTFNSIGVpdGhlciByZXNwb25kcyBvciBpZ25vcmVzIGFsbCB0TERQIEhlbGxv cy4iDQoNCiBUaGUgaW50cm9kdWN0aW9uIHNlZW1zIHRvIGltcGx5IHRoYXQgdGhpcyBkb2N1bWVu dCB3b3VsZCBnaXZlIGEgcmVtb3RlIHBlZXIgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBpbiBvcmRl ciB0byBhY2NlcHQgb3IgaWdub3JlIHRMRFAgaGVsbG8uDQpNeSBsaW1pdGVkIHVuZGVyc3RhbmRp bmcgb2YgTERQIGNhcGFiaWxpdHkgaXMgdGhhdCB0aGV5IGFyZSBleGNoYW5nZWQgIGluIEluaXRp YWxpemF0aW9uIGFuZCBDYXBhYmlsaXR5IG1lc3NhZ2VzLCBpLmUuIG5vdCBpbiBIZWxsbyBtZXNz YWdlLg0KSGVuY2UgaXQncyBub3QgY2xlYXIgdG8gbWUgaG93IHRoaXMgZG9jdW1lbnQgaGVscHMg dGhlIHJlbW90ZSBMRFAgc3BlYWtlciBpbiBkZWNpZGluZyB0byBhY2NlcHQgb3IgaWdub3JlIHRM RFAgaGVsbG8uDQotLS0tDQrCpzIuMg0KIiAgIElmIHRoZXJlIGlzIGF0IGxlYXN0IG9uZSBUQUUg Y29tbW9uIGJldHdlZW4gdGhlIFRBQyBUTFYgaXQgaGFzDQogICByZWNlaXZlZCBhbmQgaXRzIG93 biwgdGhlIHNlc3Npb24gTVVTVCBwcm9jZWVkIHRvIGVzdGFibGlzaG1lbnQgYXMNCiAgIHBlciBb UkZDNTAzNl0uIg0KDQpJJ20gbm90IHN1cmUgdGhpcyBpcyDigJxhcyBwZXIgW1JGQzUwMzZd4oCd IHNpbmNlIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhZGRpdGlvbmFsIHJ1bGVzIHRvIGRlZmluZSB3 aGljaCBGRUMgbWFwcGluZyBuZWVkcyB0byBiZSBhZHZlcnRpc2VkLCBhbmQgd2hldGhlciBvciBu b3QgdG8gYWNjZXB0IHRoZSBzZXNzaW9uLg0KDQotLS0NCsKnMi4yDQoiVGhlIFRBQyBUTFYncyBD YXBhYmlsaXR5IGRhdGEgTVVTVCBjb25zaXN0cyBvZiBub25lLCBvbmUgb3IgbW9yZSBUQUUiDQpJ dCdzIG5vdCBjbGVhciB0byBtZSB3aGF0IGlzIHRoZSB1c2UgY2FzZSB0byBhZHZlcnRpc2Ugbm9u ZSBUQUUsIGdpdmVuIHRoYXQgaW4gdGhpcyBjYXNlLCB0aGUgaW50ZXJzZWN0aW9uIG9mIHRoZSBy ZWNlaXZlZCBhbmQgc2VudCBUQS1JZCB3aWxsIGJlIG51bGwgYW5kIGhlbmNlIHRoZSB0TERQIHNl c3Npb24gd2lsbCBiZSBjbG9zZWQgYnkgYW55IG9mIHRoZSB0TERQIHNwZWFrZXJzLg0KDQotLS0N CsKnMi4yDQoiSWYgdGhlIHJlY2VpdmVyIExTUiByZWNlaXZlcyBhbiB1bmtub3duIFRBLUlkIGlu IHRoZSBUQUUsIGl0IE1VU1Qgc2lsZW50bHkgaWdub3JlIHN1Y2ggYSBUQUUgYW5kIGNvbnRpbnVl IHByb2Nlc3NpbmcgdGhlIHJlc3Qgb2YgdGhlIFRMVi4iDQpBc3N1bWluZyB0aGUgcmVjZWl2ZXIg KG5vZGUgQSkgc3VwcG9ydHMgTm9uIFN0b3AgUm91dGluZyBhbmQgaXMgdXBncmFkZWQgdG8gc3Vw cG9ydCBhIG5ldyBUQS1JZCBzaG91bGQgaXQgY2hlY2sgZm9yIHRoZSBwcmV2aW91c2x5IHJlY2Vp dmVkIFRBRSB0aGF0IGl0IGhhcyBzaWxlbnRseSBpZ25vcmVkIG9yIGRvZXMgdGhlIHNwZWFrZXIg KG5vZGUgQikgc3VwcG9zZWQgdG8gcmUtc2VuZCBhbGwgaXQncyBUQS1JRCBpZiBpdCByZWNlaXZl IG5ldyBUQS1JZCBmcm9tIG5vZGUgQT8gTXkgcmVhZGluZyBvZiB0aGUgZW5kIG9mIHNlY3Rpb24g Mi4yIGlzIHRoYXQgaW4gdGhpcyBjYXNlIHRoZSByZWNlaXZlciBtdXN0IGNoZWNrZWQgZnJvbSBw cmV2aW91c2x5IHJlY2VpdmVkIFRBRS4NCk1heSBiZSA6cy9yZWNlaXZlcy9yZWNlaXZlZCAgd291 bGQgYmUgZW5vdWdoIHRvIGFkZHJlc3MgdGhpcyBjYXNlLiBPciBwcmVmZXJhYmx5IGFkZGluZyBh IHNlbnRlbmNlLg0KDQotLS0NCsKnMi4yDQoiSW4gdGhlIGxhc3QgaW5zdGFuY2UsIHN1cHBvc2Ug dGhlDQogICBpbml0aWF0aW5nIExTUiBhZHZlcnRpc2VzIEEsIEIgYW5kIEMgYXMgYSBUQS1JZHMg YW5kIHRoZSByZXNwb25kaW5nDQogICBMU1IgYWR2ZXJ0aXNlcyBEIGFuZCBFIGFzIFRBLUlkcywg dGhhbiB0aGUgbmVnb3RpYXRlZCB0YXJnZXRlZA0KICAgYXBwbGNpYXRpb25zIGFzIHBlciBib3Ro IHRoZSBMU1JzIGFyZSBub25lLiBUaGUgUmVzcG9uZGluZyBMU1Igc2VuZHMNCiAgICdTZXNzaW9u IFJlamVjdGVkL1RhcmdldGVkIEFwcGxpY2F0aW9uIENhcGFiaWxpdHkgTWlzLU1hdGNoJw0KICAg Tm90aWZpY2F0aW9uIG1lc3NhZ2UgdG8gdGhlIGluaXRpYXRpbmcgTFNSIGFuZCBtYXkgY2xvc2Ug dGhlDQogICBzZXNzaW9uLiINCg0KSSdkIHByZWZlciBoYXZpbmcgbm9ybWF0aXZlIHRleHQgc3Rh dGluZyB0aGUgcmVxdWlyZWQgYmVoYXZpb3IgcmF0aGVyIHRoYW4gaGF2aW5nIGFuIGV4YW1wbGUu DQppLmUuIEknbSBsb29raW5nIGZvciBhIHRleHQgc2ltaWxhciB0byAiSWYgdGhlIGludGVyc2Vj dGlvbiBvZiB0aGUgc2V0cyBvZiByZWNlaXZlZCBhbmQgc2VudCBUQS1JZCBpcyBudWxsLCB0aGVu IExTUiBNVVNUIHNlbmRzICdTZXNzaW9uIFJlamVjdGVkL1RhcmdldGVkIEFwcGxpY2F0aW9uIENh cGFiaWxpdHkgTWlzLU1hdGNoJw0KICAgTm90aWZpY2F0aW9uIG1lc3NhZ2UgdG8gdGhlIGluaXRp YXRpbmcgTFNSIGFuZCBjbG9zZSB0aGUgc2Vzc2lvbi4iDQoNCiAgIG9yIDpzL01VU1QvU0hPVUxE IG9yIDpzL01VU1QvTUFZICAgYXMgeW91IHdpc2gNCg0KLS0tDQrCpzIuMg0KIklmIGl0IHNldHMg dGhlIHNlc3Npb24gc2V0dXAgcmV0cnkgaW50ZXJ2YWwgdG8gbWF4aW11bSwgdGhlIHNlc3Npb24g TUFZIHN0YXkgaW4gYSBub24tZXhpc3RlbnQgc3RhdGUuIg0KDQpJZiB0aGlzIHJlZmVycyB0byB0 aGUgTERQIEZTTSwgUkZDIDUwMzYgdXNlZCB0aGUgdGVybSAiTk9OIEVYSVNURU5UIiByYXRoZXIg dGhhbiAibm9uLWV4aXN0ZW50Ig0KLS0tDQrCpzIuMQ0KVGhpcyBzZWN0aW9uIG1peGVzIGNvcHkg b2YgcHJldmlvdXMgc3BlY2lmaWNhdGlvbnMgKGUuZy4gUkZDIDU1NjEpIHdpdGggdGhlIG5ldyBz cGVjaWZpY2F0aW9uLiBQZXJzb25hbGx5LCBJJ2QgcHJlZmVyIHRoYXQgdGhlIGRvY3VtZW50IGJl IGNsZWFyIG9uIHRoZSBwYXJ0IHdoaWNoIGFyZSByZXVzZWQgdW5jaGFuZ2VkIGFuZCB0aGUgcGFy dCB3aGljaCBhcmUgbmV3IHNwZWNpZmljYXRpb24uIEluIGdlbmVyYWwsIEkgcGVyc29uYWxseSBk b24ndCB0aGluayB0aGF0ICB0aGlzIGlzIGEgZ29vZCBwcmFjdGljZSwgYXMgaXQgYmVjb21lcyB1 bmNsZWFyIHdoaWNoIGRvY3VtZW50IGlzIHRoZSBub3JtYXRpdmUgZGVmaW5pdGlvbi4gQW5kIGlu IHBhcnRpY3VsYXIgaW4gdGhpcyBkb2N1bWVudCwgdGhlcmUgaXMgYSBjb3B5L3Bhc3RlIGVycm9y IGR1cmluZyB0aGUgY29weSBmcm9tIFJGQyA1NTYxLCBzbyBpdCBteSBiZSB1bmNsZWFyIGlmIHRo ZSBnb2FsIGlzIHRvIHJlZGVmaW5lIFJGQyA1NTYxIG9yIG5vdC4gKCJUeXAiIGZpZWxkIGhhcyBi ZWVuIGluY3JlYXNlZCBieSAxIGJpdCBhbmQgdGhlICJMZW5ndGgiIGhhcyBiZWVuIGRlY3JlYXNl ZCBieSAxIGJpdCkNCg0KSSB3b3VsZCBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgY2hhbmdlOg0KDQpP TEQ6DQoNCiAgIEFuIExTUiBNQVkgYWR2ZXJ0aXNlIHRoYXQgaXQgaXMgY2FwYWJsZSB0byBuZWdv dGlhdGUgYSB0YXJnZXRlZCBMRFANCiAgIGFwcGxpY2F0aW9uIGxpc3Qgb3ZlciBhIHRMRFAgc2Vz c2lvbiBieSB1c2luZyB0aGUgQ2FwYWJpbGl0eQ0KICAgQWR2ZXJ0aXNlbWVudCBhcyBkZWZpbmVk IGluIFtSRkM1NTYxXS4NCg0KICAgQSBuZXcgb3B0aW9uYWwgY2FwYWJpbGl0eSBUTFYgaXMgZGVm aW5lZCwgJ1RhcmdldGVkIEFwcGxpY2F0aW9uDQogICBDYXBhYmlsaXR5IChUQUMpJy4gSXRzIGVu Y29kaW5nIGlzIGFzIGZvbGxvd3M6DQoNCiAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAg ICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB8VXxGfCBUYXJnZXRlZCBBcHAuIENhcC4oSUFOQSl8ICAgICAgICAgICAg IExlbmd0aCAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8U3wgIFJlc2VydmVk ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg ICArLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICB+ICAgICAgICAgICAgICAgICBUYXJnZXRl ZCBBcHAuIENhcC4gZGF0YSAgICAgICAgICAgICAgICAgICAgICAgfg0KICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQogICAgIEFzIGRlc2NyaWJlZCBpbiBbUkZDNTU2MV0NCiAgICAgVTog c2V0IHRvIDEuIElnbm9yZSwgaWYgbm90IGtub3duLg0KICAgICBGOiBTZXQgdG8gMC4gRG8gbm90 IGZvcndhcmQuDQogICAgIFM6IE1VU1QgYmUgc2V0IHRvIDEgb3IgMCB0byBhZHZlcnRpc2Ugb3Ig d2l0aGRyYXcgdGhlIFRBQyBUTFYNCiAgICAgICAgcmVzcGVjdGl2ZWx5Lg0KDQogICAgIFRhcmdl dGVkIEFwcGxpY2F0aW9uIENhcGFiaWxpdHkgZGF0YToNCiAgICAgICBBIFRhcmdldGVkIEFwcGxp Y2F0aW9ucyBDYXBhYmlsaXR5IGRhdGEgY29uc2lzdHMgb2Ygbm9uZSwgb25lDQogICAgICAgb3Ig bW9yZSAzMiBiaXQgVGFyZ2V0ZWQgQXBwbGljYXRpb24gRWxlbWVudHMuIEl0cyBlbmNvZGluZyBp cw0KICAgICAgIGFzIGZvbGxvd3M6DQoNCiAgICAgICBUYXJnZXRlZCBBcHBsaWNhdGlvbiBFbGVt ZW50KFRBRSkNCg0KICAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAg ICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KDQogICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgICAgICB8RXwgICAgVGFyZy4gQXBwbC4gSWQgICAgICAgICAgIHwgICAgICAgUmVzZXJ2 ZWQgICAgICAgICAgICAgICAgfA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgICBUYXJnZXRlZCBB cHBsaWNhdGlvbiBJZGVudGlmaWVyIChUQS1JZCk6DQogICAgICAgYSAxNiBiaXQgVGFyZ2V0ZWQg QXBwbGljYXRpb24gSWRlbnRpZmllciB2YWx1ZS4NCg0KICAgICAgIEUtYml0OiBUaGUgZW5hYmxl IGJpdCBpbmRpY2F0ZXMgd2hldGhlciB0aGUgc2VuZGVyIGlzDQogICAgICAgYWR2ZXJ0aXNpbmcg b3Igd2l0aGRyYXdpbmcgdGhlIFRBRS4gVGhlIEUtYml0IHZhbHVlIGlzIHVzZWQgYXMNCiAgICAg ICBmb2xsb3dzOg0KDQogICAgICAgICAxIC0gVGhlIFRBRSBpcyBhZHZlcnRpc2luZyB0aGUgdGFy Z2V0ZWQgYXBwbGljYXRpb24uDQogICAgICAgICAwIC0gVGhlIFRBRSBpcyB3aXRoZHJhd2luZyB0 aGUgdGFyZ2V0ZWQgYXBwbGljYXRpb24uDQoNCiAgICAgVGhlIGxlbmd0aCBvZiBUQUMgZGVwZW5k cyBvbiB0aGUgbnVtYmVyIG9mIFRBRXMuIEZvciBpbnN0YW5jZSwNCiAgICAgaWYgdHdvIFRBRXMg YXJlIGFkZGVkLCB0aGUgbGVuZ3RoIGlzIHNldCB0byA5Lg0KDQpORVcNCg0KICAgQW4gTFNSIE1B WSBhZHZlcnRpc2UgdGhhdCBpdCBpcyBjYXBhYmxlIHRvIG5lZ290aWF0ZSBhIHRhcmdldGVkIExE UA0KICAgYXBwbGljYXRpb24gbGlzdCBvdmVyIGEgdExEUCBzZXNzaW9uIGJ5IHVzaW5nIHRoZSBD YXBhYmlsaXR5DQogICBBZHZlcnRpc2VtZW50IGFzIGRlZmluZWQgaW4gW1JGQzU1NjFdIGFuZCBl bmNvZGVkIGFzIGZvbGxvd3M6DQoNCiAgICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAg ICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgICAgIHxVfEZ8IFRMViBDb2RlIFBvaW50ICAgICAgICAgICAgfCAgICAgICAg ICAgIExlbmd0aCAgICAgICAgICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfFN8IFJlc2Vy dmVkICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICstKy0rLSstKy0rLSstKy0rICAgICAgIENhcGFiaWxpdHkgRGF0YSAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCiAgICAgICAgICAgICAgICBUaGlz IGRvY3VtZW50IGRlZmluZXMgYSBuZXcgb3B0aW9uYWwgY2FwYWJpbGl0eSBUTFYgb2YgdHlwZSBU QkQxIGNhbGxlZCAnVGFyZ2V0ZWQgQXBwbGljYXRpb24NCiAgIENhcGFiaWxpdHkgKFRBQyknLg0K ICAgRmxhZyAiVSIgTVVTVCBiZSBzZXQgdG8gMSB0byBpbmRpY2F0ZSB0aGF0IHRoaXMgY2FwYWJp bGl0eSBtdXN0IGJlIHNpbGVudGx5IGlnbm9yZWQgaWYgdW5rbm93bi4NCg0KICAgSXQncyBlbmNv ZGVkIGFzIGZvbGxvd3M6DQoNCiAgICAgICBUYXJnZXRlZCBBcHBsaWNhdGlvbiBFbGVtZW50KFRB RSkNCg0KICAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAg ICAgICAgICAgICAgICAgICAzDQogICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAg ICAgfEV8ICAgIFRhcmcuIEFwcGwuIElkICAgICAgICAgICB8ICAgICAgIFJlc2VydmVkICAgICAg ICAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCiAgICAgICAgICBUYXJnZXRlZCBBcHBs aWNhdGlvbiBJZGVudGlmaWVyIChUQS1JZCk6DQogICAgICAgYSAxNiBiaXQgVGFyZ2V0ZWQgQXBw bGljYXRpb24gSWRlbnRpZmllciB2YWx1ZS4NCg0KICAgICAgIEUtYml0OiBUaGUgZW5hYmxlIGJp dCBpbmRpY2F0ZXMgd2hldGhlciB0aGUgc2VuZGVyIGlzDQogICAgICAgYWR2ZXJ0aXNpbmcgb3Ig d2l0aGRyYXdpbmcgdGhlIFRBRS4gVGhlIEUtYml0IHZhbHVlIGlzIHVzZWQgYXMNCiAgICAgICBm b2xsb3dzOg0KDQogICAgICAgICAxIC0gVGhlIFRBRSBpcyBhZHZlcnRpc2luZyB0aGUgdGFyZ2V0 ZWQgYXBwbGljYXRpb24uDQogICAgICAgICAwIC0gVGhlIFRBRSBpcyB3aXRoZHJhd2luZyB0aGUg dGFyZ2V0ZWQgYXBwbGljYXRpb24uDQoNCg0KLS0tDQrCpzIuMg0KIklmIHRoZSB0TERQIHNlc3Np b24gY2hhbmdlcyB0byBsaW5rIHNlc3Npb24sIGEgTFNSIHNob3VsZCB3aXRoZHJhdyBpdCIuLi4N CjpzL3Nob3VsZC9TSE9VTEQNCg0KLi4uIndpdGggUyBiaXQgc2V0IHRvIDAsIHdoaWNoIGluZGlj YXRlcyB3aWxkY2FyZCB3aXRoZHJhd2FsIG9mIGFsbCBUQUUgZWxlbWVudHMuIg0KV2hlcmUgaXMg dGhpcyBiZWhhdmlvciBkZWZpbmVkPw0KTXkgcmVhZGluZyBvZiBSRkM1MDM2IGlzIHRoYXQgc2Vu ZGluZyB0aGUgY2FwYWJpbGl0eSB3aXRoIHRoZSBTIGJpdCBzZXQgdG8gMCBtZWFucyB3aXRoZHJh d2luZyB0aGUgY2FwYWJpbGl0eS4gSW4gd2hpY2ggY2FzZSB0aGlzIGRvY3VtZW50cyBzdGF0ZXMg dGhhdCAiSWYgdGhlIHJlY2VpdmVyIExTUiBkb2VzIG5vdCByZWNlaXZlIHRoZSBUQUMgVExWIGlu IHRoZQ0KICAgSW5pdGlhbGl6YXRpb24gbWVzc2FnZSBvciBpdCBkb2VzIG5vdCB1bmRlcnN0YW5k IHRoZSBUQUMgVExWLCB0aGUgVEFDIG5lZ290aWF0aW9uIE1VU1QgYmUgY29uc2lkZXJlZCB1bnN1 Y2Nlc3NmdWwgYW5kIHRoZSBzZXNzaW9uIGVzdGFibGlzaG1lbnQgTVVTVCBwcm9jZWVkIGFzIHBl ciBbUkZDNTAzNl0uIiBpLmUuIHRoZSB0TERQIHNlc3Npb25zIHN0YXlzIHVwLg0KVGhpcyBpcyBu b3QgdGhlIHNhbWUgYXMgIndpbGRjYXJkIHdpdGhkcmF3YWwgb2YgYWxsIFRBRSBlbGVtZW50cyIg d2hpY2ggbWVhbnMgdGhhdCB0aGUgVEFDIGNhcGFiaWxpdHkgaXMgYWR2ZXJ0aXNlZCB3aXRoIG5v IFRBLUlkLCBpdCB0aGUgdExEUCBzZXNzaW9ucyB3aWxsIGJlIGNsb3NlZC4NCg0KLS0NCsKnMi4y DQoNCk9MRDoNCiAgICJBbHNvLCBjdXJyZW50bHkgdGhlIHJlbW90ZSBMU1IgYWNjZXB0cyBhc3lt bWV0cmljIGV4dGVuZGVkIEhlbGxvcyBieQ0KICAgZGVmYXVsdCBvciBieSBhcHByb3ByaWF0ZSBj b25maWd1cmF0aW9uLiBXaXRoIHRoaXMgZG9jdW1lbnQsIHRoZSBMU1INCiAgIE1VU1QgYWNjZXB0 IHRMRFAgaGVsbG9zIGluIG9yZGVyIHRvIHRoZW4gYWNjZXB0IG9yIHJlamVjdCB0aGUgdExEUA0K ICAgc2Vzc2lvbiBiYXNlZCBvbiB0aGUgYXBwbGljYXRpb24gaW5mb3JtYXRpb24uIg0KDQpXaGF0 IGlzIHRoZSBnb2FsIG9mIHRoaXMgcGFyYWdyYXBoPyBJJ20gcmVhZGluZyB0aGF0IGEgTFNSIG1h eSBub3QgYmUgY29uZmlndXJlZCBhbnltb3JlIHRvIHJlamVjdCB0TERQIGhlbGxvcy4gV2h5IG5v dD8NCkkgd291bGQgcHJvcG9zZQ0KTkVXDQoiQnkgZGVmYXVsdCwgTFNSIFNIT1VMRCBhY2NlcHQg dExEUCBoZWxsb3MgaW4gb3JkZXIgdG8gdGhlbiBhY2NlcHQgb3IgcmVqZWN0IHRoZSB0TERQDQog ICBzZXNzaW9uIGJhc2VkIG9uIHRoZSBhcHBsaWNhdGlvbiBpbmZvcm1hdGlvbi4iDQoNCi0tLQ0K ICAgwqcyLjMuMQ0KIiAgICAxLiBUaGUgUy1iaXQgb2YgdGhlIFRhcmdldGVkIEFwcGxpY2F0aW9u IENhcGFiaWxpdHkgVExWIE1VU1QgYmUNCiAgICAgc2V0IHRvIDEgdG8gYWR2ZXJ0aXNlIFRhcmdl dGVkIEFwcGxpY2F0aW9uIENhcGFiaWxpdHkgYW5kDQogICAgIFNIT1VMRCBiZSBpZ25vcmVkIG9u IHRoZSByZWNlaXB0LiINCg0KDQpUaGlzIGJlaGF2aW9yIGlzIGRlZmluZWQgaW4gUkZDIDU1NjEu IEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCdzIGdvb2QgcHJhY3RpY2UgdG8gcmVkZWZpbmUgaXQuICBJ J2QgcmF0aGVyIGhhdmUgdGhpcyBzZW50ZW5jZSBkZWxldGVkLiBBbHRlcm5hdGl2ZWx5LCBpdCBz aG91bGQgYmUgbWFkZSBub24gbm9ybWF0aXZlIGFuZCByZWZlciB0byBSRkMgNTU2MS4NCi0tLQ0K wqcyLjMuMQ0KIiAyLiBUaGUgRS1iaXQgb2YgdGhlIFRhcmdldGVkIEFwcGxpY2F0aW9uIEVsZW1l bnQgTVVTVCBiZSBzZXQgdG8gMSB0bw0KICAgICBlbmFibGUgVGFyZ2V0ZWQgYXBwbGljYXRpb24g YW5kIFNIT1VMRCBiZSBpZ25vcmVkIG9uIHRoZSByZWNlaXB0LiAgICAgICAgICAgICAgICINCg0K SSB1bmRlcnN0YW5kIHRoYXQgeW91IGFyZSBtaW1pY2tpbmcgdGhlIGJlaGF2aW9yIG9mIHRoZSBT LWJpdC4gSXQgbG9va3MgZGViYXRhYmxlIHRvIGlnbm9yZSB0aGlzIGRpcmVjdCBwcm90b2NvbCB2 aW9sYXRpb24gYW5kIGFjY2VwdCB0aGUgVEFFIHdoaWxlIHRoZSBzcGVha2VyIGV4cHJlc3NlZCBp dHMgd2lsbGluZXNzIHRvIHdpdGhkcmF3IGl0LiBJIHdvdWxkIHBlcnNvbm5hbHkgYmUgZW5jbGlu ZWQgdG8gaWdub3JlIHRoZSBUQUUgYWR2ZXJ0aXNlIHdpdGggdGhlIEUtYml0IGNsZWFyZWQuDQoN Ci0tLQ0KwqcyLjMuMg0KIiAgICAgSWYgdGhlIFMtYml0IGlzIHNldCB0byAwLCB0aGUgVEFDIGlz IGRpc2FibGVkIGZvciB0aGUgc2Vzc2lvbi4NCiAgICAgQWZ0ZXIgdGhhdCwgdGhlIHNlc3Npb24g bWF5IHJlbWFpbiBpbiBlc3RhYmxpc2hlZCBzdGF0ZSBvcg0KICAgICB0b3JuIGRvd24gYmFzZWQg b24gW1JGQzUwMzZdIHJ1bGVzLiINCg0KSU1PLCBpZiBUQUMgaXMgZGlzYWJsZWQsIHRoZSBzZXNz aW9uIE1VU1QgYmVoYXZlIGFzIHBlciBSRkM1MDM2IHJ1bGVzLiAoaW4gcGFydGljdWxhciwgSSBk b24ndCBzZWUgYSByZWFzb24gdG8gdGVhciBkb3duIHRoZSBzZXNzaW9uLCBidXQgSSBkbyBzZWUg YSByZWFzb24gdG8gYWR2ZXJ0aXNlIGFsbCBGRWMgbWFwcGluZ3Mgd2hpY2ggd2hlcmUgcHJldmlv dXNseSBmaWx0ZXJlZCBiYXNlZCBvbiBUQS1JZCBuZWdvY2lhdGlvbi4pDQotLS0NCsKnMi4zLjIN CiAgIjUuIElmIHRoZSBTLWJpdCBpcyBzZXQgdG8gMSwgYSBMU1IgcHJvY2VzcyBhIGxpc3Qgb2Yg VEFFcyBmcm9tDQogICAgIFRBQ3MgY2FwYWJpbGl0eSBkYXRhIHdpdGggRS1iaXQgc2V0IHRvIDEg b3IgMCB0byB1cGRhdGUgdGhlDQogICAgIHBlZXJzIFRBRS4gQWxzbywgaXQgdXBkYXRlcyB0aGUg bmVnb3RpYXRlZCBUQUUgbGlzdCBvdmVyIHRoZQ0KICAgICB0TERQIHNlc3Npb24uIg0KDQpXaGF0 J3MgbmV3IGNvbXBhcmVkIHRvIHRoZSBhbHJlYWR5IGRlZmluZWQgcG9pbnRzIDEsIDIgYW5kIDM/ DQpJZiB0aGlzIHBvaW50IDUgaXMga2VwdDoNCiAgOnMvcGVlcnMvcGVlcidzDQogIFdoYXQgZG9l cyB0aGUgc2Vjb25kIHNlbnRlbmNlIGFkZHMgdG8gdGhlIGZpcnN0IG9uZT8NCg0KLS0tDQrCpzMN ClBlcnNvbmFsbHksIEkgd291bGQgcHJlZmVyIHRoYXQgdGhlIGFycmF5IGFsc28gaW5jbHVkZSB0 aGUgbm9ybWF0aXZlIGNvZGUgcG9pbnRzIChyYXRoZXIgdGhhbiByZXF1aXJpbmcgYW4gaW5kaXJl Y3Rpb24gaW4gdGhlIElBTkEgc2VjdGlvbikNCi0tLQ0KwqcyLjMNCldoeSBkb2VzIHRoZSBkb2N1 bWVudCBtYW5kYXRlcyB0aGF0IFRBRSBiZSBzeW1tZXRyaWNhbGx5IG5lZ290aWF0ZWQ/ICBIZXJl IHdlIGFyZSBub3QgbmVnb3RpYXRlZCBjYXBhYmlsaXRpZXMgd2hpY2ggcmVxdWlyZXMgYm90aCBl bmRzIHRvIHN1cHBvcnQgdGhlIGNhcGFiaWxpdHkgYmVmb3JlIGl0cyB1c2FnZS4gV2UgYXJlIG1v c3RseSBhZHZlcnRpc2luZyB0aGUgd2lsbGluZ25lc3Mgb2Ygb25lIExTUiB0byByZWNlaXZlIEZF QyBtYXBwaW5ncyBmcm9tIGl0cyBwZWVyLg0KZS5nLiBsZXQncyB0YWtlIHRoZSBSTEZBIGFwcGxp Y2F0aW9uIHdoaWNoIGhhcyBhc3ltbWV0cmljIG5lZWRzLiBUaGUgUExSIGlzIHdpbGxpbmcgdG8g Z2V0IHRoZSBJUCBwcmVmaXhlcyBtYXBwaW5nIGZyb20gdGhlIG1lcmdlIHBvaW50IChQUSBub2Rl KS4gQnV0IGl0cyBwZWVyICh0aGUgbWVyZ2UgcG9pbnQpIGlzIG5vdCB3aWxsaW5nIHRvIGdldCBh bnkgbWFwcGluZy4gU28gd2h5IHdvdWxkIGl0IG5lZWQgdG8gcmVjZWl2ZSBtYXBwaW5ncyBvZiBu byBpbnRlcmVzdCwgYW5kIHdoeSB3b3VsZCBpdCBuZWVkIHRvIGFkdmVydGlzZSBUQUUgd2hpY2gg ZG9lcyBub3QgaXRzZWxmPw0KVGhlIGRvY3VtZW50IGNvdWxkIGhhdmUgY2hvc2VuIGFuIGFzeW1t ZXRyaWMgbW9kZWwsIHdoZXJlIHRoZSBhZHZlcnRpc2VtZW50IG9mIGEgVEFFIG1lYW5zICJJJ2Qg bGlrZSB0byByZWNlaXZlIHRoZSBjb3JyZXNwb25kaW5nIEZFQyBtYXBwaW5ncyINCkNvbWluZyBi YWNrIHRvIHRoZSBSTEZBIHVzZSBjYXNlLCB0aGlzIHJlcXVpcmVzIGNvbmZpZ3VyaW5nIHRoZSBN ZXJnZSBQb2ludCB3aXRoIHRoZSB3aWxsaW5nbmVzcyB0byBhZHZlcnRpc2UgUkxGQSBhcHBsaWNh dGlvbiwgaW5jbHVkaW5nIHdoZW4gUkxGQSBpbiBub3QgY29uZmlndXJlZCBvbiB0aGlzIG5vZGUu IFNvIHRoaXMgaXMgYWRkaXRpb25hbCBjb25maWd1cmF0aW9uIHJlcXVpcmVtZW50LiBJbiBhZGRp dGlvbiwgUkxGQSBpcyBkZXNpZ25lZCB0byBiZSBhc3ltbWV0cmljIGluIG5hdHVyZSwgd2l0aCBm ZWF0dXJlIHJlcXVpcmVtZW50IG9ubHkgb24gdGhlIGxvY2FsIG5vZGUuIFN1Y2ggZG9jdW1lbnQg d291bGQgbm93IHJlcXVpcmUgc29tZSBzdXBwb3J0IGZvciBSTEZBIGF3YXJlbmVzcyBvbiB0aGUg TVAgbm9kZSB3aGljaCBpcyB1bmRlc2lyYWJsZS4gSSBndWVzcyB0aGF0IHRoaXMgaXMgbm90IHRv byBiYWQgdG8gUkxGQSB3aGljaCBpcyBhIHByZS1leGlzdGluZyBhcHBsaWNhdGlvbiwgYnV0IHdo YXQgYWJvdXQgZnV0dXJlIGFwcGxpY2F0aW9ucyB3aGljaCB3b3VsZCBhbHNvIGJlIGFzeW1ldHJp Yz8NCi0tLQ0Kwqc0DQoiV2l0aCB0aGUgU0FDLCB0aGUgcmVzcG9uZGluZyBMU1IgaXMgbm90IGF3 YXJlIG9mDQogICB0YXJnZXRlZCBhcHBsaWNhdGlvbnMuIFRodXMgaXQgbWF5IGJlIHVuYWJsZSB0 byBjb21tdW5pY2F0ZSBpdHMNCiAgIGludGVyZXN0IG9yIGRpc2ludGVyZXN0IHRvIHJlY2VpdmUg c3RhdGUgaW5mb3JtYXRpb24gZnJvbSB0aGUgcGVlci4iDQoNClNvcnJ5IGJ1dCBJIGZhaWwgdG8g c2VlIHRoZSBsb2dpYyBvciB0aGUgdXNlIGNhc2UuIE9uZSBpcyBhIHByaW9yaSBjYXBhYmxlIG9m IGNvbW11bmljYXRlIGl0cyAoX293bl8pIGludGVyZXN0LCBpbmRlcGVuZGVudGx5IG9mIHRoZSBv bmVzIG9mIGl0cyBwZWVyLiBlLmcuLCBJZiBJJ2QgbGlrZSBhIGJlZXIgaW4gYSByZXN0YXVyYW50 LCBJIGFzayBmb3IgYSBiZWVyLiAoSSBkb24ndCBuZWVkIHRvIHdhaXQgZm9yIHRoZSBtZW51LCBz byBzZWUgd2hldGhlciBJIHdhbid0IGEgYmVlcikNCg0KIiAgVGhlcmVmb3JlLCB3aGVuIHRoZSBy ZXNwb25kaW5nIExTUiBpcyBub3QgYXdhcmUgb2YgdGFyZ2V0ZWQNCiAgIGFwcGxpY2F0aW9ucyBz dWNoIGEgcmVtb3RlIExGQSBhbmQgQkdQIGF1dG8gZGlzY292ZXJlZCBwc2V1ZG93aXJlcywNCiAg IFRBQyBtZWNoYW5pc20gc2hvdWxkIGJlIHVzZWQgYW5kIHdoZW4gdGhlIHJlc3BvbmRpbmcgTFNS IGlzIGF3YXJlDQogICAod2l0aCBhcHByb3ByaWF0ZSBjb25maWd1cmF0aW9uKSBvZiB0YXJnZXRl ZCBhcHBsaWNhdGlvbnMgc3VjaCBhcyBGRUMNCiAgIDEyOCBwc2V1ZG93aXJlLCBTQUMgbWVjaGFu aXNtIHNob3VsZCBiZSB1c2VkLiINCg0KV2VsbCwgYXMgYWxyZWFkeSBleHByZXNzZWQsIEkgZG9u J3QgZmVlbCB0aGF0IFRBQyBpcyB3ZWxsIHN1aXRlZCBmb3IgdGhlIFJMRkEgYXBwbGljYXRpb24g YXMgaXQgYWRkcyB0aGUgcmVxdWlyZW1lbnQgdG8gY29uZmlndXJlIGJvdGggZW5kcy4gKG1vcmUg c3BlY2lmaWNhbGx5IHRoZSBNZXJnZSBQb2ludCkuIEluIHdoaWNoIGNhc2UsIGFzIHBlciB5b3Vy IGFib3ZlIHRleHQsIFNBQyBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkIG9mIFRBQy4NCklmIExEUCBo YXMgYWxyZWFkeSBhIHdheSB0byBjb250cm9sIEZFQy9zdGF0ZSBhZHZlcnRpc2VtZW50IChhcyBw ZXIgUkZDIDc0NzMpLCBJIGZlZWwgdGhhdCBhZGRpbmcgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSBp biBUQUMgaXMgcmVkdW5kYW50Lg0KDQoNCi0tLQ0Kwqc0DQoiVGhlIHNldCBvZg0KICAgYXBwbGlj YXRpb25zIG5lZ290aWF0ZWQgYnkgdGhlIFRBQyBtZWNoYW5pc20gaXMgc3ltbWV0cmljIGJldHdl ZW4gdGhlDQogICB0d28gTERQIHBlZXJzLiINCg0Kb2suIGZvciB0aGUgX25lZ29jaWF0ZWRfIGFw cGxpY2F0aW9ucy4NCg0KIkluIHRoZSBhYnNlbmNlIG9mIGZ1cnRoZXIgbWVjaGFuaXNtcywgdHdv IExEUCBwZWVycw0KICAgd2lsbCBib3RoIGFkdmVydGlzZSBzdGF0ZSBpbmZvcm1hdGlvbiBmb3Ig dGhlIHNhbWUgc2V0IG9mDQogICBhcHBsaWNhdGlvbnMuIg0KDQpXaGF0IGRvIHlvdSBtZWFuIGJ5 ICJzdGF0ZSBpbmZvcm1hdGlvbiI/IEF0IGZpcnN0IHJlYWRpbmcsIEkgdW5kZXJzdG9vZCAiVEFF IiBidXQgdGhpcyB3b3VsZCBiZSBpbmNvcnJlY3QuIFNvIG5vdyBJIGd1ZXNzIHRoYXQgeW91IG1l YW4gIkZFQyBtYXBwaW5ncyINCg0KLS0tDQpVc2FnZSAobmV3IHNlY3Rpb24pDQpUbyBhbGxvdyBm b3IgaW5jcmVtZW50YWwgZGVwbG95bWVudCBvZiBuZXcgVEFJIGFzIHdlbGwgYXMgcHJpdmF0ZSB1 c2FnZSBieSBhIG5ldHdvcmsgb3BlcmF0b3IsIEkgdGhpbmsgdGhlIGNvbmZpZ3VyYXRpb24gU0hP VUxEIGFsbG93IHRoZSBjb25maWd1cmF0aW9uIG9mIGFueSBUQUkgKGluY2x1ZGluZyB0aGUgb25l cyB1bmtub3duIGZyb20gdGhlIGltcGxlbWVudGF0aW9uKSBvbiBib3RoIHRoZSBzZW5kaW5nIHNp ZGUgYW5kIHRoZSByZWNlaXZpbmcgc2lkZS4NCi0tLQ0Kwqc0DQoiVGhlIFRBQyBtZWNoYW5pc20g TVVTVA0KICAgdGFrZSBwcmVjZWRlbmNlIG92ZXIgdGhlIFNBQyBtZWNoYW5pc20gd2l0aCByZXNw ZWN0IHRvIGVuYWJsaW5nDQogICBhcHBsaWNhdGlvbnMgZm9yIHdoaWNoIHN0YXRlIGluZm9ybWF0 aW9uIHdpbGwgYmUgYWR2ZXJ0aXNlZC4iDQoNCklzIHRoaXMgbm90IGEgY2FzZSB3aGVyZSB0aGUg ZG9jdW1lbnQgbWV0YSBkYXRhIHNob3VsZCBpbmRpY2F0ZSB0aGF0IHRoaXMgZG9jdW1lbnQgdXBk YXRlcyBSRkMgNzQ3Mz8NCi0tLQ0KwqczDQoiSVB2NCBpbnRyYS1hcmVhIEZFQ3MiDQpJcyB0aGlz IGp1c3QgYSBuYW1lIG9mIGFwcGxpY2F0aW9uLCBvciBpcyB0aGVyZSBhIHNwZWNpZmljIGJlaGF2 aW9yIGFzc29jaWF0ZWQgd2l0aCBpdD8gKGUuZy4gb25seSBhZHZlcnRpc2luZyB0aGUgSVB2NCBG RUMgZnJvbSBteSBhbiBhcmVhLikgSWYgc28sIHRoZSBiZWhhdmlvciBzaG91bGQgYmUgc3BlY2lm aWVkLiBBbmQgcGxlYXNlIGNsYXJpZnkgd2hldGhlciB0aGlzIGlzIHRoZSBhcmVhIG9mIHRoZSBz ZW5kZXIgb3Igb2YgdGhlIHJlY2VpdmVyLCBhcyBpbiB0aGUgZ2VuZXJhbCBjYXNlLCB0aGV5IG1h eSBiZSBpbiBhIGRpZmZlcmVudCBhcmVhLiBBbmQgY2xhcmlmeSB0aGUgYmVoYXZpb3IgZm9yIElT LUlTIGxldmVsIDIgbm9kZXMuDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_53C29892C857584299CBF5D05346208A0F9FC3B9OPEXCLILM21corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLmljb24NCgl7bXNvLXN0eWxlLW5hbWU6aWNv bjt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOp IEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBy w6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJl YXN0LWxhbmd1YWdlOkZSO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTE3NjUzNjQ1Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxNjI5NzUyNjY4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz MjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNt O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SGVs bG8sIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmUg YmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhp cyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0 aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBs YXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVz dC4NCiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0 byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5n IERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciI+PHNwYW4gY2xhc3M9Imljb24i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymx1ZSI+4oCLPC9zcGFuPjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJh Yy93aWtpL1J0Z0Rpcjwvc3Bhbj48L2E+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkFsdGhvdWdoIHRoZXNlIGNvbW1lbnRz IGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBi ZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVy IElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8g cmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZw0KIHRoZSBkcmFm dC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkRvY3VtZW50 OiA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW1w bHMtYXBwLWF3YXJlLXRsZHAtMDUudHh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ZHJhZnQtaWV0Zi1t cGxzLWFwcC1hd2FyZS10bGRwLTA1LnR4dDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxi cj4NClJldmlld2VyOiBCcnVubyBEZWNyYWVuZTxicj4NClJldmlldyBEYXRlOiAyMDE2LzEwLzEw PGJyPg0KSUVURiBMQyBFbmQgRGF0ZTogbm90IHN0YXJ0ZWQgKEFGQUlLKTxicj4NCkludGVuZGVk IFN0YXR1czogUHJvcG9zZWQgU3RhbmRhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Ry b25nPjxzcGFuIGxhbmc9IkVOLVVTIj5TdW1tYXJ5Ojwvc3Bhbj48L3N0cm9uZz48c3BhbiBsYW5n PSJFTi1VUyI+IDxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGhhdmUgc2lnbmlmaWNhbnQgY29u Y2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCBhbmQgcmVjb21tZW5kIHRoYXQgdGhlIFJvdXRpbmcg QURzIGRpc2N1c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIgd2l0aCB0aGUgYXV0aG9ycy48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48 L3N0cm9uZz48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RHJh ZnQgaXMgd2VsbCByZWFkYWJsZS4gQnV0IEkgZmVlbCB0aGF0IGl0IGNvdWxkIGJlIGV2ZW4gbW9y ZSBwcmVjaXNlIG9uIG5vcm1hdGl2ZSBiZWhhdmlvcnMgKGNmIG1pbm9yIGNvbW1lbnRzKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiPlByZWxpbWluYXJ5IGluZm86PG86cD48L286cD48L3NwYW4+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIEknbSBub3Qg YSBMRFAgZXhwZXJ0LiBVbmZvcnR1bmF0ZWx5LCB0aGlzIG1heSBiZWNvbWUgYXBwYXJlbnQgaW4g dGhlIGJlbG93IGNvbW1lbnRzLiBTbyB5b3UgYXJlIHdlbGNvbWUgdG8gZGlzYWdyZWUgYW5kIHBy b3ZpZGUgdGhlIGluZm9ybWF0aW9uIGFuZCByZWFzb25pbmcgdGhhdCBJIG1heSBiZSBtaXNzaW5n LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4tIEdpdmVuIHRoYXQgdGhlIHJlcXVpcmVkIElBTkEgY29kZSBwb2ludHMgaGF2ZSBu b3QgYmVlbiBwcmUtYWxsb2NhdGVkLCBJIGFtIGFzc3VtaW5nIHRoYXQgbm8gaW1wbGVtZW50YXRp b24gb2YgdGhpcyBkb2N1bWVudCBleGlzdHMuIEhlbmNlIEknbSBub3QgcmVzdHJpY3RpbmcgbXkg Y29tbWVudHMgdG8gbWlub3IgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyI+TWFqb3IgSXNzdWU6PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BYnN0cmFjdCBhbmQgU2hlcGhlcmQgV3JpdGUt VXAgZGVmaW5lcyB0aGUgZ29hbCBvZiB0aGUgc29sdXRpb24gYXMgYWR2ZXJ0aXNpbmcgdGhlIHB1 cnBvc2UgZm9yIHNlbmRpbmcgdGhpcyB0TERQIHNlc3Npb24gcmVxdWVzdCB0byB0aGUgdExEUCBy ZWNlaXZlciwgc3VjaCB0aGF0IHRoZSByZWNlaXZlciBoYXMgZW5vdWdoIGluZm9ybWF0aW9uIHRv IGRlY2lkZSB0byBlaXRoZXINCiBhY2NlcHQgb3IgZGVueSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBkb24ndCBmZWVs IHRoYXQgdGhlIHNvbHV0aW9uIHBlcmZlY3RseSBtYXRjaGVzIHRoaXMgcHVycG9zZS4gRmlyc3Qg dGhlIHNvbHV0aW9uIHJlcXVpcmVzIHRoYXQgYm90aCBlbmRzIG9mIHRoZSB0TERQIHNlc3Npb24g bmVnb3RpYXRlIHRoZSBfc2FtZV8gc2V0IG9mIGFwcGxpY2F0aW9ucy4gSSBkb24ndCBzZWUgd2h5 IHRoaXMgaXMgbmVlZGVkIHRvIGFjaGlldmUgdGhlIGFib3ZlDQogZ29hbC4gUGx1cyBJIGZpbmQg dGhpcyBwcm9ibGVtYXRpYyBmb3Igc29tZSBhcHBsaWNhdGlvbnMgd2l0aCBhc3ltbWV0cmljIHJl cXVpcmVtZW50cyAoZS5nLiBSTEZBKSwgaW4gcGFydGljdWxhciBmb3IgaW5jcmVtZW50YWwgZGVw bG95bWVudCBvZiBmdXR1cmUgYXN5bW1ldHJpYyBhcHBsaWNhdGlvbi4gKG1vcmUgY29tbWVudHMg b24gdGhpcyBpbiB0aGUgbWlub3IgaXNzdWVzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBhZGRpdGlvbiwgSSBkb24ndCBz ZWUgaG93IHRoZSBhZGRpdGlvbmFsIEZFQyBmaWx0ZXJpbmcgaGVscHMgZnVsZmlsbGluZyB0aGlz IGdvYWwuIEkgYWxzbyBmaW5kIGl0IHJlZHVuZGFudCB3aXRoIFJGQyA3NDczLiBJIGFsc28gZG9u J3QgdGhpbmsgdGhhdCB0aGlzIEZFQyBmaWx0ZXJpbmcgc2hvdWxkIGJlIHN5bW1ldHJpY2FsIChl LmcuIFJMRkEgYXBwbGljYXRpb24pLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHNob3J0LCBJIHdvdWxkIGhhdmUgbWFk ZSB0aGUgVEFJIGFkdmVydGlzZW1lbnQgYXN5bW1ldHJpYywgYW5kIHJlbW92ZWQgdGhlIEZFQyBm aWx0ZXJpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5GaW5hbGx5LCBpZiB0aGUgZ29hbCBpcyB0byBh bGxvdyB0aGUgcmVjZWl2ZXIgdG8gbGltaXQgaW5jb21pbmcgdExEUCBzZXNzaW9ucywgcHJlc3Vt YWJseSBmb3Igc2NhbGFiaWxpdHkgcHVycG9zZSwgaWYgb25lIGFwcGxpY2F0aW9uIGlzIGFsbG93 ZWQgYW5kIGhlbmNlIHRoZSB0TERQIHNlc3Npb24gaXMgc2V0IHVwLCB3aGF0IHdvdWxkIGJlIHRo ZSByZWFzb24gdG8gbGltaXQNCiB0aGUgYXBwbGljYXRpb25zIGV4Y2hhbmdlZCBvdmVyIHRoaXMg c2Vzc2lvbj8gSU9XLCB3aHkgbGltaXRpbmcgdGhlIGFwcGxpY2F0aW9ucyB0byB0aGUgaW50ZXJz ZWN0aW9uIG9mIGJvdGggYWR2ZXJ0aXNlZCBhbmQgcmVjZWl2ZWQgc2V0IG9mIGFwcGxpY2F0aW9u PyBOb3RlIHRoYXQgwqc1LjMgbGlnaHRseSByZWZlcnMgdG8gdGhpcyBwcm9ibGVtLCBidXQgaW4g YSB2ZXJ5IGFwcGxpY2F0aW9uIHNwZWNpZmljIHdheSAoYW5kIG5vdCByZWFsbHkgbm9ybWF0aXZl KSwNCiB3aGlsZSB0aGUgY29uc2VxdWVuY2VzIGNvdWxkIHByb2JhYmx5IGJlIG1hZGUgZ2VuZXJh bC4gRXNwZWNpYWxseSBnaXZlbiB0aGUgcHJlLWV4aXN0ZW5jZSBvZiBSRkMgNzQ3MyB3aGljaCBj YW4gYmUgdXNlZCB0byBsaW1pdCB0aGUgRkVDIGFkdmVydGlzZW1lbnRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiPk1pbm9yIElzc3Vlczo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPsKnNiAmcXVvdDtT ZWN1cml0eSBjb25zaWRlcmF0aW9ucyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UQUMgbmVnb3RpYXRpb24gc2VlbXMg dG8gYWxsb3cgYW4gZW50aXR5IHRvIHJlbW90ZWx5IGRpc2NvdmVyIHRoZSB0YXJnZXRlZCBMRFAg YXBwbGljYXRpb25zIHJ1bm5pbmcgb24gYSByZW1vdGUgbm9kZS4gVGhpcyBpcyBhIG5ldyBzZWN1 cml0eSBjb25zaWRlcmF0aW9uIHdoaWNoIHNob3VsZCBwcm9iYWJseSBiZSBkaXNjdXNzZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5BbHNvLCBnaXZlbiB0aGF0IG11bHRpcGxlIGFwcGxpY2F0aW9ucyBt YXBzIHRvIHRoZSBzYW1lIEZFQywgdHdvIHBlZXJzIGluIGRpZmZlcmVudCBBU2VzIGNvdWxkIHRy eSB0byBjaGVhdCwgYnkgc3VjY2Vzc2l2ZWx5IHRyeWluZyBtdWx0aXBsZSBhcHBsaWNhdGlvbnMg bWFwcGluZyB0byB0aGUgc2FtZSBGRUMuIChlLmcuIGlmIEkgd2FudCBJUHY0IEZFQyBtYXBwaW5n LCBJIHdvdWxkDQogdHJ5IHdpdGggJnF1b3Q7TERQdjQgVHVubmVsaW5nJnF1b3Q7LCB0aGVuICZx dW90O0xEUHY0IFJlbW90ZSBMRkEmcXVvdDssIHRoZW4gJnF1b3Q7SVB2NCBpbnRyYS1hcmVhIEZF Q3MmcXVvdDssIHRoZW4gcG9zc2libHkgJnF1b3Q7TERQIHNlc3Npb24gUHJvdGVjdGlvbiZxdW90 OykuIFRoaXMgaXMgYWxzbyBub3QgZGlzY3Vzc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj7CpzcgJnF1b3Q7SUFOQSBDb25zaWRlcmF0aW9ucyZxdW90OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDsweDAw MDEgLSAweDFGRkYmbmJzcDsgQXZhaWxhYmxlIGZvciBhc3NpZ25tZW50IGJ5IElFVEYgY29uc2Vu c3VzJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkFjY29yZGluZyB0byBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTIyNiNzZWN0aW9uLTQuMSAmcXVvdDtJRVRGIFJldmlldyZxdW90OyBpcyB0aGUgbmV3IG5h bWUgZm9yICZxdW90O0lFVEYgY29uc2Vuc3VzJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVv dDsweDdGRkYgLSAweEZGRkUmbmJzcDsgQXZhaWxhYmxlIGZvciB2ZW5kb3Igc3BlY2lmaWMgcHJp dmF0ZSB1c2UmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gVGhpcyBsb29rIGxpa2UgYSB2ZXJ5 IGxhcmdlIHJhbmdlIGZvciBhIHByaXZhdGUgdXNlIChoYWxmIG9mIHRoZSByZWdpc3RyeSk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+LSAmcXVvdDt2ZW5kb3Igc3BlY2lmaWMgcHJpdmF0ZSB1c2UmcXVvdDsgaXMgbm90IGEgV2Vs bC1Lbm93biBJQU5BIFBvbGljeSBhcyBkZWZpbmVkIGluJm5ic3A7IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1MjI2I3NlY3Rpb24tNC4xIC4gSXMgdGhlcmUgYW55IGRlZmluaXRpb24g b2YgdGhpcyBQb2xpY3kgb3Igc2hvdWxkIHlvdSBkZXNjcmliZSBpdD8gSG93IGlzIGNvZGUtcG9p bnQgY29sbGlzaW9uDQogc3VwcG9zZWQgdG8gYmUgYXZvaWRlZCBpbiBkZXBsb3ltZW50cz8gKEkn bSBndWVzc2luZyB0aGF0IHRoaXMgaXMgY29taW5nIGZyb20gUkZDIDUwMzYgSUFOQSBzZWN0aW9u LCBidXQgUkZDNTAzNiBzZWVtcyB0byBoYXZlIGEgJnF1b3Q7dmVuZG9yLUlEJnF1b3Q7IGZpZWxk IHRvIGRpZmZlcmVudGlhdGUgdmVuZG9ycywgd2hpY2ggaXMgbm90IHRoZSBjYXNlIG9mIHRoaXMg ZG9jdW1lbnQuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5PbiBteSBzaWRlLCBJJ2QgcmF0aGVyIHByb3Zpc2lvbiAyIHZlcnkg c21hbGwgcG9vbHMgZm9yIGV4cGVyaW1lbnRhbCBhbmQgcHJpdmF0ZS11c2UuIChpLmUuIHByaXZh dGUgdG8gdGhlIHVzZXIvIHRoZSBuZXR3b3JrIHByb3ZpZGVyLikNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+wqcxICZxdW90O0ludHJvZHVjdGlvbiZxdW90Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mcXVvdDtBcHBsaWNhdGlvbnMgc3VjaCBhcyBSZW1vdGUgTEZBIGFuZCBCR1AgYXV0byBk aXNjb3ZlcmVkIHBzZXVkb3dpcmUgYXV0b21hdGljYWxseSBpbml0aWF0ZSBhc3ltbWV0cmljIGV4 dGVuZGVkIGRpc2NvdmVyeSB0byBhbnkgTFNSIGluIGEgbmV0d29yayBiYXNlZCBvbiBsb2NhbCBz dGF0ZSBvbmx5LiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFncmVlIHRoYXQgUmVtb3RlIExGQSBpcyBhc3ltbWV0 cmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5JJ3ZlIG5vdCBiZWVuIGZvbGxvd2luZyB0aGUgd29yayBvbiBCR1AgYXV0by1k aXNjb3ZlcnksIGJ1dCBJIHdvdWxkIGhhdmUgYSBwcmlvcmkgYXNzdW1lZCB0aGF0IGJvdGggdExE UCBlbmQgcG9pbnRzIGFyZSBydW5uaW5nIEJHUCBhdXRvZGlzY292ZXJ5IGFuZCBoZW5jZSB0aGUg ZGlzY292ZXJ5IGlzIHN5bW1ldHJpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+wqcy LjEgJnF1b3Q7RW5jb2RpbmcmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O1RhcmdldGVk IEFwcGxpY2F0aW9uIElkZW50aWZpZXIgKFRBLUlkKTogYSAxNiBiaXQgVGFyZ2V0ZWQgQXBwbGlj YXRpb24gSWRlbnRpZmllciB2YWx1ZS4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWNjb3JkaW5nIHRvIHRoZSBmaWd1 cmUganVzdCBhYm92ZSwgdGhlIGZpZWxkIHNlZW1zIHRvIG9ubHkgaGF2ZSAxNSBiaXRzLiAoQXMg Yml0IDAgaXMgdXNlZCBmb3IgdGhlIEUtYml0KS4gSWYgc28gdGhlIElBTkEgcmVnaXN0cnkgd291 bGQgYWxzbyBuZWVkIHRvIGJlIG1vZGlmaWVkLiBPdGhlcndpc2UsIHRoZSBmaWd1cmUgbmVlZHMg dG8gYmUgZml4ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPsKnMi4yICZxdW90O1By b2NlZHVyZXMmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7VGhlIFRBQyBUTFYncyBDYXBhYmlsaXR5IGRhdGEg TVVTVCBjb25zaXN0cyBvZiBub25lLCBvbmUgb3IgbW9yZSBUQUUmcXVvdDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+OnMvTVVT VC9NQVkmbmJzcDsmbmJzcDsgPyAob3RoZXJ3aXNlLCBJdCdzIG5vdCBjbGVhciB0byBtZSB3aGF0 IGlzIHRoZSBtYW5kYXRlZCBiZWhhdmlvciBzaW5jZSBhbGwgcG9zc2libGUgYmVoYXZpb3JzIHNl ZW1zIGFsbG93ZWQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPsKnMTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+JnF1b3Q7Rm9yIGFuIGFwcGxpY2F0aW9uIHN1Y2ggYXMgRkVDIDEyODxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsgcHNldWRvd2lyZSwgdGhlIHJlbW90ZSBMU1IgaXMgY29uZmlndXJlZCB3aXRo IHRoZSBzb3VyY2UgTFNSIGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHNvIHRoYXQgaXQgY2Fu IHVzZSB0aGF0IGluZm9ybWF0aW9uIHRvIGFjY2VwdCBvciBpZ25vcmUgZ2l2ZW4gdExEUDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsgSGVsbG8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgQXBw bGljYXRpb25zIHN1Y2ggYXMgUmVtb3RlIExGQSBhbmQgQkdQIGF1dG8gZGlzY292ZXJlZCBwc2V1 ZG93aXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBhdXRvbWF0aWNhbGx5IGluaXRpYXRlIGFzeW1tZXRy aWMgZXh0ZW5kZWQgZGlzY292ZXJ5IHRvIGFueSBMU1IgaW4gYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsg bmV0d29yayBiYXNlZCBvbiBsb2NhbCBzdGF0ZSBvbmx5LiBXaXRoIHRoZXNlIGFwcGxpY2F0aW9u cywgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyByZW1vdGUgTFNSIGlzIG5vdCBleHBsaWNpdGx5IGNv bmZpZ3VyZWQgd2l0aCB0aGUgc291cmNlIExTUiBhZGRyZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsg U28gdGhlIHJlbW90ZSBMU1IgZWl0aGVyIHJlc3BvbmRzIG9yIGlnbm9yZXMgYWxsIHRMRFAgSGVs bG9zLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwO1RoZSBpbnRyb2R1Y3Rp b24gc2VlbXMgdG8gaW1wbHkgdGhhdCB0aGlzIGRvY3VtZW50IHdvdWxkIGdpdmUgYSByZW1vdGUg cGVlciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIGFjY2VwdCBvciBpZ25vcmUg dExEUCBoZWxsby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+TXkgbGltaXRlZCB1bmRlcnN0YW5kaW5nIG9mIExEUCBjYXBhYmls aXR5IGlzIHRoYXQgdGhleSBhcmUgZXhjaGFuZ2VkJm5ic3A7IGluIEluaXRpYWxpemF0aW9uIGFu ZCBDYXBhYmlsaXR5IG1lc3NhZ2VzLCBpLmUuIG5vdCBpbiBIZWxsbyBtZXNzYWdlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5I ZW5jZSBpdCdzIG5vdCBjbGVhciB0byBtZSBob3cgdGhpcyBkb2N1bWVudCBoZWxwcyB0aGUgcmVt b3RlIExEUCBzcGVha2VyIGluIGRlY2lkaW5nIHRvIGFjY2VwdCBvciBpZ25vcmUgdExEUCBoZWxs by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj7CpzIuMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDsmbmJzcDsmbmJzcDsgSWYgdGhl cmUgaXMgYXQgbGVhc3Qgb25lIFRBRSBjb21tb24gYmV0d2VlbiB0aGUgVEFDIFRMViBpdCBoYXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7IHJlY2VpdmVkIGFuZCBpdHMgb3duLCB0aGUgc2Vzc2lvbiBNVVNU IHByb2NlZWQgdG8gZXN0YWJsaXNobWVudCBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgcGVyIFtSRkM1 MDM2XS4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkknbSBub3Qgc3VyZSB0aGlzIGlzIOKAnGFz IHBlciBbUkZDNTAzNl3igJ0gc2luY2UgdGhpcyBkb2N1bWVudCBkZWZpbmVzIGFkZGl0aW9uYWwg cnVsZXMgdG8gZGVmaW5lIHdoaWNoIEZFQyBtYXBwaW5nIG5lZWRzIHRvIGJlIGFkdmVydGlzZWQs IGFuZCB3aGV0aGVyIG9yIG5vdCB0byBhY2NlcHQgdGhlIHNlc3Npb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+wqcyLjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7VGhlIFRBQyBUTFYncyBDYXBhYmlsaXR5 IGRhdGEgTVVTVCBjb25zaXN0cyBvZiBub25lLCBvbmUgb3IgbW9yZSBUQUUmcXVvdDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ SXQncyBub3QgY2xlYXIgdG8gbWUgd2hhdCBpcyB0aGUgdXNlIGNhc2UgdG8gYWR2ZXJ0aXNlIG5v bmUgVEFFLCBnaXZlbiB0aGF0IGluIHRoaXMgY2FzZSwgdGhlIGludGVyc2VjdGlvbiBvZiB0aGUg cmVjZWl2ZWQgYW5kIHNlbnQgVEEtSWQgd2lsbCBiZSBudWxsIGFuZCBoZW5jZSB0aGUgdExEUCBz ZXNzaW9uIHdpbGwgYmUgY2xvc2VkIGJ5IGFueSBvZiB0aGUgdExEUCBzcGVha2Vycy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj7CpzIuMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtJZiB0aGUgcmVjZWl2ZXIg TFNSIHJlY2VpdmVzIGFuIHVua25vd24gVEEtSWQgaW4gdGhlIFRBRSwgaXQgTVVTVCBzaWxlbnRs eSBpZ25vcmUgc3VjaCBhIFRBRSBhbmQgY29udGludWUgcHJvY2Vzc2luZyB0aGUgcmVzdCBvZiB0 aGUgVExWLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5Bc3N1bWluZyB0aGUgcmVjZWl2ZXIgKG5vZGUgQSkgc3VwcG9y dHMgTm9uIFN0b3AgUm91dGluZyBhbmQgaXMgdXBncmFkZWQgdG8gc3VwcG9ydCBhIG5ldyBUQS1J ZCBzaG91bGQgaXQgY2hlY2sgZm9yIHRoZSBwcmV2aW91c2x5IHJlY2VpdmVkIFRBRSB0aGF0IGl0 IGhhcyBzaWxlbnRseSBpZ25vcmVkIG9yIGRvZXMgdGhlIHNwZWFrZXIgKG5vZGUgQikgc3VwcG9z ZWQgdG8gcmUtc2VuZA0KIGFsbCBpdCdzIFRBLUlEIGlmIGl0IHJlY2VpdmUgbmV3IFRBLUlkIGZy b20gbm9kZSBBPyBNeSByZWFkaW5nIG9mIHRoZSBlbmQgb2Ygc2VjdGlvbiAyLjIgaXMgdGhhdCBp biB0aGlzIGNhc2UgdGhlIHJlY2VpdmVyIG11c3QgY2hlY2tlZCBmcm9tIHByZXZpb3VzbHkgcmVj ZWl2ZWQgVEFFLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5NYXkgYmUgOnMvcmVjZWl2ZXMvcmVjZWl2ZWQmbmJzcDsgd291bGQg YmUgZW5vdWdoIHRvIGFkZHJlc3MgdGhpcyBjYXNlLiBPciBwcmVmZXJhYmx5IGFkZGluZyBhIHNl bnRlbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPsKnMi4yPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O0lu IHRoZSBsYXN0IGluc3RhbmNlLCBzdXBwb3NlIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgaW5pdGlh dGluZyBMU1IgYWR2ZXJ0aXNlcyBBLCBCIGFuZCBDIGFzIGEgVEEtSWRzIGFuZCB0aGUgcmVzcG9u ZGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgTFNSIGFkdmVydGlzZXMgRCBhbmQgRSBhcyBUQS1JZHMs IHRoYW4gdGhlIG5lZ290aWF0ZWQgdGFyZ2V0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGFwcGxjaWF0 aW9ucyBhcyBwZXIgYm90aCB0aGUgTFNScyBhcmUgbm9uZS4gVGhlIFJlc3BvbmRpbmcgTFNSIHNl bmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyAnU2Vzc2lvbiBSZWplY3RlZC9UYXJnZXRlZCBBcHBsaWNh dGlvbiBDYXBhYmlsaXR5IE1pcy1NYXRjaCc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IE5vdGlmaWNhdGlv biBtZXNzYWdlIHRvIHRoZSBpbml0aWF0aW5nIExTUiBhbmQgbWF5IGNsb3NlIHRoZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsgc2Vzc2lvbi4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkknZCBw cmVmZXIgaGF2aW5nIG5vcm1hdGl2ZSB0ZXh0IHN0YXRpbmcgdGhlIHJlcXVpcmVkIGJlaGF2aW9y IHJhdGhlciB0aGFuIGhhdmluZyBhbiBleGFtcGxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5pLmUuIEknbSBsb29raW5nIGZv ciBhIHRleHQgc2ltaWxhciB0byAmcXVvdDtJZiB0aGUgaW50ZXJzZWN0aW9uIG9mIHRoZSBzZXRz IG9mIHJlY2VpdmVkIGFuZCBzZW50IFRBLUlkIGlzIG51bGwsIHRoZW4gTFNSIE1VU1Qgc2VuZHMg J1Nlc3Npb24gUmVqZWN0ZWQvVGFyZ2V0ZWQgQXBwbGljYXRpb24gQ2FwYWJpbGl0eSBNaXMtTWF0 Y2gnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBOb3RpZmljYXRpb24gbWVzc2FnZSB0byB0aGUgaW5pdGlh dGluZyBMU1IgYW5kIGNsb3NlIHRoZSBzZXNzaW9uLiZxdW90OyZuYnNwOyZuYnNwOw0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDtvciA6cy9NVVNUL1NI T1VMRCBvciA6cy9NVVNUL01BWSZuYnNwOyZuYnNwOyBhcyB5b3Ugd2lzaDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsm bmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj7CpzIuMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtJZiBpdCBzZXRzIHRoZSBz ZXNzaW9uIHNldHVwIHJldHJ5IGludGVydmFsIHRvIG1heGltdW0sIHRoZSBzZXNzaW9uIE1BWSBz dGF5IGluIGEgbm9uLWV4aXN0ZW50IHN0YXRlLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYg dGhpcyByZWZlcnMgdG8gdGhlIExEUCBGU00sIFJGQyA1MDM2IHVzZWQgdGhlIHRlcm0gJnF1b3Q7 Tk9OIEVYSVNURU5UJnF1b3Q7IHJhdGhlciB0aGFuICZxdW90O25vbi1leGlzdGVudCZxdW90Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+wqcyLjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBzZWN0aW9uIG1peGVzIGNvcHkgb2YgcHJl dmlvdXMgc3BlY2lmaWNhdGlvbnMgKGUuZy4gUkZDIDU1NjEpIHdpdGggdGhlIG5ldyBzcGVjaWZp Y2F0aW9uLiBQZXJzb25hbGx5LCBJJ2QgcHJlZmVyIHRoYXQgdGhlIGRvY3VtZW50IGJlIGNsZWFy IG9uIHRoZSBwYXJ0IHdoaWNoIGFyZSByZXVzZWQgdW5jaGFuZ2VkIGFuZCB0aGUgcGFydCB3aGlj aCBhcmUgbmV3IHNwZWNpZmljYXRpb24uDQogSW4gZ2VuZXJhbCwgSSBwZXJzb25hbGx5IGRvbid0 IHRoaW5rIHRoYXQmbmJzcDsgdGhpcyBpcyBhIGdvb2QgcHJhY3RpY2UsIGFzIGl0IGJlY29tZXMg dW5jbGVhciB3aGljaCBkb2N1bWVudCBpcyB0aGUgbm9ybWF0aXZlIGRlZmluaXRpb24uIEFuZCBp biBwYXJ0aWN1bGFyIGluIHRoaXMgZG9jdW1lbnQsIHRoZXJlIGlzIGEgY29weS9wYXN0ZSBlcnJv ciBkdXJpbmcgdGhlIGNvcHkgZnJvbSBSRkMgNTU2MSwgc28gaXQgbXkgYmUgdW5jbGVhciBpZiB0 aGUNCiBnb2FsIGlzIHRvIHJlZGVmaW5lIFJGQyA1NTYxIG9yIG5vdC4gKCZxdW90O1R5cCZxdW90 OyBmaWVsZCBoYXMgYmVlbiBpbmNyZWFzZWQgYnkgMSBiaXQgYW5kIHRoZSAmcXVvdDtMZW5ndGgm cXVvdDsgaGFzIGJlZW4gZGVjcmVhc2VkIGJ5IDEgYml0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB3 b3VsZCBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgY2hhbmdlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T0xE OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IEFuIExTUiBNQVkgYWR2ZXJ0aXNlIHRo YXQgaXQgaXMgY2FwYWJsZSB0byBuZWdvdGlhdGUgYSB0YXJnZXRlZCBMRFA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7IGFwcGxpY2F0aW9uIGxpc3Qgb3ZlciBhIHRMRFAgc2Vzc2lvbiBieSB1c2luZyB0aGUg Q2FwYWJpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgQWR2ZXJ0aXNlbWVudCBhcyBkZWZpbmVkIGlu IFtSRkM1NTYxXS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBBIG5ldyBvcHRpb25h bCBjYXBhYmlsaXR5IFRMViBpcyBkZWZpbmVkLCAnVGFyZ2V0ZWQgQXBwbGljYXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7IENhcGFiaWxpdHkgKFRBQyknLiBJdHMgZW5jb2RpbmcgaXMgYXMgZm9sbG93 czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHxVfEZ8IFRhcmdldGVkIEFwcC4gQ2FwLihJQU5BKXwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg TGVuZ3RoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfFN8Jm5ic3A7IFJlc2VydmVkJm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRhcmdldGVkIEFwcC4gQ2FwLiBkYXRhJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXMgZGVzY3JpYmVkIGluIFtSRkM1NTYxXTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVTogc2V0IHRvIDEuIElnbm9yZSwgaWYgbm90IGtub3du LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRjogU2V0IHRvIDAuIERvIG5vdCBmb3J3 YXJkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUzogTVVTVCBiZSBzZXQgdG8gMSBv ciAwIHRvIGFkdmVydGlzZSBvciB3aXRoZHJhdyB0aGUgVEFDIFRMVjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzcGVjdGl2ZWx5LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRhcmdldGVkIEFwcGxpY2F0aW9uIENh cGFiaWxpdHkgZGF0YTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEEgVGFyZ2V0ZWQgQXBwbGljYXRpb25zIENhcGFiaWxpdHkgZGF0YSBjb25zaXN0cyBvZiBub25l LCBvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yIG1vcmUg MzIgYml0IFRhcmdldGVkIEFwcGxpY2F0aW9uIEVsZW1lbnRzLiBJdHMgZW5jb2RpbmcgaXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIGZvbGxvd3M6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGFyZ2V0 ZWQgQXBwbGljYXRpb24gRWxlbWVudChUQUUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8RXwmbmJzcDsmbmJzcDsmbmJzcDsgVGFyZy4gQXBw bC4gSWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXNlcnZlZCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGFyZ2V0ZWQgQXBwbGljYXRpb24gSWRl bnRpZmllciAoVEEtSWQpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYSAxNiBiaXQgVGFyZ2V0ZWQgQXBwbGljYXRpb24gSWRlbnRpZmllciB2YWx1ZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtFLWJpdDog VGhlIGVuYWJsZSBiaXQgaW5kaWNhdGVzIHdoZXRoZXIgdGhlIHNlbmRlciBpczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWR2ZXJ0aXNpbmcgb3Igd2l0aGRyYXdp bmcgdGhlIFRBRS4gVGhlIEUtYml0IHZhbHVlIGlzIHVzZWQgYXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvbGxvd3M6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSAtIFRoZSBUQUUg aXMgYWR2ZXJ0aXNpbmcgdGhlIHRhcmdldGVkIGFwcGxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAtIFRoZSBUQUUgaXMgd2l0 aGRyYXdpbmcgdGhlIHRhcmdldGVkIGFwcGxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBsZW5ndGggb2YgVEFDIGRlcGVuZHMgb24gdGhlIG51 bWJlciBvZiBUQUVzLiBGb3IgaW5zdGFuY2UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBpZiB0d28gVEFFcyBhcmUgYWRkZWQsIHRoZSBsZW5ndGggaXMgc2V0IHRvIDkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5ORVc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBBbiBMU1IgTUFZ IGFkdmVydGlzZSB0aGF0IGl0IGlzIGNhcGFibGUgdG8gbmVnb3RpYXRlIGEgdGFyZ2V0ZWQgTERQ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyZuYnNwOyBhcHBsaWNhdGlvbiBsaXN0IG92ZXIgYSB0TERQIHNlc3Npb24g YnkgdXNpbmcgdGhlIENhcGFiaWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IEFkdmVydGlzZW1lbnQg YXMgZGVmaW5lZCBpbiBbUkZDNTU2MV0gYW5kIGVuY29kZWQgYXMgZm9sbG93czo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxVfEZ8IFRMViBDb2RlIFBv aW50Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGVuZ3RoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfFN8IFJlc2VydmVkJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDYXBhYmlsaXR5IERhdGEmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgb3B0aW9uYWwgY2FwYWJp bGl0eSBUTFYgb2YgdHlwZSBUQkQxIGNhbGxlZCAnVGFyZ2V0ZWQgQXBwbGljYXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7IENhcGFiaWxpdHkgKFRBQyknLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgRmxhZyAm cXVvdDtVJnF1b3Q7IE1VU1QgYmUgc2V0IHRvIDEgdG8gaW5kaWNhdGUgdGhhdCB0aGlzIGNhcGFi aWxpdHkgbXVzdCBiZSBzaWxlbnRseSBpZ25vcmVkIGlmIHVua25vd24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZu YnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7SXQncyBlbmNvZGVkIGFzIGZvbGxvd3M6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGFy Z2V0ZWQgQXBwbGljYXRpb24gRWxlbWVudChUQUUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8RXwmbmJzcDsmbmJzcDsmbmJzcDsgVGFyZy4g QXBwbC4gSWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXNlcnZl ZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IDxvOnA+DQo8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUYXJnZXRlZCBBcHBsaWNhdGlvbiBJZGVudGlmaWVyIChU QS1JZCk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIDE2IGJp dCBUYXJnZXRlZCBBcHBsaWNhdGlvbiBJZGVudGlmaWVyIHZhbHVlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEUtYml0OiBUaGUgZW5hYmxl IGJpdCBpbmRpY2F0ZXMgd2hldGhlciB0aGUgc2VuZGVyIGlzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZHZlcnRpc2luZyBvciB3aXRoZHJhd2luZyB0aGUgVEFF LiBUaGUgRS1iaXQgdmFsdWUgaXMgdXNlZCBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxIC0gVGhlIFRBRSBpcyBhZHZlcnRp c2luZyB0aGUgdGFyZ2V0ZWQgYXBwbGljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwIC0gVGhlIFRBRSBpcyB3aXRoZHJhd2luZyB0 aGUgdGFyZ2V0ZWQgYXBwbGljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj7CpzIuMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtJZiB0aGUgdExEUCBzZXNzaW9uIGNoYW5n ZXMgdG8gbGluayBzZXNzaW9uLCBhIExTUiBzaG91bGQgd2l0aGRyYXcgaXQmcXVvdDsuLi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+OnMvc2hvdWxkL1NIT1VMRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Li4uJnF1b3Q7d2l0aCBTIGJp dCBzZXQgdG8gMCwgd2hpY2ggaW5kaWNhdGVzIHdpbGRjYXJkIHdpdGhkcmF3YWwgb2YgYWxsIFRB RSBlbGVtZW50cy4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hlcmUgaXMgdGhpcyBiZWhhdmlvciBkZWZpbmVkPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5NeSByZWFkaW5nIG9mIFJGQzUwMzYgaXMgdGhhdCBzZW5kaW5nIHRoZSBjYXBhYmlsaXR5 IHdpdGggdGhlIFMgYml0IHNldCB0byAwIG1lYW5zIHdpdGhkcmF3aW5nIHRoZSBjYXBhYmlsaXR5 LiBJbiB3aGljaCBjYXNlIHRoaXMgZG9jdW1lbnRzIHN0YXRlcyB0aGF0ICZxdW90O0lmIHRoZSBy ZWNlaXZlciBMU1IgZG9lcyBub3QgcmVjZWl2ZSB0aGUgVEFDIFRMViBpbiB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7IEluaXRpYWxpemF0aW9uIG1lc3NhZ2Ugb3IgaXQgZG9lcyBub3QgdW5kZXJzdGFu ZCB0aGUgVEFDIFRMViwgdGhlIFRBQyBuZWdvdGlhdGlvbiBNVVNUIGJlIGNvbnNpZGVyZWQgdW5z dWNjZXNzZnVsIGFuZCB0aGUgc2Vzc2lvbiBlc3RhYmxpc2htZW50IE1VU1QgcHJvY2VlZCBhcyBw ZXIgW1JGQzUwMzZdLiZxdW90OyBpLmUuIHRoZSB0TERQIHNlc3Npb25zIHN0YXlzIHVwLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGlzIGlzIG5vdCB0aGUgc2FtZSBhcyAmcXVvdDt3aWxkY2FyZCB3aXRoZHJhd2FsIG9mIGFs bCBUQUUgZWxlbWVudHMmcXVvdDsgd2hpY2ggbWVhbnMgdGhhdCB0aGUgVEFDIGNhcGFiaWxpdHkg aXMgYWR2ZXJ0aXNlZCB3aXRoIG5vIFRBLUlkLCBpdCB0aGUgdExEUCBzZXNzaW9ucyB3aWxsIGJl IGNsb3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPsKnMi4yPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5PTEQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyAmcXVvdDtBbHNvLCBjdXJyZW50bHkgdGhlIHJl bW90ZSBMU1IgYWNjZXB0cyBhc3ltbWV0cmljIGV4dGVuZGVkIEhlbGxvcyBieTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsgZGVmYXVsdCBvciBieSBhcHByb3ByaWF0ZSBjb25maWd1cmF0aW9uLiBXaXRoIHRo aXMgZG9jdW1lbnQsIHRoZSBMU1I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IE1VU1QgYWNjZXB0IHRMRFAg aGVsbG9zIGluIG9yZGVyIHRvIHRoZW4gYWNjZXB0IG9yIHJlamVjdCB0aGUgdExEUDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsgc2Vzc2lvbiBiYXNlZCBvbiB0aGUgYXBwbGljYXRpb24gaW5mb3JtYXRpb24u JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hhdCBpcyB0aGUgZ29hbCBvZiB0aGlz IHBhcmFncmFwaD8gSSdtIHJlYWRpbmcgdGhhdCBhIExTUiBtYXkgbm90IGJlIGNvbmZpZ3VyZWQg YW55bW9yZSB0byByZWplY3QgdExEUCBoZWxsb3MuIFdoeSBub3Q/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgd291bGQgcHJv cG9zZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5ORVc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7QnkgZGVmYXVsdCwgTFNSIFNIT1VMRCBhY2NlcHQg dExEUCBoZWxsb3MgaW4gb3JkZXIgdG8gdGhlbiBhY2NlcHQgb3IgcmVqZWN0IHRoZSB0TERQPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyZuYnNwOyBzZXNzaW9uIGJhc2VkIG9uIHRoZSBhcHBsaWNhdGlvbiBpbmZvcm1h dGlvbi4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7IMKnMi4zLjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEuIFRoZSBTLWJpdCBv ZiB0aGUgVGFyZ2V0ZWQgQXBwbGljYXRpb24gQ2FwYWJpbGl0eSBUTFYgTVVTVCBiZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2V0IHRvIDEgdG8gYWR2ZXJ0aXNlIFRhcmdldGVkIEFw cGxpY2F0aW9uIENhcGFiaWxpdHkgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBT SE9VTEQgYmUgaWdub3JlZCBvbiB0aGUgcmVjZWlwdC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgYmVoYXZpb3IgaXMgZGVmaW5lZCBpbiBSRkMgNTU2MS4g SSBkb24ndCB0aGluayB0aGF0IGl0J3MgZ29vZCBwcmFjdGljZSB0byByZWRlZmluZSBpdC4mbmJz cDsgSSdkIHJhdGhlciBoYXZlIHRoaXMgc2VudGVuY2UgZGVsZXRlZC4gQWx0ZXJuYXRpdmVseSwg aXQgc2hvdWxkIGJlIG1hZGUgbm9uIG5vcm1hdGl2ZSBhbmQgcmVmZXIgdG8gUkZDIDU1NjEuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj7CpzIuMy4xPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90OyAyLiBUaGUgRS1iaXQgb2YgdGhlIFRh cmdldGVkIEFwcGxpY2F0aW9uIEVsZW1lbnQgTVVTVCBiZSBzZXQgdG8gMSB0bzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5hYmxlIFRhcmdldGVkIGFwcGxpY2F0aW9uIGFuZCBTSE9V TEQgYmUgaWdub3JlZCBvbiB0aGUgcmVjZWlwdC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB1 bmRlcnN0YW5kIHRoYXQgeW91IGFyZSBtaW1pY2tpbmcgdGhlIGJlaGF2aW9yIG9mIHRoZSBTLWJp dC4gSXQgbG9va3MgZGViYXRhYmxlIHRvIGlnbm9yZSB0aGlzIGRpcmVjdCBwcm90b2NvbCB2aW9s YXRpb24gYW5kIGFjY2VwdCB0aGUgVEFFIHdoaWxlIHRoZSBzcGVha2VyIGV4cHJlc3NlZCBpdHMg d2lsbGluZXNzIHRvIHdpdGhkcmF3IGl0LiBJIHdvdWxkIHBlcnNvbm5hbHkNCiBiZSBlbmNsaW5l ZCB0byBpZ25vcmUgdGhlIFRBRSBhZHZlcnRpc2Ugd2l0aCB0aGUgRS1iaXQgY2xlYXJlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPi0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+wqcyLjMuMjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlIFMtYml0IGlzIHNldCB0byAwLCB0aGUgVEFDIGlzIGRp c2FibGVkIGZvciB0aGUgc2Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFm dGVyIHRoYXQsIHRoZSBzZXNzaW9uIG1heSByZW1haW4gaW4gZXN0YWJsaXNoZWQgc3RhdGUgb3I8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvcm4gZG93biBiYXNlZCBvbiBbUkZDNTAz Nl0gcnVsZXMuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SU1PLCBpZiBUQUMgaXMgZGlzYWJsZWQsIHRoZSBzZXNzaW9uIE1VU1QgYmVoYXZlIGFz IHBlciBSRkM1MDM2IHJ1bGVzLiAoaW4gcGFydGljdWxhciwgSSBkb24ndCBzZWUgYSByZWFzb24g dG8gdGVhciBkb3duIHRoZSBzZXNzaW9uLCBidXQgSSBkbyBzZWUgYSByZWFzb24gdG8gYWR2ZXJ0 aXNlIGFsbCBGRWMgbWFwcGluZ3Mgd2hpY2ggd2hlcmUgcHJldmlvdXNseSBmaWx0ZXJlZA0KIGJh c2VkIG9uIFRBLUlkIG5lZ29jaWF0aW9uLikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj7CpzIuMy4yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmcXVvdDs1LiBJZiB0aGUg Uy1iaXQgaXMgc2V0IHRvIDEsIGEgTFNSIHByb2Nlc3MgYSBsaXN0IG9mIFRBRXMgZnJvbTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVEFDcyBjYXBhYmlsaXR5IGRhdGEgd2l0aCBFLWJp dCBzZXQgdG8gMSBvciAwIHRvIHVwZGF0ZSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHBlZXJzIFRBRS4gQWxzbywgaXQgdXBkYXRlcyB0aGUgbmVnb3RpYXRlZCBUQUUgbGlzdCBv dmVyIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdExEUCBzZXNzaW9uLiZxdW90 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoYXQncyBu ZXcgY29tcGFyZWQgdG8gdGhlIGFscmVhZHkgZGVmaW5lZCBwb2ludHMgMSwgMiBhbmQgMz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+SWYgdGhpcyBwb2ludCA1IGlzIGtlcHQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyA6cy9wZWVycy9wZWVyJ3Mm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwO1doYXQgZG9lcyB0aGUgc2Vjb25kIHNl bnRlbmNlIGFkZHMgdG8gdGhlIGZpcnN0IG9uZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij7CpzM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+UGVyc29uYWxseSwgSSB3b3VsZCBwcmVmZXIgdGhhdCB0aGUgYXJyYXkgYWxz byBpbmNsdWRlIHRoZSBub3JtYXRpdmUgY29kZSBwb2ludHMgKHJhdGhlciB0aGFuIHJlcXVpcmlu ZyBhbiBpbmRpcmVjdGlvbiBpbiB0aGUgSUFOQSBzZWN0aW9uKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+wqcy LjM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+V2h5IGRvZXMgdGhlIGRvY3VtZW50IG1hbmRhdGVzIHRoYXQgVEFFIGJlIHN5bW1l dHJpY2FsbHkgbmVnb3RpYXRlZD8mbmJzcDsgSGVyZSB3ZSBhcmUgbm90IG5lZ290aWF0ZWQgY2Fw YWJpbGl0aWVzIHdoaWNoIHJlcXVpcmVzIGJvdGggZW5kcyB0byBzdXBwb3J0IHRoZSBjYXBhYmls aXR5IGJlZm9yZSBpdHMgdXNhZ2UuIFdlIGFyZSBtb3N0bHkgYWR2ZXJ0aXNpbmcgdGhlIHdpbGxp bmduZXNzDQogb2Ygb25lIExTUiB0byByZWNlaXZlIEZFQyBtYXBwaW5ncyBmcm9tIGl0cyBwZWVy LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5lLmcuIGxldCdzIHRha2UgdGhlIFJMRkEgYXBwbGljYXRpb24gd2hpY2ggaGFzIGFz eW1tZXRyaWMgbmVlZHMuIFRoZSBQTFIgaXMgd2lsbGluZyB0byBnZXQgdGhlIElQIHByZWZpeGVz IG1hcHBpbmcgZnJvbSB0aGUgbWVyZ2UgcG9pbnQgKFBRIG5vZGUpLiBCdXQgaXRzIHBlZXIgKHRo ZSBtZXJnZSBwb2ludCkgaXMgbm90IHdpbGxpbmcgdG8gZ2V0IGFueSBtYXBwaW5nLiBTbyB3aHkN CiB3b3VsZCBpdCBuZWVkIHRvIHJlY2VpdmUgbWFwcGluZ3Mgb2Ygbm8gaW50ZXJlc3QsIGFuZCB3 aHkgd291bGQgaXQgbmVlZCB0byBhZHZlcnRpc2UgVEFFIHdoaWNoIGRvZXMgbm90IGl0c2VsZj88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+VGhlIGRvY3VtZW50IGNvdWxkIGhhdmUgY2hvc2VuIGFuIGFzeW1tZXRyaWMgbW9kZWws IHdoZXJlIHRoZSBhZHZlcnRpc2VtZW50IG9mIGEgVEFFIG1lYW5zICZxdW90O0knZCBsaWtlIHRv IHJlY2VpdmUgdGhlIGNvcnJlc3BvbmRpbmcgRkVDIG1hcHBpbmdzJnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNvbWlu ZyBiYWNrIHRvIHRoZSBSTEZBIHVzZSBjYXNlLCB0aGlzIHJlcXVpcmVzIGNvbmZpZ3VyaW5nIHRo ZSBNZXJnZSBQb2ludCB3aXRoIHRoZSB3aWxsaW5nbmVzcyB0byBhZHZlcnRpc2UgUkxGQSBhcHBs aWNhdGlvbiwgaW5jbHVkaW5nIHdoZW4gUkxGQSBpbiBub3QgY29uZmlndXJlZCBvbiB0aGlzIG5v ZGUuIFNvIHRoaXMgaXMgYWRkaXRpb25hbCBjb25maWd1cmF0aW9uIHJlcXVpcmVtZW50Lg0KIElu IGFkZGl0aW9uLCBSTEZBIGlzIGRlc2lnbmVkIHRvIGJlIGFzeW1tZXRyaWMgaW4gbmF0dXJlLCB3 aXRoIGZlYXR1cmUgcmVxdWlyZW1lbnQgb25seSBvbiB0aGUgbG9jYWwgbm9kZS4gU3VjaCBkb2N1 bWVudCB3b3VsZCBub3cgcmVxdWlyZSBzb21lIHN1cHBvcnQgZm9yIFJMRkEgYXdhcmVuZXNzIG9u IHRoZSBNUCBub2RlIHdoaWNoIGlzIHVuZGVzaXJhYmxlLiBJIGd1ZXNzIHRoYXQgdGhpcyBpcyBu b3QgdG9vIGJhZCB0byBSTEZBIHdoaWNoIGlzDQogYSBwcmUtZXhpc3RpbmcgYXBwbGljYXRpb24s IGJ1dCB3aGF0IGFib3V0IGZ1dHVyZSBhcHBsaWNhdGlvbnMgd2hpY2ggd291bGQgYWxzbyBiZSBh c3ltZXRyaWM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj7CpzQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7V2l0aCB0aGUgU0FDLCB0 aGUgcmVzcG9uZGluZyBMU1IgaXMgbm90IGF3YXJlIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyB0YXJn ZXRlZCBhcHBsaWNhdGlvbnMuIFRodXMgaXQgbWF5IGJlIHVuYWJsZSB0byBjb21tdW5pY2F0ZSBp dHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGludGVyZXN0IG9yIGRpc2ludGVyZXN0IHRvIHJlY2VpdmUg c3RhdGUgaW5mb3JtYXRpb24gZnJvbSB0aGUgcGVlci4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5Tb3JyeSBidXQgSSBmYWlsIHRvIHNlZSB0aGUgbG9naWMgb3IgdGhlIHVzZSBjYXNl LiBPbmUgaXMgYSBwcmlvcmkgY2FwYWJsZSBvZiBjb21tdW5pY2F0ZSBpdHMgKF9vd25fKSBpbnRl cmVzdCwgaW5kZXBlbmRlbnRseSBvZiB0aGUgb25lcyBvZiBpdHMgcGVlci4gZS5nLiwgSWYgSSdk IGxpa2UgYSBiZWVyIGluIGEgcmVzdGF1cmFudCwgSSBhc2sgZm9yIGEgYmVlci4gKEkgZG9uJ3QN CiBuZWVkIHRvIHdhaXQgZm9yIHRoZSBtZW51LCBzbyBzZWUgd2hldGhlciBJIHdhbid0IGEgYmVl cik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90OyZuYnNwOyBUaGVyZWZvcmUsIHdoZW4gdGhlIHJl c3BvbmRpbmcgTFNSIGlzIG5vdCBhd2FyZSBvZiB0YXJnZXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsg YXBwbGljYXRpb25zIHN1Y2ggYSByZW1vdGUgTEZBIGFuZCBCR1AgYXV0byBkaXNjb3ZlcmVkIHBz ZXVkb3dpcmVzLCZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwO1RBQyBtZWNoYW5pc20g c2hvdWxkIGJlIHVzZWQgYW5kIHdoZW4gdGhlIHJlc3BvbmRpbmcgTFNSIGlzIGF3YXJlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyAod2l0aCBhcHByb3ByaWF0ZSBjb25maWd1cmF0aW9uKSBvZiB0YXJnZXRl ZCBhcHBsaWNhdGlvbnMgc3VjaCBhcyBGRUM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IDEyOCBwc2V1ZG93 aXJlLCBTQUMgbWVjaGFuaXNtIHNob3VsZCBiZSB1c2VkLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPldlbGwsIGFzIGFscmVhZHkgZXhwcmVzc2VkLCBJIGRvbid0IGZlZWwgdGhhdCBU QUMgaXMgd2VsbCBzdWl0ZWQgZm9yIHRoZSBSTEZBIGFwcGxpY2F0aW9uIGFzIGl0IGFkZHMgdGhl IHJlcXVpcmVtZW50IHRvIGNvbmZpZ3VyZSBib3RoIGVuZHMuIChtb3JlIHNwZWNpZmljYWxseSB0 aGUgTWVyZ2UgUG9pbnQpLiBJbiB3aGljaCBjYXNlLCBhcyBwZXIgeW91ciBhYm92ZSB0ZXh0LA0K IFNBQyBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkIG9mIFRBQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgTERQIGhhcyBhbHJl YWR5IGEgd2F5IHRvIGNvbnRyb2wgRkVDL3N0YXRlIGFkdmVydGlzZW1lbnQgKGFzIHBlciBSRkMg NzQ3MyksIEkgZmVlbCB0aGF0IGFkZGluZyB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IGluIFRBQyBp cyByZWR1bmRhbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPsKn NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mcXVvdDtUaGUgc2V0IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBhcHBsaWNhdGlvbnMg bmVnb3RpYXRlZCBieSB0aGUgVEFDIG1lY2hhbmlzbSBpcyBzeW1tZXRyaWMgYmV0d2VlbiB0aGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7IHR3byBMRFAgcGVlcnMuJnF1b3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+b2suIGZvciB0aGUgX25lZ29jaWF0ZWRfIGFwcGxpY2F0aW9ucy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZxdW90O0luIHRoZSBhYnNlbmNlIG9mIGZ1cnRoZXIgbWVjaGFuaXNtcywgdHdv IExEUCBwZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgd2lsbCBib3RoIGFkdmVydGlzZSBzdGF0ZSBp bmZvcm1hdGlvbiBmb3IgdGhlIHNhbWUgc2V0IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBhcHBsaWNh dGlvbnMuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hhdCBkbyB5b3UgbWVhbiBi eSAmcXVvdDtzdGF0ZSBpbmZvcm1hdGlvbiZxdW90Oz8gQXQgZmlyc3QgcmVhZGluZywgSSB1bmRl cnN0b29kICZxdW90O1RBRSZxdW90OyBidXQgdGhpcyB3b3VsZCBiZSBpbmNvcnJlY3QuIFNvIG5v dyBJIGd1ZXNzIHRoYXQgeW91IG1lYW4gJnF1b3Q7RkVDIG1hcHBpbmdzJnF1b3Q7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+VXNhZ2UgKG5ldyBzZWN0aW9uKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UbyBhbGxvdyBm b3IgaW5jcmVtZW50YWwgZGVwbG95bWVudCBvZiBuZXcgVEFJIGFzIHdlbGwgYXMgcHJpdmF0ZSB1 c2FnZSBieSBhIG5ldHdvcmsgb3BlcmF0b3IsIEkgdGhpbmsgdGhlIGNvbmZpZ3VyYXRpb24gU0hP VUxEIGFsbG93IHRoZSBjb25maWd1cmF0aW9uIG9mIGFueSBUQUkgKGluY2x1ZGluZyB0aGUgb25l cyB1bmtub3duIGZyb20gdGhlIGltcGxlbWVudGF0aW9uKSBvbg0KIGJvdGggdGhlIHNlbmRpbmcg c2lkZSBhbmQgdGhlIHJlY2VpdmluZyBzaWRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+wqc0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZx dW90O1RoZSBUQUMgbWVjaGFuaXNtIE1VU1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHRha2UgcHJlY2Vk ZW5jZSBvdmVyIHRoZSBTQUMgbWVjaGFuaXNtIHdpdGggcmVzcGVjdCB0byBlbmFibGluZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsgYXBwbGljYXRpb25zIGZvciB3aGljaCBzdGF0ZSBpbmZvcm1hdGlvbiB3 aWxsIGJlIGFkdmVydGlzZWQuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SXMgdGhp cyBub3QgYSBjYXNlIHdoZXJlIHRoZSBkb2N1bWVudCBtZXRhIGRhdGEgc2hvdWxkIGluZGljYXRl IHRoYXQgdGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyA3NDczPyZuYnNwOyZuYnNwOw0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pi0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj7CpzM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7SVB2NCBpbnRyYS1hcmVhIEZFQ3MmcXVvdDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+SXMgdGhpcyBqdXN0IGEgbmFtZSBvZiBhcHBsaWNhdGlvbiwgb3IgaXMgdGhlcmUgYSBzcGVj aWZpYyBiZWhhdmlvciBhc3NvY2lhdGVkIHdpdGggaXQ/IChlLmcuIG9ubHkgYWR2ZXJ0aXNpbmcg dGhlIElQdjQgRkVDIGZyb20gbXkgYW4gYXJlYS4pIElmIHNvLCB0aGUgYmVoYXZpb3Igc2hvdWxk IGJlIHNwZWNpZmllZC4gQW5kIHBsZWFzZSBjbGFyaWZ5IHdoZXRoZXIgdGhpcyBpcw0KIHRoZSBh cmVhIG9mIHRoZSBzZW5kZXIgb3Igb2YgdGhlIHJlY2VpdmVyLCBhcyBpbiB0aGUgZ2VuZXJhbCBj YXNlLCB0aGV5IG1heSBiZSBpbiBhIGRpZmZlcmVudCBhcmVhLiBBbmQgY2xhcmlmeSB0aGUgYmVo YXZpb3IgZm9yIElTLUlTIGxldmVsIDIgbm9kZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_53C29892C857584299CBF5D05346208A0F9FC3B9OPEXCLILM21corp_-- From nobody Tue Oct 11 05:16:35 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFF2129534; Tue, 11 Oct 2016 05:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKqW0IDXzugB; Tue, 11 Oct 2016 05:16:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DAB012948F; Tue, 11 Oct 2016 05:16:31 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 86F87C9D0A01E; Tue, 11 Oct 2016 12:16:26 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9BCGSJW010745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Oct 2016 12:16:29 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u9BCGSiR002083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Oct 2016 14:16:28 +0200 Received: from [135.224.203.10] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 11 Oct 2016 14:16:28 +0200 Message-ID: <57FCD81B.3070408@nokia.com> Date: Tue, 11 Oct 2016 14:16:27 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> In-Reply-To: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: Cc: 'mpls' Subject: Re: [mpls] WG adoption requested for draft-psarkar-spring-mpls-anycast-segments X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 12:16:33 -0000 WG, this document is now adopted. Authors, please republish as draft-ietf-spring-mpls-anycast-segments-00 thanks -m Le 24/07/2016 14:39, John G. Scudder a crit : > Dear WG (and cc MPLS, please include SPRING in replies), > > As we discussed at our meeting, working group adoption has been requested for draft-psarkar-spring-mpls-anycast-segments. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. > > We will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. Also, the length of the author list for this document exceeds the maximum recommended. Assuming the document is adopted, the authors should be prepared to correct this when submitting as a WG document, ideally by reducing the list to simply the active editor(s) and making use of the "contributors" section for the full list. > > Thanks, > > --Bruno and John > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Tue Oct 11 05:48:15 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43080129553; Tue, 11 Oct 2016 05:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHEotuz0yrq8; Tue, 11 Oct 2016 05:48:06 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 F3CF0129555; Tue, 11 Oct 2016 05:48:00 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id t192so11721508ywf.0; Tue, 11 Oct 2016 05:48:00 -0700 (PDT) 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; bh=9min/f6ZsEb/XJ7/3EJGRzCRG/Zh0KNurNFf4kGScqI=; b=MDNZ88IGPbUaET5sOqA8sL7pATVUulDZvjA35FdpQj/QXD3sG6EGg9NjfJkLP+mQBC Pj6y7dCH8lowzoHyylRO0PfarGy3OjHMemuT6sEeWgG+NTJ2oykY5bfv4DB4sXA7zhZL rH7E3oN3T8jGoAlkGcOm0klusV6yYxDhCpuZrRh8jD1dGbV6bH2TDWnx58zW2DDddlKl bOhJ0mHsBeE1xDNJrLf/CVoAsUdjBHhQrcxI9IKmmruaPjwXbezsCLxXYlSUZZlMnxPT z5eEXsMXPISUHeg/K4lwhljmFllcUmSMVEKgwYJdIN1xY8iftUpkdLJsfxJajKDhbEfN 9oUg== 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; bh=9min/f6ZsEb/XJ7/3EJGRzCRG/Zh0KNurNFf4kGScqI=; b=JNE+5VbKd+ZphZ4qv/RxfousjqcM9dv8Hev6qpUOCX9s3V+Ik9WV1IK5c5VFzkuaxL kavdJPVqg1mzLoYwAnL3i4aQJrJYbj71wCduII+JvxHBIoaXl0wPbjpGHuZEZPascFn1 FVmPnv0RuaPSiss1Bo1/WUdwm4h8aEuWlLfEvYtQlEAJm8+OyuTMBEdoq4Z/kN6+4+EY MS5doxrdU/MPeljXnLzh0xKSHcWA0hwL48ZfpHQjXKlNF2VA7oPKBALQwhnBdSuQAzZJ GvvwZbQaTIYnvLjsf6PvB/Q9NyvOEShVH6W8qc+sCNFrjt8UCZdfE8Vg7qvEdxDcO43w SZcQ== X-Gm-Message-State: AA6/9RlL1PddyJobUZgsBVOviPlj/vaCVVDD5ioh7PTalTLYlOmikBaAB3pSDCjUV5mMgjstmms6xOqyGz7sRA== X-Received: by 10.129.93.4 with SMTP id r4mr3278563ywb.15.1476190080231; Tue, 11 Oct 2016 05:48:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.174.16 with HTTP; Tue, 11 Oct 2016 05:47:58 -0700 (PDT) In-Reply-To: <57FCD81B.3070408@nokia.com> References: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> <57FCD81B.3070408@nokia.com> From: Pushpasis Sarkar Date: Tue, 11 Oct 2016 18:17:58 +0530 Message-ID: To: Martin Vigoureux Content-Type: multipart/alternative; boundary=001a114da01e5a6bee053e964987 Archived-At: Cc: mpls , spring@ietf.org Subject: Re: [mpls] [spring] WG adoption requested for draft-psarkar-spring-mpls-anycast-segments X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 12:48:13 -0000 --001a114da01e5a6bee053e964987 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Martin, Thanks a lot for the follow up :) I have uploaded draft-ietf-spring-anycast-segments-00. Best Regards, -Pushpasis On Tue, Oct 11, 2016 at 5:46 PM, Martin Vigoureux < martin.vigoureux@nokia.com> wrote: > WG, > > this document is now adopted. > Authors, please republish as draft-ietf-spring-mpls-anycast-segments-00 > > thanks > -m > > Le 24/07/2016 14:39, John G. Scudder a =C3=A9crit : > >> Dear WG (and cc MPLS, please include SPRING in replies), >> >> As we discussed at our meeting, working group adoption has been requeste= d >> for draft-psarkar-spring-mpls-anycast-segments. Please reply to the list >> with your comments, including although not limited to whether or not you >> support adoption. Non-authors are especially encouraged to comment. >> >> We will end the call on August 31, 2015. >> >> Authors, please indicate whether you are aware of any relevant IPR and i= f >> so, whether it has been disclosed. Also, the length of the author list f= or >> this document exceeds the maximum recommended. Assuming the document is >> adopted, the authors should be prepared to correct this when submitting = as >> a WG document, ideally by reducing the list to simply the active editor(= s) >> and making use of the "contributors" section for the full list. >> >> Thanks, >> >> --Bruno and John >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --001a114da01e5a6bee053e964987 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks a lot for the follow = up :) I have uploaded draft-ietf-spring-anycast-segments-00.

=
Best Regards,
-Pushpasis


On Tue, Oct 11, 2016= at 5:46 PM, Martin Vigoureux <martin.vigoureux@nokia.com>= wrote:
WG,

this document is now adopted.
Authors, please republish as draft-ietf-spring-mpls-anycast-segments-0= 0

thanks
-m

Le 24/07/2016 14:39, John G. Scudder a =C3=A9crit :
Dear WG (and cc MPLS, please include SPRING in replies),

As we discussed at our meeting, working group adoption has been requested f= or draft-psarkar-spring-mpls-anycast-segments. Please reply to the lis= t with your comments, including although not limited to whether or not you = support adoption. Non-authors are especially encouraged to comment.

We will end the call on August 31, 2015.

Authors, please indicate whether you are aware of any relevant IPR and if s= o, whether it has been disclosed. Also, the length of the author list for t= his document exceeds the maximum recommended. Assuming the document is adop= ted, the authors should be prepared to correct this when submitting as a WG= document, ideally by reducing the list to simply the active editor(s) and = making use of the "contributors" section for the full list.

Thanks,

--Bruno and John

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


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

--001a114da01e5a6bee053e964987-- From nobody Tue Oct 11 12:07:29 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFAA129687; Tue, 11 Oct 2016 12:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.516 X-Spam-Level: X-Spam-Status: No, score=-17.516 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFSAvi2tMB9a; Tue, 11 Oct 2016 12:07:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F42129684; Tue, 11 Oct 2016 12:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6323; q=dns/txt; s=iport; t=1476212845; x=1477422445; h=from:to:cc:subject:date:message-id:mime-version; bh=0o8EBW6q1OgY3pKA60XX5vEPGQLuQTRx/1/2vTgADUU=; b=Ik+htpliwv8zhdFRyMwptuYqBgdzqocFuoQFc6s7VxgL6Wr2hDgUv5TH aniCbYvrGOOCngUwpMs06i54T7me6hIjwfb+jI/mAooPDHeEmMmS+NdRK 56pzN9wIjb3sly3EjH5WWB5BUi3tbBK2bYI+g+y3lTQ7euP6fwvSQVqjH o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAQBBN/1X/5BdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgwc1AQEBAQEdgVMHAY0rpiOFFIILhiCCCTgUAQIBAQEBAQEBXieEYQE?= =?us-ascii?q?CBClQEgECFwMBAiQEORQJCgQBDQWIUMMvAQEBAQEBAQECAQEBAQEBAQEgjysRA?= =?us-ascii?q?TyFIh0FjniFMIVaAY98gW6EZ4kghxCFaYN+AR42TYMmgTpyhkSBIAF/AQEB?= X-IronPort-AV: E=Sophos;i="5.31,330,1473120000"; d="scan'208,217";a="158648643" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2016 19:07:24 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u9BJ7OQG000385 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Oct 2016 19:07:24 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Oct 2016 14:07:24 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Tue, 11 Oct 2016 14:07:23 -0500 From: "Kamran Raza (skraza)" To: "mpls@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: Seeking WG and chairs feedback on LDP/mLDP Yang doc split [Re: [mpls] A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)] Thread-Index: AQHSI/KywiHy3+ADKkSsfe8TPCdXjA== Importance: high X-Priority: 1 Date: Tue, 11 Oct 2016 19:07:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.194.138] Content-Type: multipart/alternative; boundary="_000_D422ADDC1471D1skrazaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-ldp-mldp-yang@tools.ietf.org" Subject: [mpls] Seeking WG and chairs feedback on LDP/mLDP Yang doc split [Re: A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 19:07:27 -0000 --_000_D422ADDC1471D1skrazaciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello MPLS WG and WG chairs, [Refer to our email two weeks ago] Keeping in view some of the MPLS-RT review comments and the current size of= the join document (draft-ietf-mpls-ldp-mldp-yang), we, the authors, are th= inking of splitting the LDP/mLDP Yang model into two separate documents - o= ne for LDP and other for mLDP - and would like to get WG and chairs feedbac= k on this. Please comment/advise accordingly. Rgds. - Kamran (on behalf of authors) From: Syed Kamran Raza > Date: Tuesday, September 27, 2016 at 1:14 PM To: "mpls@ietf.org" >, "mpls-chairs@ietf.org" > Cc: "Rtg-yang-coord@ietf.org" >, "draft-ietf-mpls-ldp-mldp-yan= g@tools.ietf.org" > Subject: [mpls] A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-= mldp-yang) Hello MPLS WG and WG chairs, This email is to give a quick update on the current work being done on the= IETF LDP/mLDP Yang draft (draft-ietf-mpls-ldp-mldp-yang-00). * Multi-vendor team is meeting twice a month to progress on the model: * Cisco, Juniper, Huawei, Ciena, Ericsson, Nokia * The current focus of the team is to: * address remaining MPLS-RT comments * divide the model into "base" and "extended" features * general cleanup * We plan to submit a next revision before next IETF. * We also want to get feedback from WG/chairs on whether it makes sense= to divide this large document (which is already > 115 pages) into two sepa= rate documents - one covering LDP Yang and other mLDP yang. * We will still keep mLDP model dependent on LDP. * Please advise. Rgds. - Kamran (on behalf of authors) --_000_D422ADDC1471D1skrazaciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello MPLS WG and WG chairs,

[Refer to our email two weeks ago]

Keeping in view some of the MPLS-RT review comments and the current si= ze of the join document (draft-ietf-mpls-ldp-mldp-yang), we, the authors, a= re thinking of splitting the LDP/mLDP Yang model into two separate document= s – one for LDP and other for mLDP - and would like to get WG and chairs feedback on this. 

Please comment/advise accordingly.
Rgds.
—
Kamran 
(on behalf of authors)

From: Syed Kamran Raza <skraza@cisco.com>
Date: Tuesday, September 27, 2016 a= t 1:14 PM
To: "mpls@ietf.org" <mpls@i= etf.org>, "mpls-chairs@= ietf.org" <mpls-chairs@= ietf.org>
Cc: "Rtg-yang-coord@ietf.org" <Rtg-yang-coord@ietf.org>, "draft-ietf-mpls-ldp-mld= p-yang@tools.ietf.org" <draft-= ietf-mpls-ldp-mldp-yang@tools.ietf.org>
Subject: [mpls] A quick update on L= DP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)

Hello MPLS WG and WG chairs,

This email is to give a quick update on the current work being done on=  the IETF LDP/mLDP Yang draft (draft-ietf-mpls-ldp-mldp-yang-00).
  • Multi-vendor team is meeting twice a month to progress on the model:
    • Cisco, Juniper, Huawei, Ciena, Ericsson, Nokia
  • The current focus of the team is to:
    • address remaining MPLS-RT comments
    • divide the model into “= ;base” and “extended” features
    • general cleanup
  • We plan to submit a next revision before next IETF.
  • We also want to get feedback = from WG/chairs on whether it makes sense to divide this large document= (which is already > 115 pages) into two separate documents – one = covering LDP Yang and other mLDP yang.
    • We will still keep mLDP model dependent on LDP.
    • Please advise.<= /li>
Rgds.
—
Kamran 
(on behalf of authors)
--_000_D422ADDC1471D1skrazaciscocom_-- From nobody Wed Oct 12 07:19:40 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD8C12944D; Wed, 12 Oct 2016 07:19:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147628197730.27220.16782883627462291979.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 07:19:37 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-linear-protection-mib-10.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:19:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : MPLS Transport Profile Linear Protection MIB Authors : Kingston Smiler Selvaraj Venkatesan Mahalingam Vishwas Manral Daniel King Sam Aldrin Jeong-dong Ryoo Filename : draft-ietf-mpls-tp-linear-protection-mib-10.txt Pages : 45 Date : 2016-10-12 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing MPLS-Transport Profile (MPLS-TP) Linear Protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection-mib/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-tp-linear-protection-mib-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-linear-protection-mib-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 12 07:30:07 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153B51297A5; Wed, 12 Oct 2016 07:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.897 X-Spam-Level: X-Spam-Status: No, score=-104.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPWR_E50femJ; Wed, 12 Oct 2016 07:30:01 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E265512954C; Wed, 12 Oct 2016 07:30:00 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 12 Oct 2016 23:29:56 +0900 Received: from SMTP2.etri.info ([169.254.2.208]) by SMTP3.etri.info ([10.2.6.32]) with mapi id 14.01.0355.002; Wed, 12 Oct 2016 23:29:57 +0900 From: =?ks_c_5601-1987?B?t/nBpLW/?= To: Joan Cucchiara , Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-tp-linear-protection-mib@ietf.org" , "mpls-chairs@ietf.org" , "mib-doctors@ietf.org" Thread-Topic: MIB Dr. review of draft-ietf-tp-linear-mib-09 Thread-Index: AQHSIP5e0riTaryqu0uz9sjSdO93caCk5brD Date: Wed, 12 Oct 2016 14:29:57 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A29221AAD@SMTP2.etri.info> References: In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.26.37] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Benoit Claise Subject: [mpls] =?euc-kr?q?=C8=B8=BD=C5=3A_MIB_Dr=2E_review_of_draft-ietf-?= =?euc-kr?q?tp-linear-mib-09?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:30:03 -0000 RGVhciBKb2FuLA0KDQpUaGFuayB5b3Ugc28gbXVjaCBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1l bnRzLg0KQWxsIHlvdXIgY29tbWVudHMgaGFkIGJlZW4gaW5jb3Jwb3JhdGVkIGludG8gdGhlIHJl dmlzaW9uIHBvc3RlZCBhIGZldyBtaW51dGVzIGFnbyBhcyBmb2xsb3dzLg0KDQpOYW1lOiAgICAg ICAgICAgZHJhZnQtaWV0Zi1tcGxzLXRwLWxpbmVhci1wcm90ZWN0aW9uLW1pYg0KUmV2aXNpb246 ICAgICAgIDEwDQpUaXRsZTogICAgICAgICAgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSBMaW5lYXIg UHJvdGVjdGlvbiBNSUINCkRvY3VtZW50IGRhdGU6ICAyMDE2LTEwLTEyDQpHcm91cDogICAgICAg ICAgbXBscw0KUGFnZXM6ICAgICAgICAgIDQ1DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJvdGVj dGlvbi1taWItMTAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLXRwLWxpbmVhci1wcm90ZWN0aW9uLW1pYi8NCkh0bWxp emVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLXRw LWxpbmVhci1wcm90ZWN0aW9uLW1pYi0xMA0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24t bWliLTEwDQoNCldvdWxkIHlvdSBwbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgYW55IGZ1 cnRoZXIgY29tbWVudHMgb24gdGhpcyBkb2N1bWVudCBhdCB5b3VyIGVhcmxpZXN0IGNvbnZlbmll bmNlPw0KDQpCZXN0IHJlYWdyZHMsDQoNCkplb25nLWRvbmcNCg0KDQogDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQq6uLO9ILvntvc6IEpvYW4gQ3VjY2hpYXJhIFtq Y3VjY2hpYXJhLmlldGZAZ21haWwuY29tXQ0KurizvSCzr8KlOiAyMDE2s+IgMTC/+SA4wM8gxeS/ 5MDPIL/AwPwgOTo1Mw0Kud60wiC757b3OiBMb2EgQW5kZXJzc29uOyBtcGxzQGlldGYub3JnOyBk cmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24tbWliQGlldGYub3JnOyBtcGxzLWNo YWlyc0BpZXRmLm9yZzsgbWliLWRvY3RvcnNAaWV0Zi5vcmcNCsL8wbY6ILf5waS1vzsgQmVub2l0 IENsYWlzZQ0Kwaa48TogTUlCIERyLiByZXZpZXcgb2YgZHJhZnQtaWV0Zi10cC1saW5lYXItbWli LTA5DQoNCkF1dGhvcnMsDQoNClRoYW5rIHlvdSBmb3IgYWRkcmVzc2luZyB0aGUgY29tbWVudHMg c28gdGhvcm91Z2hseSwgYW5kIGVzcGVjaWFsbHkgZm9yDQpjbGFyaWZ5aW5nIHRoZSBleGFtcGxl IGluIHNlY3Rpb24gNy4gICAgTXVjaCBhcHByZWNpYXRlZC4NCg0KVGhlIE1JQiBjb21waWxlcyB3 aXRoIHNtaWxpbnQgYW5kIHNtaWNuZ1BSTy4gICBDb21tZW50cyBhcmUgYmVsb3cuDQoNClRoYW5r IHlvdSwNCi1Kb2FuDQoNCkNvbW1lbnRzOg0KLS0tLS0tLS0tLS0tLS0tLQ0KDQoxKSBTZWN0aW9u IDYuMSBSZWxhdGlvbnNoaXAgdG8gdGhlIE1QTFMgT0FNIE1haW50ZW5hbmNlIElkZW50aWZpZXJz IE1JQiBNb2R1bGUNCg0KICAgIlRoZSBtcGxzTHBzTWVDb25maWdUYWJsZSBlbnRyeSBpcyBleHRl bmRlZCBieSB0aGUgZW50cnkgaW4gdGhlDQogICBtcGxzT2FtSWRNZVRhYmxlIGRlZmluZWQgaW4g W1JGQzc2OTddLiINCg0KVGhlIGFib3ZlIHN0YXRlbWVudCBpcyBiYWNrd2FyZHMuLi4udGhpbmsg dGhlIGludGVudGlvbiBpcyB0byBzYXkgc29tZXRoaW5nIGxpa2U6DQpFbnRyaWVzIGluIHRoZSBt cGxzT2FtSWRNZVRhYmxlIFtSRkM3Njk3XSBhcmUgZXh0ZW5kZWQgYnkgZW50cmllcyBpbiB0aGUg bXBsc0xzcE1lQ29uZmlnVGFibGUuDQoNCjIpIGxhdGVyIGluIHRoaXMgc2FtZSBzZWN0aW9uLCBz ZWN0aW9uIDYuMQ0KDQogICAiQW4gZW50cnkgb2YgdGhpcyB0YWJsZSBpcyByZWxhdGVkIHRvIGEg c2luZ2xlIGVudHJ5IGluIG1wbHNPYW1JZE1lVGFibGUuIg0KDQpUaGUgYWJvdmUgaXMgY29uZnVz aW5nIGJlY2F1c2UgeW91J3ZlIGFscmVhZHkgZGlzY3VzcyB0aGUgc3BhcnNlIGF1Z21lbnRzIHJl bGF0aW9uc2hpcC4gIFBsZWFzZSByZW1vdmUNCnRoZSBhYm92ZSBzZW50ZW5jZS4NCg0KDQpNSUIg TW9kdWxlDQotLS0tLS0tLS0tLS0NCjMpICBtcGxzTHBzQ29uZmlnSW5kZXhOZXh0ICAtICAgcGxl YXNlIHJlbmFtZSB0byBtcGxzTHBzQ29uZmlnRG9tYWluSW5kZXhOZXh0Lg0KU2luY2UgdGhpcyBz Y2FsYXIgaXMgb25seSB1c2VkIGZvciB0aGUgbXBsc0xwc0NvbmZpZ0RvbWFpbkluZGV4IGluZGV4 J3MgdmFsdWVzLCB0aGUgbmFtZSBzaG91bGQgcmVmbGVjdCB0aGF0Lg0KTk9URTogIHRoaXMgbmFt ZSBjaGFuZ2Ugc2hvdWxkIGJlIHByb3BhZ2F0ZWQgZWxzZXdoZXJlIGluIHRoZSBkcmFmdC4gIFBs ZWFzZSBkbyBhIHNlYXJjaCBhbmQgcmVwbGFjZS4NCg0KNCkgbXBsc0xwc0NvbmZpZ0RvbWFpbklu ZGV4ICAoZWRpdG9yaWFsKQ0KICAiTWFuYWdlcnMgc2hvdWxkLi4uIg0KDQpzL01hbmFnZXJzL09w ZXJhdG9ycy8NCg0KDQo1KSBtcGxzTHBzQ29uZmlnQ29tbWFuZA0KV2h5IGlzIHRoZXJlIE5PIERF VkFMPyAgIFdvdWxkbid0ICJub0NtZCIgYmUgYW4gYXBwcm9wcmlhdGUgREVGVkFMPw0KDQoNCjYp IG1wbHNMcHNDb25maWdSb3dTdGF0dXMgREVTQ1JJUFRJT04gY2xhdXNlDQoNClJvd1N0YXR1cyBv YmplY3RzIHJlZmxlY3QgdGhlIHN0YXR1cyBvZiB0aGUgUm93LCBub3QgYSBkZXRlcm1pbmF0aW9u IG9mIHdoZXRoZXIgb3Igbm90IHZhbHVlcw0KYXJlICJhcHByb3ByaWF0ZSIuICBQbGVhc2UgcmVt b3ZlIHRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoaXMgREVTQ1JJUFRJT046DQoNCiAgICAgICAgICIu Li5BbiBlbnRyeSBtYXkgbm90IGV4aXN0IGluIHRoZSBhY3RpdmUgc3RhdGUgdW5sZXNzIGFsbA0K ICAgICAgICAgIG9iamVjdHMgaW4gdGhlIGVudHJ5IGhhdmUgYW4gYXBwcm9wcmlhdGUgdmFsdWUu Ig0KDQoNCjcpICBtcGxzTHBzQ29uZmlnRG9tYWluSW5kZXggYW5kIG1wbHNMcHNNZUNvbmZpZ0Rv bWFpbg0KDQpTaW5jZSBNSUJzIG9mdGVuIGdldCBzdHJpcHBlZCBvdXQgb2YgUkZDcywgdGhlIHJl bGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBtcGxzTHBzQ29uZmlnRG9tYWluSW5kZXggYW5kDQp0aGUg bXBsc0xwc01lQ29uZmlnRG9tYWluIG5lZWRzIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBNSUIgTW9k dWxlIGl0c2VsZi4NCg0KQm90aCBERVNDUklQVElPTiBjbGF1c2VzIG5lZWQgdG8gYmUgdXBkYXRl ZCB0byBkZXNjcmliZSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlc2Ugb2JqZWN0cy4gICBW ZXJiYWdlIHN1Y2ggYXMgIldoZW4gdGhlDQp2YWx1ZSBvZiBtcGxzTHBzQ29uZmlnRG9tYWluSW5k ZXggaXMgdGhlIHNhbWUgYXMgdGhlIHZhbHVlIG9mIG1wbHNMcHNNZUNvbmZpZ0RvbWFpbiwgdGhh dCBtZWFucy4uLiIgYW5kIHRoZW4gZXhwbGFpbiB3aGF0DQp0aGlzIG1lYW5zLg0KDQo4KSAgbXBs c0xwc01lQ29uZmlnRG9tYWluIERFU0NSSVBUSU9OIChlZGl0b3JpYWwpDQogICAgICAgICAiVGhp cyBvYmplY3QgaG9sZHMgdGhlIHZhbHVlIG9mIHByb3RlY3Rpb24gZG9tYWluIGluZGV4IHdoZXJl aW4NCiAgICAgICAgICB0aGlzIE1FIGluY2x1ZGVkIGluLg0KDQpzL2luY2x1ZGVkIGluL2lzIGlu Y2x1ZGVkLw0KDQotLS0NCg0KDQo= From nobody Wed Oct 12 11:08:31 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84395129510; Wed, 12 Oct 2016 11:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X8IY-HN0P26; Wed, 12 Oct 2016 11:08:28 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0117.outbound.protection.outlook.com [104.47.42.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 192AF129501; Wed, 12 Oct 2016 11:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qFtEkAhw22p7kMeRxM99h5dQE33aOL5aNewD2jYPowk=; b=SejSrXI9oSPu/xSbSGc5Jtc6q8kw6zWj8PSNaN6fo2wPvT+YI2VJIXz3MzUQGZoBfMLA1/qqMXhLFEfG0M1Yo+eA+geP3ZUh2ViYPJ8PlcK9UPb2eukouWDfqZP1RtXTxG4IpCAbeUrkK1Omq9AjeDAU6mimHSylgcslUC0nNNQ= Received: from DM5PR05MB2858.namprd05.prod.outlook.com (10.168.175.150) by DM5PR05MB2860.namprd05.prod.outlook.com (10.168.176.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Wed, 12 Oct 2016 18:08:26 +0000 Received: from DM5PR05MB2858.namprd05.prod.outlook.com ([10.168.175.150]) by DM5PR05MB2858.namprd05.prod.outlook.com ([10.168.175.150]) with mapi id 15.01.0669.008; Wed, 12 Oct 2016 18:08:26 +0000 From: Santosh Esale To: "Kamran Raza (skraza)" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [mpls] Seeking WG and chairs feedback on LDP/mLDP Yang doc split [Re: A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)] Thread-Index: AQHSI/KywiHy3+ADKkSsfe8TPCdXjKCkqgcA Importance: high X-Priority: 1 Date: Wed, 12 Oct 2016 18:08:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sesale@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-ms-office365-filtering-correlation-id: 40044a49-6f9b-48ca-becb-08d3f2cac3af x-microsoft-exchange-diagnostics: 1; DM5PR05MB2860; 7:D3CBtn2C8LWxPcY8vK5SLCl5MqeU3Ov+SQegQkr9xDh6FngNo9z2JI3RQU14ULu6q7t9G1BSL6duq9v87qnI2jsgVO7pST40D/K/cuH21yGrnRBzSKL8i5BqWWHYRHjsZiTspa3zNR5c2+8vGqgRQFoLBMWBsLd3c2SUhimqiSwMme96wuhUKCGt1ErpBZCGGKLjBsuO0ZOdU6UEt8BarX+SAZdyrISMvmdEHY7b/4DGt40R62nkSgPEoexYyqhAkDtkHSfAmPv06gcNqjtzxng0sDv/9d0plKIwG53PLel6P1Ho9s3MItqi5Q1DLwcpi2hLt8UTLymMTg0bpCNoRrfQdbRJFMo+waVMhMVkmPk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR05MB2860; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DM5PR05MB2860; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2860; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(199003)(189002)(377454003)(11100500001)(2906002)(5002640100001)(66066001)(4001350100001)(122556002)(2201001)(97736004)(68736007)(4326007)(87936001)(83506001)(8936002)(15650500001)(19580405001)(7846002)(86362001)(7736002)(36756003)(16236675004)(2900100001)(3660700001)(8676002)(76176999)(19580395003)(3280700002)(6116002)(81686999)(586003)(105586002)(102836003)(189998001)(3846002)(106356001)(50986999)(92566002)(99286002)(106116001)(81166006)(5660300001)(230783001)(81156014)(77096005)(10400500002)(2501003)(2950100002)(5001770100001)(54356999)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2860; H:DM5PR05MB2858.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D423C868D5D10sesalejunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2016 18:08:26.9361 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2860 Archived-At: Cc: "draft-ietf-mpls-ldp-mldp-yang@tools.ietf.org" Subject: Re: [mpls] Seeking WG and chairs feedback on LDP/mLDP Yang doc split [Re: A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 18:08:30 -0000 --_000_D423C868D5D10sesalejunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByZXNlbnQgZG9jdW1lbnQgd2hpY2ggaXMgYXJvdW5kIDExNSBwYWdlcyBsb25nIGlzIG9u bHkgZXhwZWN0ZWQgdG8NCmdldCBiaWdnZXIgYXMgd2UgYWRkIG1vcmUgb3BlcmF0aW9uYWwgc3Rh dGVzIGluIHRoZSB1cGNvbWluZyByZXZpc2lvbi4gUGxlYXNlDQpsZXQgdXMga25vdyB5b3VyIGNv bW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4NCg0KVGhhbmtzLA0KU2FudG9zaCAob24gYmVoYWxmIG9m IGF1dGhvcnMpDQpPbiAxMC8xMS8xNiwgMTI6MDcgUE0sICJtcGxzIG9uIGJlaGFsZiBvZiBLYW1y YW4gUmF6YSAoc2tyYXphKSIgPG1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Ygc2tyYXphQGNpc2NvLmNvbTxtYWlsdG86c2tyYXph QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIZWxsbyBNUExTIFdHIGFuZCBXRyBjaGFpcnMsDQoNCltS ZWZlciB0byBvdXIgZW1haWwgdHdvIHdlZWtzIGFnb10NCg0KS2VlcGluZyBpbiB2aWV3IHNvbWUg b2YgdGhlIE1QTFMtUlQgcmV2aWV3IGNvbW1lbnRzIGFuZCB0aGUgY3VycmVudCBzaXplIG9mIHRo ZSBqb2luIGRvY3VtZW50IChkcmFmdC1pZXRmLW1wbHMtbGRwLW1sZHAteWFuZyksIHdlLCB0aGUg YXV0aG9ycywgYXJlIHRoaW5raW5nIG9mIHNwbGl0dGluZyB0aGUgTERQL21MRFAgWWFuZyBtb2Rl bCBpbnRvIHR3byBzZXBhcmF0ZSBkb2N1bWVudHMg4oCTIG9uZSBmb3IgTERQIGFuZCBvdGhlciBm b3IgbUxEUCAtIGFuZCB3b3VsZCBsaWtlIHRvIGdldCBXRyBhbmQgY2hhaXJzIGZlZWRiYWNrIG9u IHRoaXMuDQoNClBsZWFzZSBjb21tZW50L2FkdmlzZSBhY2NvcmRpbmdseS4NClJnZHMuDQrigJQN CkthbXJhbg0KKG9uIGJlaGFsZiBvZiBhdXRob3JzKQ0KDQpGcm9tOiBTeWVkIEthbXJhbiBSYXph IDxza3JhemFAY2lzY28uY29tPG1haWx0bzpza3JhemFAY2lzY28uY29tPj4NCkRhdGU6IFR1ZXNk YXksIFNlcHRlbWJlciAyNywgMjAxNiBhdCAxOjE0IFBNDQpUbzogIm1wbHNAaWV0Zi5vcmc8bWFp bHRvOm1wbHNAaWV0Zi5vcmc+IiA8bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+ LCAibXBscy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3JnPiIgPG1w bHMtY2hhaXJzQGlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZz4+DQpDYzogIlJ0 Zy15YW5nLWNvb3JkQGlldGYub3JnPG1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZz4iIDxS dGcteWFuZy1jb29yZEBpZXRmLm9yZzxtYWlsdG86UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc+Piwg ImRyYWZ0LWlldGYtbXBscy1sZHAtbWxkcC15YW5nQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFm dC1pZXRmLW1wbHMtbGRwLW1sZHAteWFuZ0B0b29scy5pZXRmLm9yZz4iIDxkcmFmdC1pZXRmLW1w bHMtbGRwLW1sZHAteWFuZ0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWxk cC1tbGRwLXlhbmdAdG9vbHMuaWV0Zi5vcmc+Pg0KU3ViamVjdDogW21wbHNdIEEgcXVpY2sgdXBk YXRlIG9uIExEUC9tTERQIFlhbmcgbW9kZWwgKGRyYWZ0LWlldGYtbXBscy1sZHAtbWxkcC15YW5n KQ0KDQpIZWxsbyBNUExTIFdHIGFuZCBXRyBjaGFpcnMsDQoNClRoaXMgZW1haWwgaXMgdG8gZ2l2 ZSBhIHF1aWNrIHVwZGF0ZSBvbiB0aGUgY3VycmVudCB3b3JrIGJlaW5nIGRvbmUgb24gIHRoZSBJ RVRGIExEUC9tTERQIFlhbmcgZHJhZnQgKGRyYWZ0LWlldGYtbXBscy1sZHAtbWxkcC15YW5nLTAw KS4NCg0KICAqICAgTXVsdGktdmVuZG9yIHRlYW0gaXMgbWVldGluZyB0d2ljZSBhIG1vbnRoIHRv IHByb2dyZXNzIG9uIHRoZSBtb2RlbDoNCiAgICAgKiAgIENpc2NvLCBKdW5pcGVyLCBIdWF3ZWks IENpZW5hLCBFcmljc3NvbiwgTm9raWENCiAgKiAgIFRoZSBjdXJyZW50IGZvY3VzIG9mIHRoZSB0 ZWFtIGlzIHRvOg0KICAgICAqICAgYWRkcmVzcyByZW1haW5pbmcgTVBMUy1SVCBjb21tZW50cw0K ICAgICAqICAgZGl2aWRlIHRoZSBtb2RlbCBpbnRvIOKAnGJhc2XigJ0gYW5kIOKAnGV4dGVuZGVk 4oCdIGZlYXR1cmVzDQogICAgICogICBnZW5lcmFsIGNsZWFudXANCiAgKiAgIFdlIHBsYW4gdG8g c3VibWl0IGEgbmV4dCByZXZpc2lvbiBiZWZvcmUgbmV4dCBJRVRGLg0KICAqICAgV2UgYWxzbyB3 YW50IHRvIGdldCBmZWVkYmFjayBmcm9tIFdHL2NoYWlycyBvbiB3aGV0aGVyIGl0IG1ha2VzIHNl bnNlIHRvIGRpdmlkZSB0aGlzIGxhcmdlIGRvY3VtZW50ICh3aGljaCBpcyBhbHJlYWR5ID4gMTE1 IHBhZ2VzKSBpbnRvIHR3byBzZXBhcmF0ZSBkb2N1bWVudHMg4oCTIG9uZSBjb3ZlcmluZyBMRFAg WWFuZyBhbmQgb3RoZXIgbUxEUCB5YW5nLg0KICAgICAqICAgV2Ugd2lsbCBzdGlsbCBrZWVwIG1M RFAgbW9kZWwgZGVwZW5kZW50IG9uIExEUC4NCiAgICAgKiAgIFBsZWFzZSBhZHZpc2UuDQoNClJn ZHMuDQrigJQNCkthbXJhbg0KKG9uIGJlaGFsZiBvZiBhdXRob3JzKQ0K --_000_D423C868D5D10sesalejunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <84106F612E403F45A84C6B9EAE179B5F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+VGhl IHByZXNlbnQgZG9jdW1lbnQgd2hpY2ggaXMgYXJvdW5kIDExNSBwYWdlcyBsb25nIGlzIG9ubHkg ZXhwZWN0ZWQgdG8mbmJzcDs8L2Rpdj4NCjxkaXY+Z2V0IGJpZ2dlciBhcyB3ZSBhZGQgbW9yZSBv cGVyYXRpb25hbCBzdGF0ZXMgaW4gdGhlIHVwY29taW5nIHJldmlzaW9uLiBQbGVhc2UmbmJzcDs8 L2Rpdj4NCjxkaXY+bGV0IHVzIGtub3cgeW91ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0K PGRpdj5TYW50b3NoIChvbiBiZWhhbGYgb2YgYXV0aG9ycyk8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+T24gMTAvMTEv MTYsIDEyOjA3IFBNLCAmcXVvdDttcGxzIG9uIGJlaGFsZiBvZiBLYW1yYW4gUmF6YSAoc2tyYXph KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyI+bXBscy1i b3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpza3JhemFA Y2lzY28uY29tIj5za3JhemFAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJ T05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJ Tkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IZWxsbyBNUExT IFdHIGFuZCBXRyBjaGFpcnMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bUmVmZXIg dG8gb3VyIGVtYWlsIHR3byB3ZWVrcyBhZ29dPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5LZWVwaW5nIGluIHZpZXcgc29tZSBvZiB0aGUgTVBMUy1SVCByZXZpZXcgY29tbWVudHMgYW5k IHRoZSBjdXJyZW50IHNpemUgb2YgdGhlIGpvaW4gZG9jdW1lbnQgKGRyYWZ0LWlldGYtbXBscy1s ZHAtbWxkcC15YW5nKSwgd2UsIHRoZSBhdXRob3JzLCBhcmUgdGhpbmtpbmcgb2Ygc3BsaXR0aW5n IHRoZSBMRFAvbUxEUCBZYW5nIG1vZGVsIGludG8gdHdvIHNlcGFyYXRlIGRvY3VtZW50cyDigJMg b25lIGZvciBMRFAgYW5kIG90aGVyIGZvciBtTERQDQogLSBhbmQgd291bGQgbGlrZSB0byBnZXQg V0cgYW5kIGNoYWlycyBmZWVkYmFjayBvbiB0aGlzLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+UGxlYXNlIGNvbW1lbnQvYWR2aXNlIGFjY29yZGluZ2x5LjwvZGl2Pg0KPGRp dj5SZ2RzLjwvZGl2Pg0KPGRpdj4NCjxkaXY+4oCUPC9kaXY+DQo8ZGl2PkthbXJhbiZuYnNwOzwv ZGl2Pg0KPGRpdj4ob24gYmVoYWxmIG9mIGF1dGhvcnMpPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29s b3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVt IG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJ R0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1l ZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5Gcm9tOiA8L3NwYW4+U3llZCBLYW1yYW4gUmF6YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNr cmF6YUBjaXNjby5jb20iPnNrcmF6YUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgU2VwdGVtYmVyIDI3LCAy MDE2IGF0IDE6MTQgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwv c3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3Jn PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyI+bXBs cy1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBscy1jaGFp cnNAaWV0Zi5vcmciPm1wbHMtY2hhaXJzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86UnRn LXlhbmctY29vcmRAaWV0Zi5vcmciPlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIj5SdGcteWFuZy1jb29y ZEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxz LWxkcC1tbGRwLXlhbmdAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtbXBscy1sZHAtbWxkcC15 YW5nQHRvb2xzLmlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQt aWV0Zi1tcGxzLWxkcC1tbGRwLXlhbmdAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtbXBscy1s ZHAtbWxkcC15YW5nQHRvb2xzLmlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlttcGxzXSBBIHF1aWNrIHVwZGF0ZSBvbiBM RFAvbUxEUCBZYW5nIG1vZGVsIChkcmFmdC1pZXRmLW1wbHMtbGRwLW1sZHAteWFuZyk8YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGVsbG8gTVBMUyBXRyBhbmQgV0cgY2hhaXJzLDwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBlbWFpbCBpcyB0byBnaXZlIGEgcXVpY2sgdXBk YXRlIG9uIHRoZSBjdXJyZW50IHdvcmsgYmVpbmcgZG9uZSBvbiAmbmJzcDt0aGUgSUVURiBMRFAv bUxEUCBZYW5nIGRyYWZ0IChkcmFmdC1pZXRmLW1wbHMtbGRwLW1sZHAteWFuZy0wMCkuPC9kaXY+ DQo8dWw+DQo8bGk+TXVsdGktdmVuZG9yIHRlYW0gaXMgbWVldGluZyB0d2ljZSBhIG1vbnRoIHRv IHByb2dyZXNzIG9uIHRoZSBtb2RlbDoNCjx1bD4NCjxsaT5DaXNjbywgSnVuaXBlciwgSHVhd2Vp LCBDaWVuYSwgRXJpY3Nzb24sIE5va2lhPC9saT48L3VsPg0KPC9saT48bGk+VGhlIGN1cnJlbnQg Zm9jdXMgb2YgdGhlIHRlYW0gaXMgdG86DQo8dWw+DQo8bGk+YWRkcmVzcyByZW1haW5pbmcgTVBM Uy1SVCBjb21tZW50czwvbGk+PGxpPmRpdmlkZSB0aGUgbW9kZWwgaW50byDigJxiYXNl4oCdIGFu ZCDigJxleHRlbmRlZOKAnSBmZWF0dXJlczwvbGk+PGxpPmdlbmVyYWwgY2xlYW51cDwvbGk+PC91 bD4NCjwvbGk+PGxpPldlIHBsYW4gdG8gc3VibWl0IGEgbmV4dCByZXZpc2lvbiBiZWZvcmUgbmV4 dCBJRVRGLjwvbGk+PGxpPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDApOyI+V2UgYWxzbyB3YW50IHRvIGdldCBmZWVkYmFjayBmcm9tIFdHL2NoYWlycyBvbiB3 aGV0aGVyIGl0IG1ha2VzIHNlbnNlIHRvIGRpdmlkZSB0aGlzJm5ic3A7bGFyZ2UgZG9jdW1lbnQg KHdoaWNoIGlzIGFscmVhZHkgJmd0OyAxMTUgcGFnZXMpIGludG8gdHdvIHNlcGFyYXRlIGRvY3Vt ZW50cyDigJMgb25lIGNvdmVyaW5nIExEUCBZYW5nIGFuZCBvdGhlciBtTERQIHlhbmcuPC9zcGFu Pg0KPHVsPg0KPGxpPldlIHdpbGwgc3RpbGwga2VlcCBtTERQIG1vZGVsIGRlcGVuZGVudCBvbiBM RFAuPC9saT48bGk+UGxlYXNlIGFkdmlzZS48L2xpPjwvdWw+DQo8L2xpPjwvdWw+DQo8ZGl2PlJn ZHMuPC9kaXY+DQo8ZGl2PuKAlDwvZGl2Pg0KPGRpdj5LYW1yYW4mbmJzcDs8L2Rpdj4NCjxkaXY+ PGZvbnQ+KG9uIGJlaGFsZiBvZiBhdXRob3JzKTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_D423C868D5D10sesalejunipernet_-- From nobody Wed Oct 12 20:49:30 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072D91297E9; Wed, 12 Oct 2016 20:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.217 X-Spam-Level: X-Spam-Status: No, score=-7.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DA6e0P_OuqPu; Wed, 12 Oct 2016 20:49:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD591297E8; Wed, 12 Oct 2016 20:49:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYC41938; Thu, 13 Oct 2016 03:49:23 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 13 Oct 2016 04:49:22 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 13 Oct 2016 11:49:15 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: How to indicate the existence of an explicit protocol field immediately after the MPLS label stack? Thread-Index: AdIlBMP6LXv/uE5HT4SrFJTX7KhsFg== Date: Thu, 13 Oct 2016 03:49:14 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB21A78@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.57FF0444.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e35981dbebbe2497649d1c9b37ef0de7 Archived-At: Cc: "bier@ietf.org" , "sfc@ietf.org" Subject: [mpls] How to indicate the existence of an explicit protocol field immediately after the MPLS label stack? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 03:49:29 -0000 Hi all, It's well-known that the MPLS label stack has no EXPLICIT protocol identifi= er field to indicate the protocol type of the MPLS payload. However, the fi= rst nibble of the MPLS payload has actually been used as an implicit protoc= ol identifier for some payloads, such as IPv4 (0100), IPv6(0110) and MPLS-B= IER (0101, for more details, please see https://tools.ietf.org/html/draft-i= etf-bier-mpls-encapsulation-05#page-5). Unfortunately, the first nibble spa= ce is not enough for the sustainable development of new encapsulation heade= rs which may happen to be encapsulated with an MPLS header. Furthermore, th= e remaining first nibble space available for payload indication is only 011= 1 due to the NSH specification (https://tools.ietf.org/html/draft-ietf-sfc-= nsh-10#page-7) unless the NSH is restricted from being transported directly= over the MPLS transport (in this case the NSH is sadly not transport indep= endent anymore).=20 Hence, it's seem necessary for us to consider the approach of inserting an = EXPLICIT protocol identifier field within the MPLS packet as early as possi= ble. The following are two possible ways of inserting an EXPLICIT protocol = identifier field within the MPLS packet: One is to use an SPL (or even ESPL) as described (https://tools.ietf.org/ht= ml/draft-xu-mpls-payload-protocol-identifier-01). See the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PIL | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Reserved | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Another is to set the first nibble of the 4-octet entry containing the prot= ocol field to a dedicated value (e.g., 1111), as shown in the following fig= ure. In this case, there is no need to insert additional label (s) (i.e., S= PL or ESPL) anymore. The logic of the latter approach is that the first nib= ble of the MPLS payload has been implicitly used as a protocol id (e.g., in= the case where the payload is IPv4 or IPv6 packet), and since the 4-bit (i= mplicit) protocol id field is not extensible, we introduce a longer (explic= it) protocol id field as per the approach of ESPL.=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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bottom Label | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1| Reserved | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IMHO, the benefits of introducing an explicit protocol id into the MPLS pac= ket include but not limited to: 1) provide a sustainable way of indicating = new MPLS payload types without any need of inserting one additional label i= ndicating the MPLS payloads (e.g., considering how to transport NSH over MP= LS networks); 2) there is no need any more for each new encapsulation heade= r to deal with the notorious first nibble issue associated with MPLS indivi= dually. More specifically, there is no need to intentionally avoid the firs= t nibble of each new encapsulation header from being 0100 (IPv4) or 0110 (I= Pv6). Any comments and suggestions are welcome. Best regards, Xiaohu From nobody Wed Oct 12 22:36:09 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13ACE1295CB; Wed, 12 Oct 2016 22:36:08 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JM5dWSxGQwej; Wed, 12 Oct 2016 22:36:05 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0112.outbound.protection.outlook.com [104.47.0.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB76C129409; Wed, 12 Oct 2016 22:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n6dX2p7XdaKqUIIT35BQ6p6OPiaiouYf9eaHt/bWEkg=; b=hwF/GaHkAkh8EmoX5UHjqNnRVY+3mTjJsTHzFbsnXHYs7ld+EuYuXEK7nHwTLizew50idfYc2pGH63tGCrIZQ4p3wtSXPylHBIZ8m911Ale+nR0ZigsnnsLElW1ITbDjfJ1cNiDp+piEzUUtO1tPJMrVwCd2db2p7S95+odA9xE= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2268.eurprd03.prod.outlook.com (10.168.31.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Thu, 13 Oct 2016 05:36:02 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0669.011; Thu, 13 Oct 2016 05:36:02 +0000 From: Alexander Vainshtein To: Xuxiaohu , "mpls@ietf.org" Thread-Topic: How to indicate the existence of an explicit protocol field immediately after the MPLS label stack? Thread-Index: AdIlBMP6LXv/uE5HT4SrFJTX7KhsFgADlfLd Date: Thu, 13 Oct 2016 05:36:02 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB21A78@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB21A78@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [25.165.214.132] x-ms-office365-filtering-correlation-id: 045870ff-5fc6-4ae9-a3e4-08d3f32ad1be x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2268; 7:OFWvxL1930kIKM1dCJEG9SNhJj/9931RCldkPcu7yxYWLIR2PLho0sI7hCjG5JYpuc+QmAkciKfv2SoHhxpD+I7leNWfkRQPWeHLKVZgjDnp1AGu7tgdGUGLE5UdiknNW5gMNvYauUiIDw8VHDsEbJ/S7dFPrWvU3uLyAjLeYgUIdHOutHHWOqg4FQKYeekhYs2hgKAsGXCE6XRqSJ1ceNMqaWoNR00V2hnRC+iQpENg5LY0txEVaew0Fzn9NLQnCqk5iLdtDm08fU4QJRknh9Y+u2DgAugLHkHpNUgfa1Z+pHE1QInKftyTbUzFvM4nNxToPRxAdC5jCFH1YnqexrlNQq01tjJfg2zB2Ps2lgk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0301MB2268; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:HE1PR0301MB2268; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2268; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(53754006)(199003)(2950100002)(15974865002)(106356001)(5002640100001)(586003)(5660300001)(2501003)(3846002)(102836003)(105586002)(6116002)(19617315012)(81166006)(97736004)(15975445007)(77096005)(10400500002)(2906002)(5001770100001)(189998001)(4326007)(33656002)(2900100001)(8936002)(7696004)(101416001)(3900700001)(11100500001)(6606003)(7846002)(8676002)(19580405001)(92566002)(9686002)(19580395003)(19625215002)(76576001)(68736007)(122556002)(16236675004)(3660700001)(3280700002)(7736002)(54356999)(76176999)(86362001)(87936001)(74316002)(7906003)(50986999)(19627405001)(81156014)(66066001)(14773001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2268; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0301MB22666341F0FC2F76AFEBF6DB9DDC0HE1PR0301MB2266_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2016 05:36:02.0418 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2268 Archived-At: Cc: "bier@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] How to indicate the existence of an explicit protocol field immediately after the MPLS label stack? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 05:36:08 -0000 --_000_HE1PR0301MB22666341F0FC2F76AFEBF6DB9DDC0HE1PR0301MB2266_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Xiaohu and all, I respectfully disagree with your statement "the first nibble of the MPLS p= ayload has actually been used as an implicit protocol identifier for some p= ayloads". In the case of PWs the CW (with this first nibble) may be not pre= sent at all, but even when it is present, its first nibble is only used for= disambiguation of the PW packets (so that they cannot be mistakenly treate= d as IPv4 or IPv6 packets by the ECMP mechanisms). My 2c, Sasha ________________________________ From: mpls on behalf of Xuxiaohu Sent: Thursday, October 13, 2016 6:49 AM To: mpls@ietf.org Cc: bier@ietf.org; sfc@ietf.org Subject: [mpls] How to indicate the existence of an explicit protocol field= immediately after the MPLS label stack? Hi all, It's well-known that the MPLS label stack has no EXPLICIT protocol identifi= er field to indicate the protocol type of the MPLS payload. However, the fi= rst nibble of the MPLS payload has actually been used as an implicit protoc= ol identifier for some payloads, such as IPv4 (0100), IPv6(0110) and MPLS-B= IER (0101, for more details, please see https://tools.ietf.org/html/draft-i= etf-bier-mpls-encapsulation-05#page-5). Unfortunately, the first nibble spa= ce is not enough for the sustainable development of new encapsulation heade= rs which may happen to be encapsulated with an MPLS header. Furthermore, th= e remaining first nibble space available for payload indication is only 011= 1 due to the NSH specification (https://tools.ietf.org/html/draft-ietf-sfc-= nsh-10#page-7) unless the NSH is restricted from being transported directly= over the MPLS transport (in this case the NSH is sadly not transport indep= endent anymore). Hence, it's seem necessary for us to consider the approach of inserting an = EXPLICIT protocol identifier field within the MPLS packet as early as possi= ble. The following are two possible ways of inserting an EXPLICIT protocol = identifier field within the MPLS packet: One is to use an SPL (or even ESPL) as described (https://tools.ietf.org/ht= ml/draft-xu-mpls-payload-protocol-identifier-01). See the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PIL | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Reserved | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Another is to set the first nibble of the 4-octet entry containing the prot= ocol field to a dedicated value (e.g., 1111), as shown in the following fig= ure. In this case, there is no need to insert additional label (s) (i.e., S= PL or ESPL) anymore. The logic of the latter approach is that the first nib= ble of the MPLS payload has been implicitly used as a protocol id (e.g., in= the case where the payload is IPv4 or IPv6 packet), and since the 4-bit (i= mplicit) protocol id field is not extensible, we introduce a longer (explic= it) protocol id field as per the approach of ESPL. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bottom Label | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 1| Reserved | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IMHO, the benefits of introducing an explicit protocol id into the MPLS pac= ket include but not limited to: 1) provide a sustainable way of indicating = new MPLS payload types without any need of inserting one additional label i= ndicating the MPLS payloads (e.g., considering how to transport NSH over MP= LS networks); 2) there is no need any more for each new encapsulation heade= r to deal with the notorious first nibble issue associated with MPLS indivi= dually. More specifically, there is no need to intentionally avoid the firs= t nibble of each new encapsulation header from being 0100 (IPv4) or 0110 (I= Pv6). Any comments and suggestions are welcome. Best regards, Xiaohu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls mpls Info Page - Internet Engineering Task Force www.ietf.org For information about the MPLS working group, see http://www.ietf.org/html.= charters/mpls-charter.html. To see the collection of prior postings to the = list, visit ... --_000_HE1PR0301MB22666341F0FC2F76AFEBF6DB9DDC0HE1PR0301MB2266_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Xiaohu and= all,

I respectf= ully disagree with your statement "the first nibble of the MPLS payload has actually been used as an implicit pro= tocol identifier for some payloads". In the case= of PWs the CW (with this first nibble) may be not present at all, but even= when it is present, its first nibble is only used for disambiguation of the PW packets (so that they cannot be = mistakenly treated as IPv4 or IPv6 packets by the ECMP mechanisms).<= /p>


My 2c,

Sasha







From: mpls <mpls-bounc= es@ietf.org> on behalf of Xuxiaohu <xuxiaohu@huawei.com>
Sent: Thursday, October 13, 2016 6:49 AM
To: mpls@ietf.org
Cc: bier@ietf.org; sfc@ietf.org
Subject: [mpls] How to indicate the existence of an explicit protoco= l field immediately after the MPLS label stack?
 
Hi all,

It's well-known that the MPLS label stack has no EXPLICIT protocol identifi= er field to indicate the protocol type of the MPLS payload. However, the fi= rst nibble of the MPLS payload has actually been used as an implicit protoc= ol identifier for some payloads, such as IPv4 (0100), IPv6(0110) and MPLS-BIER (0101, for more details, ple= ase see https://tools.ietf.org/html/draft-ietf-bier-mpls-encapsulation-05#page-5). Unfortunately, the first nibble space is not enough for the sustainable= development of new encapsulation headers which may happen to be encapsulat= ed with an MPLS header. Furthermore, the remaining first nibble space available for payload indication is only = 0111 due to the NSH specification (htt= ps://tools.ietf.org/html/draft-ietf-sfc-nsh-10#page-7) unless the NSH is restricted from being transported directly over the MPLS= transport (in this case the NSH is sadly not transport independent anymore= ).

Hence, it's seem necessary for us to consider the approach of inserting an = EXPLICIT protocol identifier field within the MPLS packet as early as possi= ble. The following are two possible ways of inserting an EXPLICIT protocol = identifier field within the MPLS packet:

One is to use an SPL (or even ESPL) as described (https://tools.ietf.org/html/draft-xu-mpls-paylo= ad-protocol-identifier-01). See the following figure:

     0        &= nbsp;          1  &n= bsp;            = ;    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
     +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+      |        &= nbsp;        PIL    =             &nb= sp;  | EXP |1|      TTL   &nbs= p;  |
     +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+      |0 0 0 0|       Rese= rved          |  &nb= sp;     Protocol Type     &nbs= p;  |
     +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+      |        &= nbsp;           &nbs= p;         Payload   = ;            &n= bsp;          |
     +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+
Another is to set the first nibble of the 4-octet entry containing the prot= ocol field to a dedicated value (e.g., 1111), as shown in the following fig= ure. In this case, there is no need to insert additional label (s) (i.e., S= PL or ESPL) anymore. The logic of the latter approach is that the first nibble of the MPLS payload has been = implicitly used as a protocol id (e.g., in the case where the payload is IP= v4 or IPv6 packet), and since the 4-bit (implicit) protocol id field is not= extensible, we introduce a longer (explicit) protocol id field as per the approach of ESPL.
       0      &= nbsp;            1&n= bsp;            = ;      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
       +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+
       |      &= nbsp;      Bottom Label    &nb= sp;         | EXP |1|  &n= bsp;   TTL      |
       +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+
       |0 1 1 1|     = ;  Reserved          |&nb= sp;       Protocol Type   &nbs= p;    |
       +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+
       |      &= nbsp;           &nbs= p;           Payload = ;            &n= bsp;            |        +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

IMHO, the benefits of introducing an explicit protocol id into the MPLS pac= ket include but not limited to: 1) provide a sustainable way of indicating = new MPLS payload types without any need of inserting one additional label i= ndicating the MPLS payloads (e.g., considering how to transport NSH over MPLS networks); 2) there is no need = any more for each new encapsulation header to deal with the notorious first= nibble issue associated with MPLS individually. More specifically, there i= s no need to intentionally avoid the first nibble of each new encapsulation header from being 0100 (IPv4) o= r 0110 (IPv6).

Any comments and suggestions are welcome.

Best regards,
Xiaohu

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
www.ietf.org
For information about the MPLS working group, see http://www.ietf.org/html.= charters/mpls-charter.html. To see the collection of prior postings to the = list, visit ...


--_000_HE1PR0301MB22666341F0FC2F76AFEBF6DB9DDC0HE1PR0301MB2266_-- From nobody Thu Oct 13 05:53:56 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07FB129767; Thu, 13 Oct 2016 05:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W42XirAnjof6; Thu, 13 Oct 2016 05:53:48 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 5AB0C129764; Thu, 13 Oct 2016 05:53:47 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id x79so138332751lff.0; Thu, 13 Oct 2016 05:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=GKZfT0GIALufJszPw40C9R+f2AZleu0sJpl3XBDOTvE=; b=DnZBzySuLh3F4M6ObhFbNMMY6fhGT/zH8FrMJmX1rWpIc947wjywTtTuYmzzT1gOnn Lmo/eXGV75GVB+GqkZr7Q0sraM8UUcdndrXcnI8iHpNihJKiIt3RaLCAkoDssHOQNtQ+ PFxsK2GmU1f5A5HPm6N835I2AegWTlGhsd1zxUIoxTaZ60k5PVDfQyOJhIEdImwktQrK DaLT1kjXhne8cjhO1vU9pgbP2C8JjgKT6ScT+IXQZIaNSUbMnFOHv+VAJeaIsSdawuF8 ZZALjsBFgIX0QpkRQ2tskjzFy4L/DjENuB/haIuM/Pvoho2tc2jwNe7bedKeLM4Bk5om viQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=GKZfT0GIALufJszPw40C9R+f2AZleu0sJpl3XBDOTvE=; b=QDzEUeT+o/uWhwAQTJGxVnfjjyAvrMieIJ23fz38bG2J+ps7dI2Nv395oR/0QdZcMD Wu7tf2p1hZeGwanzlTLJGVEnWxoZ0bJ/sEUHoKqiLpuyJdZAomjKaO3GoQ2cYVLLvOfD yNk5MVcblHDz2c2OwNWIToLyQfwpiLaScF4nQZ4oyitxTkZrzdgPf4ihihJ4iHAweMqE FqwFiTXTekNDlhUXbotc0nNc4bWrI6I/ah5bJDGZEUvGO+BhPjHHLt5iAP1KbiqkT3HQ fJjMRZ3bETbFhOEu87/hKVEoQgBDm1MkIyXMIo6kDTScsyGMQRUhMSFM6OYGwg/uxh+1 r3Dw== X-Gm-Message-State: AA6/9RkI5xVLP+qzUZ0MEFRA+f1G60dT/A0QZEkDezS4sHr1O6Vduvu8dLG0aDVu1D40Bw== X-Received: by 10.25.7.201 with SMTP id 192mr9834694lfh.170.1476363225430; Thu, 13 Oct 2016 05:53:45 -0700 (PDT) Received: from [192.168.2.127] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id r16sm3722391lfe.38.2016.10.13.05.53.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Oct 2016 05:53:44 -0700 (PDT) To: Alexander Vainshtein , Xuxiaohu , "mpls@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB21A78@NKGEML515-MBX.china.huawei.com> From: Stewart Bryant Message-ID: <71ee24c7-7702-093f-2595-af18f2539a60@gmail.com> Date: Thu, 13 Oct 2016 13:53:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------584D86D38972B862E24FD4FD" Archived-At: Cc: "bier@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] How to indicate the existence of an explicit protocol field immediately after the MPLS label stack? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 12:53:51 -0000 This is a multi-part message in MIME format. --------------584D86D38972B862E24FD4FD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sasha is correct, and I seem to remember a PW system that did meet an Ethernet packet with IPv4 as the first nibble and made such a mistake. You can only use the first nibble as a disambiguator for example to distinguish IPv4 and IPv6 if you have some supplementary information telling you that the packet can only be either type IPv4 or IPv6. Stewart On 13/10/2016 06:36, Alexander Vainshtein wrote: > > Xiaohu and all, > > I respectfully disagree with your statement "*/the first nibble of the > MPLS payload has actually been used as an implicit protocol identifier > for some payloads/*". In the case of PWs the CW (with this first > nibble) may be not present at all, but even when it is present, its > first nibble is only used for disambiguation of the PW packets (so > that they cannot be mistakenly treated as IPv4 or IPv6 packets by the > ECMP mechanisms). > > > My 2c, > > Sasha > > > > > > > > ------------------------------------------------------------------------ > *From:* mpls on behalf of Xuxiaohu > > *Sent:* Thursday, October 13, 2016 6:49 AM > *To:* mpls@ietf.org > *Cc:* bier@ietf.org; sfc@ietf.org > *Subject:* [mpls] How to indicate the existence of an explicit > protocol field immediately after the MPLS label stack? > Hi all, > > It's well-known that the MPLS label stack has no EXPLICIT protocol > identifier field to indicate the protocol type of the MPLS payload. > However, the first nibble of the MPLS payload has actually been used > as an implicit protocol identifier for some payloads, such as IPv4 > (0100), IPv6(0110) and MPLS-BIER (0101, for more details, please see > https://tools.ietf.org/html/draft-ietf-bier-mpls-encapsulation-05#page-5). > Unfortunately, the first nibble space is not enough for the > sustainable development of new encapsulation headers which may happen > to be encapsulated with an MPLS header. Furthermore, the remaining > first nibble space available for payload indication is only 0111 due > to the NSH specification > (https://tools.ietf.org/html/draft-ietf-sfc-nsh-10#page-7) unless the > NSH is restricted from being transported directly over the MPLS > transport (in this case the NSH is sadly not transport independent > anymore). > > Hence, it's seem necessary for us to consider the approach of > inserting an EXPLICIT protocol identifier field within the MPLS packet > as early as possible. The following are two possible ways of inserting > an EXPLICIT protocol identifier field within the MPLS packet: > > One is to use an SPL (or even ESPL) as described > (https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier-01). > See the following figure: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PIL | EXP |1| TTL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Reserved | Protocol Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Another is to set the first nibble of the 4-octet entry containing the > protocol field to a dedicated value (e.g., 1111), as shown in the > following figure. In this case, there is no need to insert additional > label (s) (i.e., SPL or ESPL) anymore. The logic of the latter > approach is that the first nibble of the MPLS payload has been > implicitly used as a protocol id (e.g., in the case where the payload > is IPv4 or IPv6 packet), and since the 4-bit (implicit) protocol id > field is not extensible, we introduce a longer (explicit) protocol id > field as per the approach of ESPL. > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Bottom Label | EXP |1| TTL | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 1 1 1| Reserved | Protocol Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > IMHO, the benefits of introducing an explicit protocol id into the > MPLS packet include but not limited to: 1) provide a sustainable way > of indicating new MPLS payload types without any need of inserting one > additional label indicating the MPLS payloads (e.g., considering how > to transport NSH over MPLS networks); 2) there is no need any more for > each new encapsulation header to deal with the notorious first nibble > issue associated with MPLS individually. More specifically, there is > no need to intentionally avoid the first nibble of each new > encapsulation header from being 0100 (IPv4) or 0110 (IPv6). > > Any comments and suggestions are welcome. > > Best regards, > Xiaohu > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > mpls Info Page - Internet Engineering Task Force > > www.ietf.org > For information about the MPLS working group, see > http://www.ietf.org/html.charters/mpls-charter.html. To see the > collection of prior postings to the list, visit ... > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --------------584D86D38972B862E24FD4FD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Sasha is correct, and I seem to remember a PW system that did meet an Ethernet packet with IPv4 as the first nibble and made such a mistake.


You can only use the first nibble as a disambiguator for example to distinguish IPv4 and IPv6 if you have some supplementary information telling you that the packet can only be either type IPv4 or IPv6.


Stewart



On 13/10/2016 06:36, Alexander Vainshtein wrote:

Xiaohu and all,

I respectfully disagree with your statement "the first nibble of the MPLS payload has actually been used as an implicit protocol identifier for some payloads". In the case of PWs the CW (with this first nibble) may be not present at all, but even when it is present, its first nibble is only used for disambiguation of the PW packets (so that they cannot be mistakenly treated as IPv4 or IPv6 packets by the ECMP mechanisms).


My 2c,

Sasha







From: mpls <mpls-bounces@ietf.org> on behalf of Xuxiaohu <xuxiaohu@huawei.com>
Sent: Thursday, October 13, 2016 6:49 AM
To: mpls@ietf.org
Cc: bier@ietf.org; sfc@ietf.org
Subject: [mpls] How to indicate the existence of an explicit protocol field immediately after the MPLS label stack?
Hi all,

It's well-known that the MPLS label stack has no EXPLICIT protocol identifier field to indicate the protocol type of the MPLS payload. However, the first nibble of the MPLS payload has actually been used as an implicit protocol identifier for some payloads, such as IPv4 (0100), IPv6(0110) and MPLS-BIER (0101, for more details, please see https://tools.ietf.org/html/draft-ietf-bier-mpls-encapsulation-05#page-5). Unfortunately, the first nibble space is not enough for the sustainable development of new encapsulation headers which may happen to be encapsulated with an MPLS header. Furthermore, the remaining first nibble space available for payload indication is only 0111 due to the NSH specification (https://tools.ietf.org/html/draft-ietf-sfc-nsh-10#page-7) unless the NSH is restricted from being transported directly over the MPLS transport (in this case the NSH is sadly not transport independent anymore).

Hence, it's seem necessary for us to consider the approach of inserting an EXPLICIT protocol identifier field within the MPLS packet as early as possible. The following are two possible ways of inserting an EXPLICIT protocol identifier field within the MPLS packet:

One is to use an SPL (or even ESPL) as described (https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier-01). See the following figure:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIL | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Reserved | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Another is to set the first nibble of the 4-octet entry containing the protocol field to a dedicated value (e.g., 1111), as shown in the following figure. In this case, there is no need to insert additional label (s) (i.e., SPL or ESPL) anymore. The logic of the latter approach is that the first nibble of the MPLS payload has been implicitly used as a protocol id (e.g., in the case where the payload is IPv4 or IPv6 packet), and since the 4-bit (implicit) protocol id field is not extensible, we introduce a longer (explicit) protocol id field as per the approach of ESPL.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bottom Label | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1| Reserved | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IMHO, the benefits of introducing an explicit protocol id into the MPLS packet include but not limited to: 1) provide a sustainable way of indicating new MPLS payload types without any need of inserting one additional label indicating the MPLS payloads (e.g., considering how to transport NSH over MPLS networks); 2) there is no need any more for each new encapsulation header to deal with the notorious first nibble issue associated with MPLS individually. More specifically, there is no need to intentionally avoid the first nibble of each new encapsulation header from being 0100 (IPv4) or 0110 (IPv6).

Any comments and suggestions are welcome.

Best regards,
Xiaohu

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
For information about the MPLS working group, see http://www.ietf.org/html.charters/mpls-charter.html. To see the collection of prior postings to the list, visit ...
 




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

--------------584D86D38972B862E24FD4FD-- From nobody Thu Oct 13 19:59:46 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686331295A9; Thu, 13 Oct 2016 19:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.217 X-Spam-Level: X-Spam-Status: No, score=-7.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0sAax2UHDvG; Thu, 13 Oct 2016 19:59:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1ACC1293D9; Thu, 13 Oct 2016 19:59:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYE43334; Fri, 14 Oct 2016 02:59:39 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 14 Oct 2016 03:59:38 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 14 Oct 2016 10:59:31 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-xu-mpls-service-chaining-00.txt Thread-Index: AQHSJcK948TCIJp9706iNJkiD52uJqCnPiMg Date: Fri, 14 Oct 2016 02:59:30 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2203A@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58004A1C.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9ec94120f8726d1401bb69cfb8287218 Archived-At: Cc: "sfc@ietf.org" , "spring-chairs@tools.ietf.org" Subject: [mpls] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-xu-mpls-service-chaining-00=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 02:59:45 -0000 SGkgYWxsLA0KDQpkcmFmdC14dS1tcGxzLXNlcnZpY2UtY2hhaW5pbmctMDAgaXMgYSByZXBsYWNl bWVudCBvZiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXNmYy11c2luZy1t cGxzLXNwcmluZykuIEFueSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoN CkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R 5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddDQo+IOWPkemAgeaXtumXtDogMjAxNuW5tDEw5pyIMTTml6UgMTA6MjkNCj4g5pS2 5Lu25Lq6OiBEYW5pZWwgQmVybmllcjsgU3Rld2FydCBCcnlhbnQ7IFh1eGlhb2h1OyBkYW5pZWwu YmVybmllckBiZWxsLmNhOw0KPiBIaW1hbnNodSBTaGFoOyBIYW1pZCBBc3NhcnBvdXI7IEx1aXMg Q29udHJlcmFzOyBMdWlzIE0uIENvbnRyZXJhcw0KPiDkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQteHUtbXBscy1zZXJ2aWNlLWNoYWluaW5nLTAwLnR4dA0KPiANCj4g DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14dS1tcGxzLXNlcnZpY2UtY2hhaW5pbmct MDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1IGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC14dS1t cGxzLXNlcnZpY2UtY2hhaW5pbmcNCj4gUmV2aXNpb246CTAwDQo+IFRpdGxlOgkJU2VydmljZSBD aGFpbmluZyB1c2luZyBNUExTIFNvdXJjZSBSb3V0aW5nDQo+IERvY3VtZW50IGRhdGU6CTIwMTYt MTAtMTMNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6CQk4DQo+IFVS TDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1LW1wbHMt c2VydmljZS1jaGFpbmluZy0wMC50eHQNCj4gU3RhdHVzOg0KPiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC14dS1tcGxzLXNlcnZpY2UtY2hhaW5pbmcvDQo+IEh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtbXBscy1zZXJ2aWNl LWNoYWluaW5nLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFNvdXJjZSBQYWNrZXQgUm91 dGluZyBpbiBOZXR3b3JraW5nIChTUFJJTkcpIFdHIGlzIGRldmVsb3BpbmcgYW4gTVBMUw0KPiAg ICBzb3VyY2Ugcm91dGluZyBtZWNoYW5pc20uICBUaGlzIE1QTFMgc291cmNlIHJvdXRpbmcgbWVj aGFuaXNtIGNhbiBiZQ0KPiAgICBsZXZlcmFnZWQgdG8gcmVhbGl6ZSB0aGUgc2VydmljZSBwYXRo IGxheWVyIGZ1bmN0aW9uYWxpdHkgb2YgdGhlDQo+ICAgIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5p bmcgKGkuZS4sIHN0ZWVyaW5nIHRoZSBzZWxlY3RlZCB0cmFmZmljDQo+ICAgIHRocm91Z2ggYSBw YXJ0aWN1bGFyIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCkgYnkgZW5jb2RpbmcgdGhlIHNlcnZpY2UN Cj4gICAgZnVuY3Rpb24gcGF0aCBpbmZvcm1hdGlvbiBhcyBhbiBNUExTIGxhYmVsIHN0YWNrLiAg VGhpcyBkb2N1bWVudA0KPiAgICBkZXNjcmliZXMgaG93IHRvIHVzZSB0aGUgTVBMUyBzb3VyY2Ug cm91dGluZyBtZWNoYW5pc20gYXMgZGV2ZWxvcGVkDQo+ICAgIGJ5IHRoZSBTUFJJTkcgV0cgdG8g cmVhbGl6ZSB0aGUgc2VydmljZSBwYXRoIGxheWVyIGZ1bmN0aW9uYWxpdHkgb2YNCj4gICAgc2Vy dmljZSBmdW5jdGlvbiBjaGFpbmluZy4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Oct 13 20:04:05 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7191C129436 for ; Thu, 13 Oct 2016 20:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.217 X-Spam-Level: X-Spam-Status: No, score=-7.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSTDSTZXT8b1 for ; Thu, 13 Oct 2016 20:04:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F14F1293D9 for ; Thu, 13 Oct 2016 20:04:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYE44426; Fri, 14 Oct 2016 03:03:59 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 14 Oct 2016 04:03:59 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 14 Oct 2016 11:03:51 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-xu-mpls-spring-islands-connection-over-ip-00.txt Thread-Index: AQHSJR3C0uLjZ6UkBEqsbY32GdrN/KCnRDOA Date: Fri, 14 Oct 2016 03:03:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB22057@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58004B20.000A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6976cc18516c930bb2066e8c07254b3a Archived-At: Subject: [mpls] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-xu-mpls-spring-islands-connection-over-ip-00=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 03:04:03 -0000 SGkgYWxsLA0KDQpUaGlzIGRyYWZ0IGlzIGEgcmVwbGFjZW1lbnQgb2YgKGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJpbmctaXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXAt MDUpLiBBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQpCZXN0IHJl Z2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTblubQxMOaciDEz5pelIDE0OjQ4DQo+IOaUtuS7tuS6ujog THVpcyBNLiBDb250cmVyYXM7IFVtYSBDaHVuZHVyaTsgWHV4aWFvaHU7IEx1YXkgSmFsaWw7IFJv YmVydCBSYXN6dWs7DQo+IEx1aXMgQ29udHJlcmFzDQo+IOS4u+mimDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC14dS1tcGxzLXNwcmluZy1pc2xhbmRzLWNvbm5lY3Rpb24t b3Zlci1pcC0wMC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteHUt bXBscy1zcHJpbmctaXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXAtMDAudHh0DQo+IGhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1IGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC14dS1tcGxzLXNwcmluZy1pc2xhbmRz LWNvbm5lY3Rpb24tb3Zlci1pcA0KPiBSZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlDb25uZWN0aW5n IE1QTFMtU1BSSU5HIElzbGFuZHMgb3ZlciBJUCBOZXR3b3Jrcw0KPiBEb2N1bWVudCBkYXRlOgky MDE2LTEwLTEyDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJNg0K PiBVUkw6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC14dS1t cGxzLXNwcmluZy1pc2xhbmRzLWNvbm5lY3Rpb24tb3YNCj4gZXItaXAtMDAudHh0DQo+IFN0YXR1 czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteHUtbXBscy1zcHJp bmctaXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXANCj4gLw0KPiBIdG1saXplZDoNCj4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LW1wbHMtc3ByaW5nLWlzbGFuZHMtY29ubmVj dGlvbi1vdmVyLWlwLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIE1QTFMtU1BSSU5HIGlz IGFuIE1QTFMtYmFzZWQgc291cmNlIHJvdXRpbmcgcGFyYWRpZ20gaW4gd2hpY2ggYQ0KPiAgICBz ZW5kZXIgb2YgYSBwYWNrZXQgaXMgYWxsb3dlZCB0byBwYXJ0aWFsbHkgb3IgY29tcGxldGVseSBz cGVjaWZ5IHRoZQ0KPiAgICByb3V0ZSB0aGUgcGFja2V0IHRha2VzIHRocm91Z2ggdGhlIG5ldHdv cmsgYnkgaW1wb3Npbmcgc3RhY2tlZCBNUExTDQo+ICAgIGxhYmVscyB0byB0aGUgcGFja2V0LiAg VG8gZmFjaWxpdGF0ZSB0aGUgaW5jcmVtZW50YWwgZGVwbG95bWVudCBvZg0KPiAgICB0aGlzIG5l dyB0ZWNobm9sb2d5LCB0aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSB3aGljaCBh bGxvd3MNCj4gICAgdGhlIG91dGVybW9zdCBMU1AgYmUgcmVwbGFjZWQgYnkgYW4gSVAtYmFzZWQg dHVubmVsLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Oct 14 10:00:11 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE38129841; Fri, 14 Oct 2016 08:28:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147645889719.18573.2849185759970104353.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2016 08:28:17 -0700 Archived-At: X-Mailman-Approved-At: Fri, 14 Oct 2016 10:00:09 -0700 Cc: itu-t-liaison@iab.org, Multiprotocol Label Switching Discussion List , Common Control and Measurement Plane Discussion List , JP Vasseur , Path Computation Element Discussion List , jonathan.hardwick@metaswitch.com Subject: [mpls] New Liaison Statement, "Reply to SG15 Liaison regarding OTNT Standardization Work Plan" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:28:17 -0000 Title: Reply to SG15 Liaison regarding OTNT Standardization Work Plan Submission Date: 2016-10-14 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1497/ From: "Scott Mansfield" To: Naotaka.morita@ntt-at.co.jp,tsbsg15@itu.int Cc: Alvaro Retana ,Deborah Brungard ,Julien Meuric ,Multiprotocol Label Switching Discussion List ,Scott Mansfield ,Jonathan Hardwick ,Fatai Zhang ,George Swallow ,Path Computation Element Discussion List ,JP Vasseur ,John Drake ,Alia Atlas ,Daniele Ceccarelli ,Loa Andersson ,Common Control and Measurement Plane Discussion List ,itu-t-liaison@iab.org,Nicolai Leymann , Response Contacts: n.leymann@telekom.de,loa@pi.nu,swallow.ietf@gmail.com,jonathan.hardwick@metaswitch.com,jpv@cisco.com,julien.meuric@orange.com,Daniele Ceccarelli ,Fatai Zhang Technical Contacts: scott.mansfield@ericsson.com Purpose: For information Referenced liaison: LS on SG15 OTNT Standardization Work Plan (https://datatracker.ietf.org/liaison/1494/) Body: Thank you for keeping the MPLS, PCE, and CCAMP working groups up to date on the standardization work plan for OTNT. We feel the splitting of the document is a useful improvement for the reader. As noted previously, the IETF encourages engagement with the work of the working groups on the MPLS, PCE, and CCAMP mailing lists. Please consider including PALS (Pseudowire And LDP-enabled Services) pals@ietf.org and the TEAS (Traffic Engineering Architecture and Signaling) teas@ietf.org in future correspondence on this topic. Attachments: No document has been attached From nobody Fri Oct 14 14:06:44 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0842712963C; Fri, 14 Oct 2016 14:06:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147647920003.18677.11420258407994294603.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2016 14:06:40 -0700 Archived-At: Cc: mpls@ietf.org, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-mpls-bfd-directed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 21:06:40 -0000 Dear Jeff Tantsura, Ilya Varlashkin, Mach Chen, Gregory Mirsky: An IPR disclosure that pertains to your Internet-Draft entitled "Bidirectional Forwarding Detection (BFD) Directed Return Path" (draft-ietf-mpls-bfd-directed) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2892/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-mpls-bfd-directed" Thank you IETF Secretariat From nobody Mon Oct 17 14:58:39 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13717129535; Mon, 17 Oct 2016 14:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYwQwSwJSMJ2; Mon, 17 Oct 2016 14:58:30 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E911294C2; Mon, 17 Oct 2016 14:58:30 -0700 (PDT) X-AuditID: c6180641-e73ff70000000a0b-dd-5804f51cedcd Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by (Symantec Mail Security) with SMTP id 18.AC.02571.C15F4085; Mon, 17 Oct 2016 17:58:23 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0319.002; Mon, 17 Oct 2016 17:58:25 -0400 From: Eric Gray To: "huubatwork@gmail.com" , "mpls@ietf.org" Thread-Topic: Working Group Last Call for draft-ietf-mpls-tp-shared-ring-protection-02 Thread-Index: AdH3ANzPdQ19JyNsQnuCnI2RKyUKQQAKdw5ACj+cbYACHV4cYA== Date: Mon, 17 Oct 2016 21:58:24 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF64A911679@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF64A883507@eusaamb107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF64A886D22@eusaamb107.ericsson.se> <4d229ad5-d6c4-264a-9afc-8235c0f9e0d2@gmail.com> In-Reply-To: <4d229ad5-d6c4-264a-9afc-8235c0f9e0d2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF64A911679eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXRPlK78V5YIg0fbNC12XWCxmDH7MqvF usun2CxuLV3J6sDisXPWXXaPJUt+MgUwRXHZpKTmZJalFunbJXBlXJ3Xx1Lw6TZbxaQFP9gb GE8+Ye1i5OSQEDCR6G9rAbK5OIQENjBKHGrYyA7hLGeUmLv3MVgVm4CGxLE7axlBbBGBEInW zZ8ZQYqYBRYwSuyc+xeog4NDWCBcoh2mJkJiyoPlrCBhEQEniRvXvUHCLAKqEvv33WQGsXkF fCVWXLnPCLHrCKPEtBUNLCAJTgFbia+zzoIVMQqISXw/tYYJxGYWEJe49WQ+E8TVAhJL9pxn hrBFJV4+/gf1jZLEnNfXmCHq8yXuHWtih1gmKHFy5hOWCYwis5CMmoWkbBaSMoi4jsSC3Z/Y IGxtiWULXzPD2GcOPGZCFl/AyL6KkaO0uCAnN93IcBMjMKqOSbA57mDc2+t5iFGAg1GJh1dh IUuEEGtiWXFl7iFGCQ5mJRHeEnfWCCHelMTKqtSi/Pii0pzU4kOM0hwsSuK810PuhwsJpCeW pGanphakFsFkmTg4pRoYhQ0fm13adPP/DeluzrP7jrBev8qlm5Fe0C2Se/Vb0qLgnWsFFr6s N05I6IgP/zzZ9UVL0KFEgx21Eh6fDubta7v5d/rf45dLC82fXdS/ufH+Rp7giykZDxg+3mJc Fcz36lEI6x+/Q3UXc6ybT/MxmajdF/wwYYtZWMtTn+vvsng8ou+f+fJDTomlOCPRUIu5qDgR AGptgWSmAgAA Archived-At: Cc: "draft-ietf-mpls-tp-shared-ring-protection@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Working Group Last Call for draft-ietf-mpls-tp-shared-ring-protection-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 21:58:37 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF64A911679eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Huub, et al, Sorry it has taken me so long to reply. I have heard from Loa that his comments have been addressed= . The document is much improved, but not quite there yet. I have noticed a few NITs in the revised wording that can b= e dealt with via instructions to the RFC Editor (no action required by the = Authors or Contributors unless addressing other issues anyway). I have a pair of minor questions: you now define a "Ring No= de" as a node that actively participates in ring protection; this suggests = that there might be nodes that either passively participate in ring protect= ion, or do not participate in ring protection - so - is it possible for any such node to exist in a ring topology and= still have rig protection work correctly? - are their well understood requirements of such nodes (my concern= is to understand if there is anything that such a node might do that would= conceal the link status between Ring Nodes)? I strongly suspect that there is no hole here, but just want to make sure. I have had some difficulty in determining if the comments I made earlier ar= e entirely addressed by the changes you've made. I interleave the comments= I made and the way they seem to have been addressed below (hopefully nobod= y in this discussion suffers from red-green color blindness). Section 5.1 seems to indicate that the protection switching mode is a ring = characteristic - which strongly supports the need for consistency in protection switching mo= de in a ring. But I did not see an explicit statement to this effect elsewhere in the doc= ument. I would expect any such statement to occur at the point where the modes are= introduced (i.e. - in section 4.3). -3- the concern regarding the presence of different protection modes is removed by including a statement that all nodes in the ring MUST be provisioned in the same protection mode. To detect possible misconfiguration two bits are used in the RPS PDU that identify the protection switching mode which allows detection o= f any mis-configuration during provisioning. This change fully addresses this ambiguity. I would note that what you act= ually said in the draft is not quite the same as what you say in the mail b= elow (repeated directly above), because - in the draft - it says that rings= on a node "MUST use" (as opposed to "MUST be provisioned in"). This is a = minor point, however, and the draft wording is most likely more correct. In the Introduction for this draft, you summarize optimization features fro= m RFC 5654 as follows: a. Minimize the number of OAM entities for protection b. Minimize the number of elements of recovery c. Minimize the required label number d. Minimize the amount of control and management-plane transactions during maintenance operation e. Minimize the impact on information exchange during protection if a control plane is supported >From RFC 5654, the actual "optimization criteria" are: a. Minimize the number of OAM entities that are needed to trigger the recovery operation, such that it is less than is required by other recovery mechanisms. b. Minimize the number of elements of recovery in the ring, such that it is less than is required by other recovery mechanisms. c. Minimize the number of labels required for the protection paths across the ring, such that it is less than is required by other recovery mechanisms. d. Minimize the amount of control and management-plane transactions during a maintenance operation (e.g., ring upgrade), such that it is less than the amount required by other recovery mechanisms. e. When a control plane is supported, minimize the impact on signaling and routing information exchange during protection, such that it is less than the impact caused by other recovery mechanisms. The draft does not identify the list provided as a summary of the correlate= d "optimization criteria" from RFC 5654, and the summarized versions leave a lot of informa= tion out. This could be misleading and it would be useful to suggest to a reader that= they might look a at the actual criteria in RFC 5654 for more information. As an example of "missing information," the summarized versions do not indi= cate to what we would compare the minimizations in this draft to determine that they ach= ieve their (ambiguous) goals (i.e. "such that [the characteristic being minimized] is = less than [that same or similar characteristic] for other recovery mechanisms"). Additional "missing" information includes: a. "needed to trigger recovery" as opposed to "for protection." b. "in the ring" (possibly not important). c. "number of labels required for the protection paths across the ring" a= s opposed to "required label number" (remember that - to some people - labels are = numbers). d. an example is given of a maintenance operation (possibly not important= ). e. "signaling and routing information exchange" as opposed to "informatio= n exchange." Minimally, some wording improvements are required to align the text in this= draft with the corresponding text in RFC 5654. =3D=3D=3D=3D=3D In the second paragraph after bullet "e" on page 4, you state that "the sol= ution for point-to-multipoint transport paths is under study and will be presented in= a separate document." It is generally not a good idea for an Internet Draft to attemp= t to predict what may or may not happen in documents that are as yet unwritten. It is s= ufficient to say that "a solution for anything other than point-to-point transport pa= ths is out of scope in this document" (specifically - replace "under study and will be p= resented in a separate" with "out of scope in this"). Note that this means this document does not satisfy Requirement 95 from RFC= 5654. =3D=3D=3D=3D=3D When I see a statement along the lines of "This document elaborates on the = requirements in detail" - my immediate concern is that what might actually happen is tha= t requirements are going to be "restated" in some way that supports a new (or different) i= nterpretation or agenda. Please make it clearer what the intentions are for this document with respe= ct to RFC 5654. The Introduction claims that this document addresses ring protection requir= ements in RFC 5654, yet - once we get into section 2, we jumps right over requirement= s 92-104A to address the requirement that the protection mechanisms SHOULD protect ag= ainst multiple failures. Why is that? Perhaps the authors are already aware of an obvious set of mechanisms that = satisfy these earlier requirements (many of which are ones that MUST be met) and it= is then only necessary to delve more deeply into mechanisms that further satisfy th= is "SHOULD" be met requirement? If so, say so. If not, then provide some justification for why you want to address this so= mewhat soft requirement first. =3D=3D=3D=3D=3D Where - in RFC 5654 - does it state "recovery mechanisms which are optimize= d for ring topologies could be further developed if it can provide the following featu= res" (I couldn't discover that the word "developed" was used at all in RFC 5654, for instanc= e)? What it seems to say is that the recovery mechanisms applicable to generic recovery= may be optimized for specific topologies provided the optimizations meet the state= d criteria, and satisfy somewhat vague "cost-benefit" considerations. Perhaps you mean= t to say: "recovery mechanisms could be further optimized for ring topologies if thos= e further optimizations meet the following criteria" (or something along these lines)= ? =3D=3D=3D=3D=3D The first paragraph after bullet "e" on page 4 is awkward; I suggest replac= ing "those" with "the." Also note that the wording could use some minor improvement to avoid= giving the impression that the preceding list of "criteria" is not what you are referr= ing to here as "requirements on ring protection listed in RFC 5654." Perhaps stating the = actual number range (i.e. - 92-94 and 96-109) of requirements this document addresses; or= is the list of requirements this draft aims to address shorter than this? =3D=3D=3D=3D=3D Which requirements from RFC 5654 are addressed in section 2.2 (can you iden= tify them as part of this section). =3D=3D=3D=3D Which requirements from RFC 5654 are addressed in section 2.3 (can you iden= tify them as part of this section). -2- the referencing to RFC5654 has been improved What it looks like in comparing the two documents is that - for your first = step - you have removed the summary versions of the optimization requiremen= ts. This is one (and most likely the simplest) way to get rid of inconsist= encies. You then go on to be a lot more explicit about which requirements this docu= ment is specifically addressing. This fully addresses my comments with res= pect to RFC 5654. It also - incidentally - eliminates a few grammatical NI= Ts. Note that this took some looking into, because (for instance) of the way th= at you have re-ordered sections 2 and 3, thus requiring a detailed review o= f both the old and the new text to determine the real changes. Figure 1 (or at least part of the text describing it) appears to apply only= to the ingress port for Ring Tunnels; at an egress port, it is not a question of the port "can = carry" multiple ring tunnels, because it _does_ carry exactly 4 (per description in section 4.1.= 1). As near as I can tell, you did not identify how the above comment was addre= ssed. The wording appears to have been changed in minor ways. From this s= et of minor changes, it looks as if we are not necessarily talking about th= e same thing as "a port." I think I understand what you mean in your wordi= ng, now, so I feel this comment is adequately addressed by the minor change= s made. Having defined a notation for "label stack" in section 3, section 4 then fa= lls back to a more traditional notation. Is there a reason why you do not use the same notati= on consistently? Should you maybe include the possibility that the more traditional notation= might also be used when defining a different notation in section 3? The way I understand the notation defined in section 3, the label stack in = figure 2 would be shown as - [ Ring Tunnel Label | LSP Label | PW Label ] Payload - which seems simpler than the way it is currently depicted. Again, as near as I can tell, you did not identify how this comments was ad= dressed. However, I see that you now use both notations, making it at leas= t obvious how one maps to the other, therefore I feel that this comment is = fully addressed by your changes. Perhaps you should look again at the notation text in section 3. One notat= ion that you appear to be actually using is for an egress "" to define 4 tunnels as: RcW_ RaP_ RaW_ RcP_ For the first "reverse hop" in each tunnel, there is a label assigned by th= e egress corresponding to that tunnel. If you then construct a label-stack along the lines of the one above, the "= Ring Tunnel Label" would be whatever label corresponds to one of the above 4 tunnels (for that= "hop" it might be unnecessary to use parentheses to add the "Node Name" of the assigning n= ode to the label stack). For each subsequent "reverse hop", the label could presumably be assigned b= y the downstream end of the "hop" and the assigning node would be the same for RcW_ and R= cP_ (the node that is one "hop" clockwise from ), and a (probably different) assigning= node would be the same for RaW_ and RaP_ (the node that is one "hop" counter-clockwise = from ). In any case, the notation used to name Ring tunnels is not described in sec= tion 3. I assume that how LSP labels and PW labels are assigned is out of scope for= this draft. I see no indication that this comment has been addressed. Most of it was i= ntended as a suggestion, hence addressing those portions was not absolutely= necessary. I do, however, feel that section 2 (the re-ordered section that now address= es Notation) should include the way that tunnel naming in section 4.1.1 is = derived (see the accentuated part of the comment repeated above). The wording in section 4.1.3 is unclear; because you have not described the= mapping for Ring Tunnel Labels at each hop, it is not clear what it means when the "ingress = node on the ring pushes the working ring tunnel label according to the egress node" (chances= are pretty good the actual label pushed on by the Ring Tunnel ingress may not be the same label= that was assigned for the Ring Tunnel by the tunnel egress node (unless the particular tunnel= is one "hop" from the ingress to the egress node, or the labels are configured that way for all t= unnels at all ring nodes - which may not be possible). Section 4.1.2 should probably say a little bit more about assignment of Rin= g Tunnel Labels at each transit node in the ring. Again, as near as I can tell, you did not identify how this comments was ad= dressed. However, I see that the wording in question has been clarified. = This comment is fully addressed by your changes. What is meant in section 4.2 by "Two end ports of a link"? I assume this m= eans the ports that are used to connect two adjacent nodes on a ring, but "end ports" makes this un= clear. Again, as near as I can tell, you did not identify how this comments was ad= dressed. However, I see that you removed the word "end" and this should re= duce the possibility for misinterpretation. This comment is adequately addr= essed by the minor change made. There are issues with use of (or non-use of) normative language in section = 4.3. Is it the case that every node MUST obtain the ring topology (currently it says "can")? This seems important because it is not at all clear that ring-topology awar= eness is required to support either wrapping protection mode (this assumes that protection mode = is required to be consistent in a ring), since it seems that wrapping occurs at points where = the ring is broken, irrespective of the ring topology otherwise. Where is there a statement to the effect that the protection switching mode= in a single ring MUST be consistent? =3D=3D=3D=3D=3D For Steering (section 4.3.3), there are a few places where the description = might be easier to follow if there was a term (or expression) for "the ring node on which an LSP ente= rs the ring" - since this is (as I understand it) the ONLY ring node where the location of the failure d= etermines which ring the LSP traffic will be forwarded on. There may be an unwritten assumption associated with the use of Steering pr= otection switching mode - that is particularly obvious in the 2nd paragraph. As I understand = it, Steering mode is the only mode where ring topology information is needed by every ring node. This seems to be the case because steering mode is the only mode where the = decision as to which ring to use in forwarding LSP traffic is made at each node depending on whe= re that node is in the ring and where in the ring the failure has occurred. For the wrapping mode= s, the traffic is placed on the working ring by each node and only moved to a protection ring by the= ring node directly adjacent to the link or node failure. However, with respect to knowledge of ring-topology information, the draft = says only that this information is either configured or learned "via some topology discovery me= chanism" (in the 2nd paragraph, section 4.3). If it is the case that ring-topology awareness is only explicitly required = for steering mode, then the assumption that this information is known should be explicitly stated here = (if - as does not seem very likely, or possibly not necessary - this information is explicitly req= uired for all modes, then that should be made explicit in the use of normative language in section 4.3). This was (in part) addressed by the addition of a requirement for consisten= t protection modes in a ring. With that, and the change from "can" to "MUS= T" and other clarifying text throughout section 4, this comment is fully ad= dressed by your changes. There were a number of relatively minor comments/questions which I don't be= lieve have been answered or addressed: What does it mean to have no protection switching active on a ring (perhaps= you mean no protection switching in effect)? Or is this something that is a common understanding = among operators (i.e. - if protection switching is "active" this means that the protection switching m= echanisms enabled are in use as a result of a failure)? What exactly is a "failed span?" Here it would be good to know if there is a difference between a "span" and= a "link." If there is no difference, then why not use the same term? If = there is a difference, perhaps it should be defined in the terminology sect= ion. Based on usage in the draft, I suspect there is a difference between = a "span" and a "link." What does it mean to say that "Ring switches MUST be preempted by higher pr= iority RPS requests?" I assume this means that it must be possible to change the protection switc= hing state as a result of a higher priority RPS request - but this is not necessarily obvious. In the last paragraph of section 5.1 (immediately before section 5.1.1), yo= u say that "nodes do not preempt existing RPS requests unless they have a higher-priority RPS reques= t." Further, you imply that "knowledge of the state of the ring" is required to make this determin= ation. Exactly how does a ring node make this determination? A ring node can make= direct comparisons between an incoming RPS message type/priority and the RPS message type/prio= rity it would make based on local knowledge of the ring - but this does not require "knowledge= of the state of the ring" only knowledge of local ring-state. Moreover, "knowledge of the state of the ring" is often less than perfect, = if meant to apply to remote portions of the ring (an incoming RPS message is likely to reflect better k= nowledge of the ring-state than the ring node would otherwise likely have). The set of questions above is both complicated and inter-related. The main= thrust of the issue is that Ring Nodes only know what they know about the = state of the ring based on the most recently received set of RPS messages. = This information may be temporarily incorrect and there is no way for a Ri= ng Node to know if this is (or is not) the case. I am not certain that the= text in section 5 properly addresses how a deterministic state is necessar= ily arrived at independent of the order in which RPS messages are received. By having a strict prioritization between state indications, it should be t= he case that the "final" state arrived at would be deterministic based on a= n assumption that the RPS messages will provide a consistent "state of the = ring" within some period of time (because all ring nodes should agree as to= which indication has the highest priority). =3D=3D=3D=3D=3D For section 5.1.1 - exactly how is the recommended interval between RPS mes= sage reflecting new information determined? I can see that having an interval of 3.3 milliseco= nds would result in having sent 3 of them in slightly less than 10 milliseconds, but this may not be p= articularly relevant in the goal of a 50 millisecond protection switch completion if the mechanism is r= elying on RPS propagation around the ring the long way in order to detect a unidirectional link failu= re. =3D=3D=3D On page 28, what does this paragraph mean? "When multiple MS RPS requests over different spans exist at the same time,= no switch SHOULD be executed and existing switches MUST be dropped. The nodes MUST signal, any= way, the MS RPS request code." After looking a bit, "MS" probably means "Manual Switch" and this would imp= ly that the effect of having multiple manual switch commands should be that they nullify each oth= er. But what is the expected behavior if there are multiple manual switch commands in a ring an= d a ring node sends a "Signal Fail" RPS message? As near as I can tell, none of these comments and/or questions have resulte= d in any changes. Possibly the questions were answered in separate E-Mail which I have not ye= t uncovered. While I believe I know what (at least some of) these terms me= an, it is important to have this knowledge exist somewhere other than in th= e minds of experienced operators and people (vendors, operators and standar= ds developers) with SONET/SDH experience/awareness. If the authors all feel that there is no ambiguity, need for further clarif= ication or related issues with the way these issues are currently addresse= d/specified, I am happy to withdraw these questions and comments at least u= ntil such time as I have a better understanding of the issues. Section 6 - in effect, this section determines the value assignments that = will be used in the rest of the document. Therefore, the statement that "new values" are "defined in t= his document and summarized in this section" is not quite correct (because it implies that t= hey are defined elsewhere in this document and then summarized here). I suggest replacing " and summ= arized in this section" with "listed in the sections below" so that it would now read: "IANA is requested to administer the assignments of new values defined in t= his document and listed in the sections below." I will grant you that this seems a minor point; the code points are defined= here and their meaning and use is defined elsewhere in the document. But this section is about th= e code points and the need for IANA to create registries as needed and record these assignments. = Everything that IANA needs MUST be _included_ (not summarized) here. This comment was fully addressed in this version. Many NITs were not addressed: "()" Are called "parentheses" - now in section 2 (previously in section 3). "At the egress node, the traffic leave the ring ..." - "leave" should be "l= eaves" (even though "traffic" may be (and often is) plural, it is a group name (like "herd") so if it is = in the singular form, that is what the verb ("leave" in this case) has to match. Similar for the case with "... following sections describes ..." (should be= "... following sections describe ..."). So far, these are minor issues, and may be corrected by the RFC Editor. As a question on how the following NIT was addressed: Section 4.3.1 - "... tunnel can protect both the link failure and the node = failure" should probably be "... tunnel can protect against either a link failure or a node failure." The text now reads: "protect both link failures and node failures." Intuitively, this seems incorrect, because (intuitively) we don't "protect"= failures (we protect services against failures). I assume the authors cho= se this phrasing because (in this context) the meaning for "protect" differ= s slightly from the intuitive English meaning. Is this correct? If so, we= might want to add "Protect" to the terminology section as well. Section 4.3.2.1 - in the 4th sentence, "Rap_D" should be "RaP_D." While this one may be corrected via instructions to the RFC Editor, this is= not so much a spelling error as a Notation error and may not otherwise be = picked up by the RFC Editor. Section 4.3.3 - 1st sentence, "perform" should be "performs." Top of page 26, 2nd paragraph - "resulting the ring being ..." should proba= bly be "resulting in the ring being ..." (now the 4th paragraph, from the top of page 25). In section 5.1.3.2, "... to adjacent node ..." should probably be "... to a= djacent nodes ..." To be more specific, the 1st sentence in the section "A node in the switchi= ng state MUST source RPS request to adjacent node with its highest RPS requ= est code in both directions when it detects a failure or receives an extern= al command." When sourcing RPS messages in both directions I believe more = than one node will be the target for the RPS request (except in the trivial= case of a "ring" consisting of two nodes). On the last line on page 28, "Node" should probably be "The node." (Now the= last line before section 5.1.3.3 - though still on page 28) A few NITs I missed previously: In section 4.3, paragraph at the top of page 10, "impaced" should be "impac= ted" and "perform switching" should be "performs switching" ("the ingress n= ode ... performs switching ..."). -- Eric From: Huub van Helvoort [mailto:huubatwork@gmail.com] Sent: Thursday, October 06, 2016 3:27 PM To: Eric Gray ; mpls@ietf.org Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org; mpls-chairs@ietf.or= g Subject: Re: Working Group Last Call for draft-ietf-mpls-tp-shared-ring-pro= tection-02 Importance: High Hello Eric, You wrote: The below is my comments (as document shepherd) for the Working Group Last = Call on this draft. Comments: I support progression of this document after addressing a number of issues. As you may have noticed we, the editors/authors, have addressed your issues and uploaded a new version of the draft (see below). The main updates are: -1- reduction of the number of authors to 5 -2- the referencing to RFC5654 has been improved -3- the concern regarding the presence of different protection modes is removed by including a statement that all nodes in the ring MUST be provisioned in the same protection mode. To detect possible misconfiguration two bits are used in the RPS PDU that identify the protection switching mode which allows detection o= f any mis-configuration during provisioning. If you agree with these updates the document can be progressed. Best regards, Huub. -------- Forwarded Message -------- Subject: [mpls] I-D Action: draft-ietf-mpls-tp-shared-ring-protection-03.txt Date: Sat, 01 Oct 2016 06:16:10 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Shared-Ring protection (MSRP) mechanism for ring = topology Authors : Weiqiang Cheng Lei Wang Han Li Huub van Helvoort Jie Dong Filename : draft-ietf-mpls-tp-shared-ring-protection-03.txt Pages : 47 Date : 2016-10-01 Abstract: This document describes requirements, architecture and solutions for MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switch (RPS) Protocol that is used to coordinate the protection behavior of the nodes on MPLS ring. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-tp-shared-ring-protection-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-shared-ring-protecti= on-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... --_000_48E1A67CB9CA044EADFEAB87D814BFF64A911679eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Huub, et al,

 

     &nbs= p;          Sorry it has taken= me so long to reply.

 

     &nbs= p;          I have heard from = Loa that his comments have been addressed.

 

    &nbs= p;           The document= is much improved, but not quite there yet.

 

     &nbs= p;          I have noticed a f= ew NITs in the revised wording that can be dealt with via instructions to t= he RFC Editor (no action required by the Authors or Contributors unless addressing other issues anyway).<= /p>

 

     &nbs= p;          I have a pair of m= inor questions: you now define a “Ring Node” as a node that act= ively participates in ring protection; this suggests that there might be nodes that either passively participate in ring protection,= or do not participate in ring protection – so

-  &nb= sp;       is it possible for any suc= h node to exist in a ring topology and still have rig protection work corre= ctly?

-  &nb= sp;       are their well understood = requirements of such nodes (my concern is to understand if there is anythin= g that such a node might do that would conceal the link status between Ring Nodes)?

 

I stron= gly suspect that there is no hole here, but just want to make sure.

&n= bsp;

I have = had some difficulty in determining if the comments I made earlier are entir= ely addressed by the changes you’ve made.  I interleave the comments I made and the way they seem to have been addressed below (hopefully nobody in this discussion suffers= from red-green color blindness).

     &nbs= p;         

Section 5.1 seems to in= dicate that the protection switching mode is a ring characteristic -

which strongly supports= the need for consistency in protection switching mode in a ring.

But I did not see an ex= plicit statement to this effect elsewhere in the document. 

 

I would expect any such= statement to occur at the point where the modes are introduced

(i.e. - in section 4.3)= .

 

-3- the concern regard= ing the presence of different protection modes is
       removed by including a statement that = all nodes in the ring MUST be
       provisioned in the same protection mode.
       To detect possible misconfiguration two bits are= used in the RPS PDU
       that identify the protection switching mode whic= h allows detection of
       any mis-configuration during provisioning.<= /o:p>

 

This change fully addresses = this ambiguity.  I would note that what you actually said in the draft is not quite the same as wha= t you say in the mail below (repeated directly above), because – in t= he draft – it says that rings on a node “MUST use” (as op= posed to “MUST be provisioned in”).  This is a minor point= , however, and the draft wording is most likely more correct.

 

In the Introduction for= this draft, you summarize optimization features from RFC 5654 as

follows:

   a.  M= inimize the number of OAM entities for protection

   b.  M= inimize the number of elements of recovery

   c.  M= inimize the required label number

   d.  M= inimize the amount of control and management-plane transactions<= /span>

    = ;   during maintenance operation

   e.  M= inimize the impact on information exchange during protection if<= /span>

    = ;   a control plane is supported

 

>From RFC 5654, the = actual "optimization criteria" are:

 

   a.  M= inimize the number of OAM entities that are needed to trigger

    = ;   the recovery operation, such that it is less than is required= by

    = ;   other recovery mechanisms.

   b.  M= inimize the number of elements of recovery in the ring, such

    = ;   that it is less than is required by other recovery mechanisms= .

   c.  M= inimize the number of labels required for the protection paths

    = ;   across the ring, such that it is less than is required by oth= er

    = ;   recovery mechanisms.

   d.  M= inimize the amount of control and management-plane transactions<= /span>

    = ;   during a maintenance operation (e.g., ring upgrade), such tha= t it

    = ;   is less than the amount required by other recovery mechanisms= .

   e.  W= hen a control plane is supported, minimize the impact on<= /p>

    = ;   signaling and routing information exchange during protection,=

    = ;   such that it is less than the impact caused by other recovery=

    = ;   mechanisms.

 

The draft does not iden= tify the list provided as a summary of the correlated "optimization

criteria" from RFC= 5654, and the summarized versions leave a lot of information out. 

 

This could be misleadin= g and it would be useful to suggest to a reader that they might look a=

at the actual criteria = in RFC 5654 for more information.

 

As an example of "= missing information," the summarized versions do not indicate to what

we would compare the mi= nimizations in this draft to determine that they achieve their

(ambiguous) goals (i.e.= "such that [the characteristic being minimized] is less than [that

same or similar charact= eristic] for other recovery mechanisms").

 

Additional "missin= g" information includes:

  a. "needed = to trigger recovery" as opposed to "for protection."

  b. "in the = ring" (possibly not important).

  c. "number = of labels required for the protection paths across the ring" as oppose= d to

    = ;  "required label number" (remember that - to some peo= ple - labels are numbers).

  d. an example is= given of a maintenance operation (possibly not important).

  e. "signali= ng and routing information exchange" as opposed to "information e= xchange."

 

Minimally, some wording= improvements are required to align the text in this draft with the

corresponding text in R= FC 5654.

 

=3D=3D=3D=3D=3D

 

In the second paragraph= after bullet "e" on page 4, you state that "the solution fo= r

point-to-multipoint tra= nsport paths is under study and will be presented in a separate

document."  I= t is generally not a good idea for an Internet Draft to attempt to predict

what may or may not hap= pen in documents that are as yet unwritten.  It is sufficient

to say that "a sol= ution for anything other than point-to-point transport paths is out of

scope in this document&= quot;  (specifically - replace "under study and will be presented= in

a separate" with &= quot;out of scope in this").

 

Note that this means th= is document does not satisfy Requirement 95 from RFC 5654.

 

=3D=3D=3D=3D=3D

 

When I see a statement = along the lines of "This document elaborates on the requirements

in detail" - my im= mediate concern is that what might actually happen is that requirements

are going to be "r= estated" in some way that supports a new (or different) interpretation= or

agenda.

 

Please make it clearer = what the intentions are for this document with respect to RFC 5654.

 

The Introduction claims= that this document addresses ring protection requirements in

RFC 5654, yet - once we= get into section 2, we jumps right over requirements 92-104A

to address the requirem= ent that the protection mechanisms SHOULD protect against

multiple failures. = ; Why is that? 

 

Perhaps the authors are= already aware of an obvious set of mechanisms that satisfy

these earlier requireme= nts (many of which are ones that MUST be met) and it is then

only necessary to delve= more deeply into mechanisms that further satisfy this

"SHOULD" be m= et requirement? 

 

If so, say so. 

 

If not, then provide so= me justification for why you want to address this somewhat soft

requirement first.=

 

=3D=3D=3D=3D=3D

 

Where - in RFC 5654 - d= oes it state "recovery mechanisms which are optimized for ring

topologies could be fur= ther developed if it can provide the following features" (I couldn't

discover that the word = "developed" was used at all in RFC 5654, for instance)?  Wha= t it

seems to say is that th= e recovery mechanisms applicable to generic recovery may be

optimized for specific = topologies provided the optimizations meet the stated criteria,<= /span>

and satisfy somewhat va= gue "cost-benefit" considerations.  Perhaps you meant to say= :

"recovery mechanis= ms could be further optimized for ring topologies if those further

optimizations meet the = following criteria" (or something along these lines)?

 

=3D=3D=3D=3D=3D

 

The first paragraph aft= er bullet "e" on page 4 is awkward; I suggest replacing "tho= se" with

"the.” Also = note that the wording could use some minor improvement to avoid giving the<= o:p>

impression that the pre= ceding list of "criteria" is not what you are referring to here a= s

"requirements on r= ing protection listed in RFC 5654."  Perhaps stating the actual n= umber

range (i.e. - 92-94 and= 96-109) of requirements this document addresses; or is the list of

requirements this draft= aims to address shorter than this?

 

=3D=3D=3D=3D=3D

 

Which requirements from= RFC 5654 are addressed in section 2.2 (can you identify them

as part of this section= ).

=3D=3D=3D=3D=

 

Which requirements from= RFC 5654 are addressed in section 2.3 (can you identify them

as part of this section= ).

 

-2- the referencing to= RFC5654 has been improved

 

What it looks like in comparing th= e two documents is that – for your first step – you have remove= d the summary versions of the optimization requirements.  This is one (and most likely the simplest) way to get rid of inconsistenci= es.

 

You then go on to be a lot more ex= plicit about which requirements this document is specifically addressing.&n= bsp; This fully addresses my comments with respect to RFC 5654.  = It also – incidentally – eliminates a few grammatical NITs.=

 

Note that this took some looking i= nto, because (for instance) of the way that you have re-ordered sections 2 = and 3, thus requiring a detailed review of both the old and the new text to determine the real changes.<= /p>

 

Figure 1 (or at least p= art of the text describing it) appears to apply only to the ingress port

for Ring Tunnels; at an= egress port, it is not a question of the port "can carry" multip= le ring

tunnels, because it _do= es_ carry exactly 4 (per description in section 4.1.1).

 

As near as I can tell, you did not= identify how the above comment was addressed.  The wording appears to= have been changed in minor ways.  From this set of minor changes, it looks as if we are not necessarily talking about the sam= e thing as “a port.”  I think I understand what you mean i= n your wording, now, so I feel this comment is adequately addressed by the minor changes made.

 

Having defined a notati= on for "label stack" in section 3, section 4 then falls back to a= more

traditional notation.&n= bsp; Is there a reason why you do not use the same notation consistently?

Should you maybe includ= e the possibility that the more traditional notation might also be

used when defining a di= fferent notation in section 3?

 

The way I understand th= e notation defined in section 3, the label stack in figure 2 would be<= /o:p>

shown as -

 

    = ;            [ Ring = Tunnel Label | LSP Label | PW Label ] Payload

 

- which seems simpler t= han the way it is currently depicted.

 

Again, as near as I can tell, you = did not identify how this comments was addressed.  However, I see that= you now use both notations, making it at least obvious how one maps to the other, therefore I feel that this comment is ful= ly addressed by your changes.

 

Perhaps you should look= again at the notation text in section 3.  One notation that you appea= r

to be actually using is= for an egress "<X>" to define 4 tunnels as:

    = ;            RcW_<= ;X>

    = ;            RaP_<= ;X>

    = ;            RaW_<= ;X>

    = ;            RcP_<= ;X>

 

For the first "rev= erse hop" in each tunnel, there is a label assigned by the egress corr= esponding

to that tunnel.

 

If you then construct a= label-stack along the lines of the one above, the "Ring Tunnel Label&= quot;

would be whatever label= corresponds to one of the above 4 tunnels (for that "hop" it mig= ht

be unnecessary to use p= arentheses to add the "Node Name" of the assigning node to the

label stack).

 

For each subsequent &qu= ot;reverse hop", the label could presumably be assigned by the downstr= eam

end of the "hop&qu= ot; and the assigning node would be the same for RcW_<X> and RcP_<= X> (the node

that is one "hop&q= uot; clockwise from <X>), and a (probably different) assigning node w= ould be the

same for RaW_<X> = and RaP_<X> (the node that is one "hop" counter-clockwise f= rom <X>).

 

In any case, t= he notation used to name Ring tunnels is not described in section 3.

 

I assume that how LSP l= abels and PW labels are assigned is out of scope for this draft.=

 

I see no indication that this comm= ent has been addressed.  Most of it was intended as a suggestion, henc= e addressing those portions was not absolutely necessary.=

 

I do, however, feel that section 2= (the re-ordered section that now addresses Notation) should include the way that tunnel naming in sectio= n 4.1.1 is derived (see the accentuated part of the comment repeated above)= .

 

The wording in section = 4.1.3 is unclear; because you have not described the mapping for Ring

Tunnel Labels at each h= op, it is not clear what it means when the "ingress node on the ring

pushes the working ring= tunnel label according to the egress node" (chances are pretty good t= he

actual label pushed on = by the Ring Tunnel ingress may not be the same label that was assigned

for the Ring Tunnel by = the tunnel egress node (unless the particular tunnel is one "hop"= from the

ingress to the egress n= ode, or the labels are configured that way for all tunnels at all ring node= s

- which may not be poss= ible).

 

Section 4.1.2 should pr= obably say a little bit more about assignment of Ring Tunnel Labels at=

each transit node in th= e ring.

 

Again, as near as I can tell, you = did not identify how this comments was addressed.  However, I see that= the wording in question has been clarified.  This comment is fully addressed by your changes.

 

What is meant in sectio= n 4.2 by "Two end ports of a link"?  I assume this means the= ports that are

used to connect two adj= acent nodes on a ring, but "end ports" makes this unclear.

 

Again, as near as I can tell, you = did not identify how this comments was addressed.  However, I see that= you removed the word “end” and this should reduce the possibility for misinterpretation. This comment is adequately ad= dressed by the minor change made.

 

There are issues with u= se of (or non-use of) normative language in section 4.3.  Is it the ca= se that

every node MUST obtain = the ring topology (currently it says "can")? 

 

This seems important be= cause it is not at all clear that ring-topology awareness is required to

support either wrapping= protection mode (this assumes that protection mode is required to be

consistent in a ring), = since it seems that wrapping occurs at points where the ring is broken,

irrespective of the rin= g topology otherwise.

 

Where is there a statem= ent to the effect that the protection switching mode in a single ring MUST<= o:p>

be consistent?

 

=3D=3D=3D=3D=3D

 

For Steering (section 4= .3.3), there are a few places where the description might be easier to foll= ow

if there was a term (or= expression) for "the ring node on which an LSP enters the ring" = - since this is

(as I understand it) th= e ONLY ring node where the location of the failure determines which ring th= e

LSP traffic will be for= warded on.

 

There may be an unwritt= en assumption associated with the use of Steering protection switching

mode - that is particul= arly obvious in the 2nd paragraph.  As I understand it, Steering mode = is the

only mode where ring to= pology information is needed by every ring node. 

 

This seems to be the ca= se because steering mode is the only mode where the decision as to which

ring to use in forwardi= ng LSP traffic is made at each node depending on where that node is in the<= o:p>

ring and where in the r= ing the failure has occurred.  For the wrapping modes, the traffic is = placed

on the working ring by = each node and only moved to a protection ring by the ring node directly

adjacent to the link or= node failure.

 

However, with respect t= o knowledge of ring-topology information, the draft says only that this

information is either c= onfigured or learned "via some topology discovery mechanism" (in = the 2nd

paragraph, section 4.3)= .

 

If it is the case that = ring-topology awareness is only explicitly required for steering mode, then= the

assumption that this in= formation is known should be explicitly stated here (if - as does not seem

very likely, or possibl= y not necessary - this information is explicitly required for all modes, th= en that

should be made explicit= in the use of normative language in section 4.3).

 

This was (in part) addressed by th= e addition of a requirement for consistent protection modes in a ring. = ; With that, and the change from “can” to “MUST” an= d other clarifying text throughout section 4, this comment is fully ad= dressed by your changes.

 

There were a number of relatively = minor comments/questions which I don’t believe have been answered or = addressed:

What does it mean to ha= ve no protection switching active on a ring (perhaps you mean no protection=

switching in effect)?&n= bsp; Or is this something that is a common understanding among operators (i= .e. - if

protection switching is= "active" this means that the protection switching mechanisms ena= bled are in

use as a result of a fa= ilure)?

 

What exactly is a= "failed span?"

 

Here it would be good to know if there is a diffe= rence between a “span” and a “link.”  If there= is no difference, then why not use the same term?  If there is a diff= erence, perhaps it should be defined in the terminology section.  Base= d on usage in the draft, I suspect there is a differenc= e between a “span” and a “link.” 

 

What does it mean to sa= y that "Ring switches MUST be preempted by higher priority RPS request= s?"

I assume this means tha= t it must be possible to change the protection switching state as a result = of a

higher priority RPS req= uest - but this is not necessarily obvious.

 

In the last paragraph o= f section 5.1 (immediately before section 5.1.1), you say that "nodes = do not

preempt existing RPS re= quests unless they have a higher-priority RPS request."  Further,= you imply

that "knowledge of= the state of the ring" is required to make this determination. 

 

Exactly how does a ring= node make this determination?  A ring node can make direct comparison= s

between an incoming RPS= message type/priority and the RPS message type/priority it would make=

based on local knowledg= e of the ring - but this does not require "knowledge of the state of t= he ring"

only knowledge of local= ring-state.

 

Moreover, "knowled= ge of the state of the ring" is often less than perfect, if meant to a= pply to remote

portions of the ring (a= n incoming RPS message is likely to reflect better knowledge of the ring-st= ate

than the ring node woul= d otherwise likely have).

 

The set of questions above is both= complicated and inter-related.  The main thrust of the issue is that = Ring Nodes only know what they know about the state of the ring based on the most recently received set of RPS messages. = This information may be temporarily incorrect and there is no way for a Ri= ng Node to know if this is (or is not) the case.  I am not certain tha= t the text in section 5 properly addresses how a deterministic state is necessarily arrived at independent of the ord= er in which RPS messages are received. 

 

By having a strict prioritization = between state indications, it should be the case that the “final̶= 1; state arrived at would be deterministic based on an assumption that the RPS messages will provide a consistent “state of the ring&#= 8221; within some period of time (because all ring nodes should agree as to= which indication has the highest priority).

 

=3D=3D=3D=3D=3D

 

For section 5.1.1 - exa= ctly how is the recommended interval between RPS message reflecting new

information determined?=   I can see that having an interval of 3.3 milliseconds would result i= n having

sent 3 of them in sligh= tly less than 10 milliseconds, but this may not be particularly relevant in= the

goal of a 50 millisecon= d protection switch completion if the mechanism is relying on RPS propagati= on

around the ring the lon= g way in order to detect a unidirectional link failure.

 

=3D=3D=3D

 

On page 28, what does t= his paragraph mean?

 

"When multiple MS = RPS requests over different spans exist at the same time, no switch SHOULD = be

executed and existing s= witches MUST be dropped.  The nodes MUST signal, anyway, the MS RPS

request code."

 

After looking a bit, &q= uot;MS" probably means "Manual Switch" and this would imply = that the effect of

having multiple manual = switch commands should be that they nullify each other.  But what is t= he

expected behavior if th= ere are multiple manual switch commands in a ring and a ring node sends

a "Signal Fail&quo= t;  RPS message?

 

As near as I can tell, none of the= se comments and/or questions have resulted in any changes.

 

Possibly the questions were answer= ed in separate E-Mail which I have not yet uncovered.  While I believe= I know what (at least some of) these terms mean, it is important to have this knowledge exist somewhere other than in the mind= s of experienced operators and people (vendors, operators and standards dev= elopers) with SONET/SDH experience/awareness.

 

If the authors all feel that there= is no ambiguity, need for further clarification or related issues with the= way these issues are  currently addressed/specified, I am happy to withdraw these questions and comments at least until such ti= me as I have a better understanding of the issues.

 

Section 6 - in effect, = this section determines  the value assignments that will be used in th= e rest of

the document.  The= refore, the statement that "new values" are "defined in this= document and

summarized in this sect= ion" is not quite correct (because it implies that they are defined el= sewhere

in this document and th= en summarized here).  I suggest replacing " and summarized in thi= s section"

with "listed in th= e sections below" so that it would now read:

 

"IANA is requested= to administer the assignments of new values defined in this document and l= isted

in the sections below.&= quot;

 

I will grant you that t= his seems a minor point; the code points are defined here and their meaning=

and use is defined else= where in the document.  But this section is about the code points and = the

need for IANA to create= registries as needed and record these assignments.  Everything that I= ANA

needs MUST be _included= _ (not summarized) here.

 

This comment was fully addre= ssed in this version.

 

Many NITs were not addressed:

 

"()" Are called = "parentheses" - now in section = 2 (previously in section 3).

 

"At the egress nod= e, the traffic leave the ring ..." - "leave" should be "= ;leaves" (even though "traffic"

may be (and often is) p= lural, it is a group name (like "herd") so if it is in the singul= ar form, that is what

the verb ("leave&q= uot; in this case) has to match.

 

Similar for the case wi= th "... following sections describes ..." (should be "... fo= llowing sections describe

...").<= /span>

 

So far, these are minor issues, an= d may be corrected by the RFC Editor.

 

As a question on how the following= NIT was addressed:

 

Section 4.3.1 - ".= .. tunnel can protect both the link failure and the node failure" shou= ld probably be "...

tunnel can protect agai= nst either a link failure or a node failure."

 

The text now reads: “protect= both link failures and node failures.”

 

Intuitively, this seems incorrect,= because (intuitively) we don’t “protect” failures (we pr= otect services against failures).  I assume the = authors chose this phrasing because (in this context) the meaning for ̶= 0;protect” differs slightly from the intuitive English meaning.  Is this correct?  If so, we might want to add “Pro= tect” to the terminology section as well.

 

Section 4.3.2.1 - in th= e 4th sentence, "Rap_D" should be "RaP_D."

 

While this one may be corrected vi= a instructions to the RFC Editor, this is not so much a spelling error as a Notation error and may not otherwise be picked up by the RFC = Editor.

 

Section 4.3.3 - 1st sen= tence, "perform" should be "performs."

 

Top of page 26, 2nd par= agraph - "resulting the ring being ..." should probably be "= resulting in the

ring being ..." (now the 4th paragraph, from the top of page 25).

 

In section 5.1.3.2, &qu= ot;... to adjacent node ..." should probably be "... to adjacent = nodes ..."

 

To be more specific, the 1st sentence = in the section “A node in the switching state MUST source RPS request to ad= jacent node with its highest RPS request code in both directions when i= t detects a failure or receives an external command.”  W= hen sourcing RPS messages in both directions I believe more than one node will be the t= arget for the RPS request (except in the trivial case of a “ring̶= 1; consisting of two nodes).

 

On the last line on pag= e 28, "Node" should probably be "The node." (Now the last line before section 5.1.3.3 – though still on pa= ge 28)

 

A few NITs I missed previously:

 

In section 4.3, paragraph at the t= op of page 10, “impaced” should be “impacted” and &= #8220;perform switching” should be “performs switching” (= “the ingress node … performs switching …”).

 

--

Eric

 

From: Huub van Helvoort [mailto:huubatwork@gmail.com]
Sent: Thursday, October 06, 2016 3:27 PM
To: Eric Gray <eric.gray@ericsson.com>; mpls@ietf.org
Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org; mpls-chairs@= ietf.org
Subject: Re: Working Group Last Call for draft-ietf-mpls-tp-shared-r= ing-protection-02
Importance: High

 

Hello Eric,

You wrote:

The below is my comments (as document shepherd) for the Working Group =
Last Call on 
this draft.
 
Comments:
 
I support progression of this document after addressing a number of is=
sues.


As you may have noticed we, the editors/authors, have addressed your issues=
and uploaded a new version of the draft (see below).

The main updates are:
-1- reduction of the number of authors to 5
-2- the referencing to RFC5654 has been improved
-3- the concern regarding the presence of different protection modes is
       removed by including a statement that = all nodes in the ring MUST be
       provisioned in the same protection mode.
       To detect possible misconfiguration two bits are= used in the RPS PDU
       that identify the protection switching mode whic= h allows detection of
       any mis-configuration during provisioning.<= /o:p>

If you agree with these updates the document can be progressed.

Best regards, Huub.


-------- Forwarded Message --------

Subjec= t:

[mpls] I-D Action: draft-ietf-mpls-tp-shared-ring-pr= otection-03.txt

Date: =

Sat, 01 Oct 2016 06:16:10 -0700

From: =

internet= -drafts@ietf.org

To:

i-d-announc= e@ietf.org

CC:

mpls@ietf.org

 

A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
This draft is a work item of the Multiprotocol Label Switching of the =
IETF.
 
        Title   &nbs=
p;       : Shared-Ring protection (MSRP) mech=
anism for ring topology
        Authors   &n=
bsp;     : Weiqiang Cheng
           &nbs=
p;            &=
nbsp; Lei Wang
           &nbs=
p;            &=
nbsp; Han Li
           &nbs=
p;            &=
nbsp; Huub van Helvoort
           &nbs=
p;            &=
nbsp; Jie Dong
        Filename   &=
nbsp;    : draft-ietf-mpls-tp-shared-ring-protection-03.txt<=
o:p>
        Pages   &nbs=
p;       : 47
        Date    =
;        : 2016-10-01
 
Abstract:
   This document describes requirements, architecture and so=
lutions for
   MPLS-TP Shared Ring Protection (MSRP) in a ring topology =
for point-
   to-point (P2P) services.  The MSRP mechanism is desc=
ribed to meet the
   ring protection requirements as described in RFC 5654.&nb=
sp; This document
   defines the Ring Protection Switch (RPS) Protocol that is=
 used to
   coordinate the protection behavior of the nodes on MPLS r=
ing.
 
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-share=
d-ring-protection/
 
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-tp-shared-ring-p=
rotection-03
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-=
tp-shared-ring-protection-03
 
 
Please note that it may take a couple of minutes from the time of subm=
ission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/int=
ernet-drafts/


 


_______________________________________________


mpls mailing list


mpls@ietf.org


https://www.iet=
f.org/mailman/listinfo/mpls

 

 

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Always remember that you are unique...just like everyone else...<=
/o:p>
--_000_48E1A67CB9CA044EADFEAB87D814BFF64A911679eusaamb107erics_-- From nobody Mon Oct 17 20:05:53 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA141294AB; Mon, 17 Oct 2016 20:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXIzY2h8SVMx; Mon, 17 Oct 2016 20:05:46 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 0C42B12711D; Mon, 17 Oct 2016 20:05:46 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b81so318809696lfe.1; Mon, 17 Oct 2016 20:05:45 -0700 (PDT) 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; bh=HzDZIV8u2XY0+H9y3DH+iMoxZPiN+TwRTngIzrLTxZI=; b=FNH1u2r1rFmXlG6sAATu+T3B5O52FN3fhWEriR3PgKQonkn0mLjdCbTpDQ80kbjCHF Fjbpz0IJbYA9O2AkqgYWMhAc3rmqlfD//bLSxtBq7uEll39EWMTIEDT4mWUeTpHs7Jts zN+VSH5sy+OhdeJGbqNfg377fkxuVrBdM2urg8UwjG9ZhuoW5Iv86DixEQbu8iUma3BX /u4EPrgKHxj/ASIVJagHSUF4bA4GKaoDWBgjXHr3ljYNgyo/idi4aJuvPaFq8gfn79yX susyJlhlZk9Lu6nfSVI4KltbnVbbojyraglfcg7HpvJCcv1XwCWxSxL+pP+lRnGsQujz xZvg== 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; bh=HzDZIV8u2XY0+H9y3DH+iMoxZPiN+TwRTngIzrLTxZI=; b=NSvehUV4tYndyPq1RFa9wwRVi9I3hqnB7lOVhX9PrsK9If5EdcPhaPtJQHntBtjBTY Pey55H7AbRtvNe5RHYbxDzobB9085KdCY3yXstD3RxY614T2NdO17o/wNbPq/Tt8tPwD vLPKTUsEzUsjOSIk+rXtRKaOxK1/k6+YP3sOncn/DhtsjFTVqYvJyHNMWHQdZx+ybs/6 JHpOp/lXAYpWV8vPgcaJDcTGdmKSdGdAcun3JyaWVQJfONEOLIZfcUvaE+vOqtlgyqll vWkWN/eiOONmyPAdSjq5NYFhdP389auP0L6vigOffdWceQaNBCAthVkWKbdfS/3xJPHD 93xg== X-Gm-Message-State: AA6/9RnpwVLCvV8oVsC+O3rq+RrKVCIa0gVWGgbeuoCdvWcGfeqaMp3Vvj7rEuB3hcx0kyUuVK2pYisN01yK6A== X-Received: by 10.28.25.134 with SMTP id 128mr9596811wmz.99.1476759944173; Mon, 17 Oct 2016 20:05:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.154.66 with HTTP; Mon, 17 Oct 2016 20:05:43 -0700 (PDT) In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A29221AAD@SMTP2.etri.info> References: <5B4A6CBE3924BB41A3BEE462A8E0B75A29221AAD@SMTP2.etri.info> From: Joan Cucchiara Date: Mon, 17 Oct 2016 23:05:43 -0400 Message-ID: To: =?UTF-8?B?66WY7KCV64+Z?= Content-Type: multipart/alternative; boundary=001a114d46b8e41c4d053f1af7fb Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-linear-protection-mib@ietf.org" , "mib-doctors@ietf.org" , "mpls-chairs@ietf.org" , Benoit Claise Subject: Re: [mpls] =?utf-8?b?7ZqM7IugOiBNSUIgRHIuIHJldmlldyBvZiBkcmFmdC1pZXRm?= =?utf-8?q?-tp-linear-mib-09?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 03:05:48 -0000 --001a114d46b8e41c4d053f1af7fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jeong-dong, Thank you for the quick turn-around and also for the thoroughness of addressing this last round of comments. I believe the MIB review is complete. Thanks again for all your time and effort during this process, -Joan On Wed, Oct 12, 2016 at 10:29 AM, =EB=A5=98=EC=A0=95=EB=8F=99 wrote: > Dear Joan, > > Thank you so much for your review and comments. > All your comments had been incorporated into the revision posted a few > minutes ago as follows. > > Name: draft-ietf-mpls-tp-linear-protection-mib > Revision: 10 > Title: MPLS Transport Profile Linear Protection MIB > Document date: 2016-10-12 > Group: mpls > Pages: 45 > URL: https://www.ietf.org/internet-drafts/draft-ietf-mpls-tp- > linear-protection-mib-10.txt > Status: https://datatracker.ietf.org/ > doc/draft-ietf-mpls-tp-linear-protection-mib/ > Htmlized: https://tools.ietf.org/html/draft-ietf-mpls-tp-linear- > protection-mib-10 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp- > linear-protection-mib-10 > > Would you please let us know if you have any further comments on this > document at your earliest convenience? > > Best reagrds, > > Jeong-dong > > > > ________________________________________ > =EB=B3=B4=EB=82=B8 =EC=82=AC=EB=9E=8C: Joan Cucchiara [jcucchiara.ietf@gm= ail.com] > =EB=B3=B4=EB=82=B8 =EB=82=A0=EC=A7=9C: 2016=EB=85=84 10=EC=9B=94 8=EC=9D= =BC =ED=86=A0=EC=9A=94=EC=9D=BC =EC=98=A4=EC=A0=84 9:53 > =EB=B0=9B=EB=8A=94 =EC=82=AC=EB=9E=8C: Loa Andersson; mpls@ietf.org; draf= t-ietf-mpls-tp-linear- > protection-mib@ietf.org; mpls-chairs@ietf.org; mib-doctors@ietf.org > =EC=B0=B8=EC=A1=B0: =EB=A5=98=EC=A0=95=EB=8F=99; Benoit Claise > =EC=A0=9C=EB=AA=A9: MIB Dr. review of draft-ietf-tp-linear-mib-09 > > Authors, > > Thank you for addressing the comments so thoroughly, and especially for > clarifying the example in section 7. Much appreciated. > > The MIB compiles with smilint and smicngPRO. Comments are below. > > Thank you, > -Joan > > Comments: > ---------------- > > 1) Section 6.1 Relationship to the MPLS OAM Maintenance Identifiers MIB > Module > > "The mplsLpsMeConfigTable entry is extended by the entry in the > mplsOamIdMeTable defined in [RFC7697]." > > The above statement is backwards....think the intention is to say > something like: > Entries in the mplsOamIdMeTable [RFC7697] are extended by entries in the > mplsLspMeConfigTable. > > 2) later in this same section, section 6.1 > > "An entry of this table is related to a single entry in > mplsOamIdMeTable." > > The above is confusing because you've already discuss the sparse augments > relationship. Please remove > the above sentence. > > > MIB Module > ------------ > 3) mplsLpsConfigIndexNext - please rename to > mplsLpsConfigDomainIndexNext. > Since this scalar is only used for the mplsLpsConfigDomainIndex index's > values, the name should reflect that. > NOTE: this name change should be propagated elsewhere in the draft. > Please do a search and replace. > > 4) mplsLpsConfigDomainIndex (editorial) > "Managers should..." > > s/Managers/Operators/ > > > 5) mplsLpsConfigCommand > Why is there NO DEVAL? Wouldn't "noCmd" be an appropriate DEFVAL? > > > 6) mplsLpsConfigRowStatus DESCRIPTION clause > > RowStatus objects reflect the status of the Row, not a determination of > whether or not values > are "appropriate". Please remove the last sentence of this DESCRIPTION: > > "...An entry may not exist in the active state unless all > objects in the entry have an appropriate value." > > > 7) mplsLpsConfigDomainIndex and mplsLpsMeConfigDomain > > Since MIBs often get stripped out of RFCs, the relationship between the > mplsLpsConfigDomainIndex and > the mplsLpsMeConfigDomain needs to be included in the MIB Module itself. > > Both DESCRIPTION clauses need to be updated to describe the relationship > between these objects. Verbage such as "When the > value of mplsLpsConfigDomainIndex is the same as the value of > mplsLpsMeConfigDomain, that means..." and then explain what > this means. > > 8) mplsLpsMeConfigDomain DESCRIPTION (editorial) > "This object holds the value of protection domain index wherein > this ME included in. > > s/included in/is included/ > > --- > > > --001a114d46b8e41c4d053f1af7fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeong-dong,

Thank you for the = quick turn-around and also for the thoroughness of addressing this last rou= nd of comments.=C2=A0=C2=A0 I believe the MIB review is complete.

Thanks again for all your time and effort during this process,
-Joan


On Wed, Oct 12, 2016 at 10:29 AM, =EB=A5=98=EC=A0=95=EB=8F=99 <ryoo@etri= .re.kr> wrote:
Dear Joan,
Thank you so much for your review and comments.
All your comments had been incorporated into the revision posted a few minu= tes ago as follows.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-mpls-tp-linear-protection-mib
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A010
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MPLS Transport Profile Linear Prot= ection MIB
Document date:=C2=A0 2016-10-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mpls
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 45
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/dra= ft-ietf-mpls-tp-linear-protection-mib-10.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-lin= ear-protection-mib/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-mpls-tp-linear-prot= ection-mib-10
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-iet= f-mpls-tp-linear-protection-mib-10

Would you please let us know if you have any further comments on this docum= ent at your earliest convenience?

Best reagrds,

Jeong-dong



________________________________________
=EB=B3=B4=EB=82=B8 =EC=82=AC=EB=9E=8C: Joan Cucchiara [jcucchiara.ietf@gmail.com]
=EB=B3=B4=EB=82=B8 =EB=82=A0=EC=A7=9C: 2016=EB=85=84 10=EC=9B=94 8=EC=9D=BC= =ED=86=A0=EC=9A=94=EC=9D=BC =EC=98=A4=EC=A0=84 9:53
=EB=B0=9B=EB=8A=94 =EC=82=AC=EB=9E=8C: Loa Andersson; mpls@ietf.org; draft-ietf-mpls-tp-linear-protection-mib@ietf= .org; mpls-chairs@ietf.org;= mib-doctors@ietf.org
=EC=B0=B8=EC=A1=B0: =EB=A5=98=EC=A0=95=EB=8F=99; Benoit Claise
=EC=A0=9C=EB=AA=A9: MIB Dr. review of draft-ietf-tp-linear-mib-09

Authors,

Thank you for addressing the comments so thoroughly, and especially for
clarifying the example in section 7.=C2=A0 =C2=A0 Much appreciated.

The MIB compiles with smilint and smicngPRO.=C2=A0 =C2=A0Comments are below= .

Thank you,
-Joan

Comments:
----------------

1) Section 6.1 Relationship to the MPLS OAM Maintenance Identifiers MIB Mod= ule

=C2=A0 =C2=A0"The mplsLpsMeConfigTable entry is extended by the entry = in the
=C2=A0 =C2=A0mplsOamIdMeTable defined in [RFC7697]."

The above statement is backwards....think the intention is to say something= like:
Entries in the mplsOamIdMeTable [RFC7697] are extended by entries in the mp= lsLspMeConfigTable.

2) later in this same section, section 6.1

=C2=A0 =C2=A0"An entry of this table is related to a single entry in m= plsOamIdMeTable."

The above is confusing because you've already discuss the sparse augmen= ts relationship.=C2=A0 Please remove
the above sentence.


MIB Module
------------
3)=C2=A0 mplsLpsConfigIndexNext=C2=A0 -=C2=A0 =C2=A0please rename to mplsLp= sConfigDomainIndexNext.
Since this scalar is only used for the mplsLpsConfigDomainIndex index's= values, the name should reflect that.
NOTE:=C2=A0 this name change should be propagated elsewhere in the draft.= =C2=A0 Please do a search and replace.

4) mplsLpsConfigDomainIndex=C2=A0 (editorial)
=C2=A0 "Managers should..."

s/Managers/Operators/


5) mplsLpsConfigCommand
Why is there NO DEVAL?=C2=A0 =C2=A0Wouldn't "noCmd" be an app= ropriate DEFVAL?


6) mplsLpsConfigRowStatus DESCRIPTION clause

RowStatus objects reflect the status of the Row, not a determination of whe= ther or not values
are "appropriate".=C2=A0 Please remove the last sentence of this = DESCRIPTION:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"...An entry may not exist in the ac= tive state unless all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 objects in the entry have an appropriate= value."


7)=C2=A0 mplsLpsConfigDomainIndex and mplsLpsMeConfigDomain

Since MIBs often get stripped out of RFCs, the relationship between the mpl= sLpsConfigDomainIndex and
the mplsLpsMeConfigDomain needs to be included in the MIB Module itself.
Both DESCRIPTION clauses need to be updated to describe the relationship be= tween these objects.=C2=A0 =C2=A0Verbage such as "When the
value of mplsLpsConfigDomainIndex is the same as the value of mplsLpsMeConf= igDomain, that means..." and then explain what
this means.

8)=C2=A0 mplsLpsMeConfigDomain DESCRIPTION (editorial)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"This object holds the value of prot= ection domain index wherein
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this ME included in.

s/included in/is included/

---



--001a114d46b8e41c4d053f1af7fb-- From nobody Tue Oct 18 01:43:51 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585FD129997; Tue, 18 Oct 2016 01:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 053CaYkc0X51; Tue, 18 Oct 2016 01:43:44 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1D112999F; Tue, 18 Oct 2016 01:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2478; q=dns/txt; s=iport; t=1476780223; x=1477989823; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=nKWo3I5+iDTI1llWCnTfbiD5zC7x8QsVGAFjq4gPwUc=; b=Htf9p6IInqzGcs0lfAOPbbKEI2r6ycjfmNTwE+SokL2gxpB079w+ljeV KmHEWCJ9lJjh+w0VG7FSaInd1cruQf4dED/mw2CBNb53Hu0dqsDW06vXe 65jkLA+ZzGK922Zt2/urLQLvom5d5eWRke6LWqYVov6f9K8MzrKo8If+v Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAQAD4AVY/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAXQqUo00lwWPJIUUgggqhXgCgi0UAQIBAQEBAQEBXie?= =?us-ascii?q?EYgEBBCNWEAkCBAoKJwMCAkYRBgEMBgIBAYhODpgbnTGMawEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhj2BfQiCUIdLglsBBJoGhiiJXIlphgyJKYNShAAeNkQGCIR?= =?us-ascii?q?vPDQBiFUBAQE?= X-IronPort-AV: E=Sophos;i="5.31,361,1473120000"; d="scan'208,217";a="689026339" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2016 08:43:38 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9I8hZYZ031681; Tue, 18 Oct 2016 08:43:36 GMT To: Joan Cucchiara , =?UTF-8?B?66WY7KCV64+Z?= References: <5B4A6CBE3924BB41A3BEE462A8E0B75A29221AAD@SMTP2.etri.info> From: Benoit Claise Message-ID: <83337b69-7f27-2872-cb56-5caa964259e7@cisco.com> Date: Tue, 18 Oct 2016 10:43:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1FE6E8910A30D30F5CE41E3D" Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-linear-protection-mib@ietf.org" , "mpls-chairs@ietf.org" , "mib-doctors@ietf.org" Subject: Re: [mpls] =?utf-8?b?7ZqM7IugOiBNSUIgRHIuIHJldmlldyBvZiBkcmFmdC1pZXRm?= =?utf-8?q?-tp-linear-mib-09?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 08:43:45 -0000 This is a multi-part message in MIME format. --------------1FE6E8910A30D30F5CE41E3D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Many thanks Joan, I marked this task as completed at https://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history Regards, Benoit > > > Thank you for the quick turn-around and also for the thoroughness of > addressing this last round of comments. I believe the MIB review is > complete. > > Thanks again for all your time and effort during this process, > -Joan > > > On Wed, Oct 12, 2016 at 10:29 AM, 류정동 > wrote: > > Dear Joan, > --------------1FE6E8910A30D30F5CE41E3D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Many thanks Joan,
I marked this task as completed at https://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history

Regards, Benoit


Thank you for the quick turn-around and also for the thoroughness of addressing this last round of comments.   I believe the MIB review is complete.

Thanks again for all your time and effort during this process,
-Joan


On Wed, Oct 12, 2016 at 10:29 AM, 류정동 <ryoo@etri.re.kr> wrote:
Dear Joan,

--------------1FE6E8910A30D30F5CE41E3D-- From nobody Tue Oct 18 05:23:11 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488C4129A33; Tue, 18 Oct 2016 05:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZurw3EhLEYV; Tue, 18 Oct 2016 05:23:07 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F9C1204D9; Tue, 18 Oct 2016 05:23:07 -0700 (PDT) Received: from [192.168.1.8] (unknown [49.146.48.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A67ED18013E2; Tue, 18 Oct 2016 14:23:03 +0200 (CEST) To: Santosh Esale , "Kamran Raza (skraza)" , "mpls@ietf.org" , "mpls-chairs@ietf.org" References: From: Loa Andersson Message-ID: <2074b6dd-ce85-5528-ec3d-a423f92d831d@pi.nu> Date: Tue, 18 Oct 2016 20:22:59 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-mpls-ldp-mldp-yang@tools.ietf.org" Subject: Re: [mpls] Seeking WG and chairs feedback on LDP/mLDP Yang doc split [Re: A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 12:23:09 -0000 Folks, One useful piece of information is what the relative size of the to documents would be. If we come tp som sort of "equal size" documents I see no problem splitting the current document. I would advice adding some info to both documents on the relationship between the documents. /Loa On 2016-10-13 02:08, Santosh Esale wrote: > The present document which is around 115 pages long is only expected to > get bigger as we add more operational states in the upcoming revision. > Please > let us know your comments and suggestions. > > Thanks, > Santosh (on behalf of authors) > On 10/11/16, 12:07 PM, "mpls on behalf of Kamran Raza (skraza)" > on behalf of > skraza@cisco.com > wrote: > > Hello MPLS WG and WG chairs, > > [Refer to our email two weeks ago] > > Keeping in view some of the MPLS-RT review comments and the current > size of the join document (draft-ietf-mpls-ldp-mldp-yang), we, the > authors, are thinking of splitting the LDP/mLDP Yang model into two > separate documents one for LDP and other for mLDP - and would like > to get WG and chairs feedback on this. > > Please comment/advise accordingly. > Rgds. > > Kamran > (on behalf of authors) > > From: Syed Kamran Raza > > Date: Tuesday, September 27, 2016 at 1:14 PM > To: "mpls@ietf.org " >, "mpls-chairs@ietf.org > " > > Cc: "Rtg-yang-coord@ietf.org " > >, > "draft-ietf-mpls-ldp-mldp-yang@tools.ietf.org > " > > > Subject: [mpls] A quick update on LDP/mLDP Yang model > (draft-ietf-mpls-ldp-mldp-yang) > > Hello MPLS WG and WG chairs, > > This email is to give a quick update on the current work being done > on the IETF LDP/mLDP Yang draft (draft-ietf-mpls-ldp-mldp-yang-00). > > * Multi-vendor team is meeting twice a month to progress on the > model: > o Cisco, Juniper, Huawei, Ciena, Ericsson, Nokia > * The current focus of the team is to: > o address remaining MPLS-RT comments > o divide the model into base and extended features > o general cleanup > * We plan to submit a next revision before next IETF. > * We also want to get feedback from WG/chairs on whether it makes > sense to divide this large document (which is already > 115 > pages) into two separate documents one covering LDP Yang and > other mLDP yang. > o We will still keep mLDP model dependent on LDP. > o Please advise. > > Rgds. > > Kamran > (on behalf of authors) > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Oct 18 06:24:06 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CD2129A5E; Tue, 18 Oct 2016 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLWfd6gin9Hx; Tue, 18 Oct 2016 06:24:03 -0700 (PDT) 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 74C0B129A64; Tue, 18 Oct 2016 06:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3936; q=dns/txt; s=iport; t=1476797043; x=1478006643; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MNDXYaA8Vs8N27d+P86388LHDIOaL7Be9trG2BOyQHE=; b=mDvnH92DbnTrMB5lqy6IvprJjOIeHMF+mKVIXJGg5hDPHEwap/8Dk+p3 HP+kshnGv853x1FF61zL1Do9+fDzYuNUF3q2fl/kajiZiNsl+qoXZMTRC FTLm8cML3HNr3mbm8/qgToePuxoA6i/Ald+ooSpKF2++fFXMKFZotrLCH o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AQAkIQZY/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAR1XfAeNLZcGlDiCCB0LhXoCgX44FAECAQEBAQEBAV4?= =?us-ascii?q?nhGEBAQEEAQEBaAMEBw4CAgEIEQMBAgEjBAcbDAsUCQgCBAENBYhSDsJVAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAUFgiiIZYQZEQEcOIUKHQWaBgGQA4FuhGeJIIc?= =?us-ascii?q?QhWuDfwEeNlKDM4E6coY2gSCBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,362,1473120000"; d="scan'208";a="161195576" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2016 13:24:01 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u9IDO1SE017414 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Oct 2016 13:24:01 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 08:24:01 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Tue, 18 Oct 2016 08:24:01 -0500 From: "Kamran Raza (skraza)" To: Loa Andersson , Santosh Esale , "mpls@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [mpls] Seeking WG and chairs feedback on LDP/mLDP Yang doc split [Re: A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)] Thread-Index: AQHSJLOjnbPEjVWT7ECp0Z61c/7cYKCufySA///N+oA= Date: Tue, 18 Oct 2016 13:24:00 +0000 Message-ID: References: <2074b6dd-ce85-5528-ec3d-a423f92d831d@pi.nu> In-Reply-To: <2074b6dd-ce85-5528-ec3d-a423f92d831d@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.240.52] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0594648703603D48AFB0C62B2E0611A1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-ldp-mldp-yang@tools.ietf.org" Subject: Re: [mpls] Seeking WG and chairs feedback on LDP/mLDP Yang doc split [Re: A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 13:24:05 -0000 Hi Loa, 1. We expect LDP document to be little bigger than mLDP as it sets the base for both LDP and mLDP. 2. Yes, both documents will be made related where mLDP one being dependent on LDP document with proper x-ref. Rgds. =8B Kamran On 2016-10-18, 8:22 AM, "Loa Andersson" wrote: >Folks, > >One useful piece of information is what the relative size of the to >documents would be. If we come tp som sort of "equal size" documents >I see no problem splitting the current document. > >I would advice adding some info to both documents on the relationship >between the documents. > >/Loa > >On 2016-10-13 02:08, Santosh Esale wrote: >> The present document which is around 115 pages long is only expected to >> get bigger as we add more operational states in the upcoming revision. >> Please >> let us know your comments and suggestions. >> >> Thanks, >> Santosh (on behalf of authors) >> On 10/11/16, 12:07 PM, "mpls on behalf of Kamran Raza (skraza)" >> on behalf of >> skraza@cisco.com > wrote: >> >> Hello MPLS WG and WG chairs, >> >> [Refer to our email two weeks ago] >> >> Keeping in view some of the MPLS-RT review comments and the current >> size of the join document (draft-ietf-mpls-ldp-mldp-yang), we, the >> authors, are thinking of splitting the LDP/mLDP Yang model into two >> separate documents =AD one for LDP and other for mLDP - and would li= ke >> to get WG and chairs feedback on this. >> >> Please comment/advise accordingly. >> Rgds. >> =8B >> Kamran >> (on behalf of authors) >> >> From: Syed Kamran Raza > >> Date: Tuesday, September 27, 2016 at 1:14 PM >> To: "mpls@ietf.org " > >, "mpls-chairs@ietf.org >> " > > >> Cc: "Rtg-yang-coord@ietf.org " >> >, >> "draft-ietf-mpls-ldp-mldp-yang@tools.ietf.org >> " >> > > >> Subject: [mpls] A quick update on LDP/mLDP Yang model >> (draft-ietf-mpls-ldp-mldp-yang) >> >> Hello MPLS WG and WG chairs, >> >> This email is to give a quick update on the current work being done >> on the IETF LDP/mLDP Yang draft (draft-ietf-mpls-ldp-mldp-yang-00). >> >> * Multi-vendor team is meeting twice a month to progress on the >> model: >> o Cisco, Juniper, Huawei, Ciena, Ericsson, Nokia >> * The current focus of the team is to: >> o address remaining MPLS-RT comments >> o divide the model into =B3base=B2 and =B3extended=B2 features >> o general cleanup >> * We plan to submit a next revision before next IETF. >> * We also want to get feedback from WG/chairs on whether it makes >> sense to divide this large document (which is already > 115 >> pages) into two separate documents =AD one covering LDP Yang and >> other mLDP yang. >> o We will still keep mLDP model dependent on LDP. >> o Please advise. >> >> Rgds. >> =8B >> Kamran >> (on behalf of authors) >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Oct 18 12:07:51 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE25B1293DA; Tue, 18 Oct 2016 12:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMJUCbbqnNGn; Tue, 18 Oct 2016 12:07:48 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369D21293D6; Tue, 18 Oct 2016 12:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5654; q=dns/txt; s=iport; t=1476817667; x=1478027267; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5G/sMz7+VgblIvPRsKP8Mmjzm8oWX1IQWIw4ueac66Y=; b=YqVGTSM9TR3zrnON/xlPcasymTs8t6F8UxQftTqPetvMZj7i6qqVmqqM eMC0s6kwpfYYLl/KyN/ENeGXUhWiTZsuMLfbjmUarlOlfm83FFnwptsfa BpqHUmAYCB+YIXbhXLmg/tSICoWVbKZRawi6TGHTmAZayE+YKpBlxmevR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQDYcQZY/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAR1XfAcBjSyXBZQ4gggcC4V6AhqBaTgUAQIBAQEBAQE?= =?us-ascii?q?BYieEYQEBAQQBAQEgETcDBAcOAgIBCBEDAQIBAgIfBAMCAgIZDAsUAQgIAgQBD?= =?us-ascii?q?QWIUg62PIx3AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFgQKBJohlhBkRATMhAoJ?= =?us-ascii?q?Kgj4dBZoIAZAFgW6EaYkghxCFa4N/AR42VIM7gTpyhXmBIAF/AQEB?= X-IronPort-AV: E=Sophos;i="5.31,362,1473120000"; d="scan'208";a="336628807" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2016 19:07:46 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u9IJ7kEu008679 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Oct 2016 19:07:46 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 14:07:45 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Tue, 18 Oct 2016 14:07:45 -0500 From: "Kamran Raza (skraza)" To: Loa Andersson , Santosh Esale , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Tarek Saad (tsaad)" Thread-Topic: [mpls] Seeking WG and chairs feedback on LDP/mLDP Yang doc split [Re: A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)] Thread-Index: AQHSJLOjnbPEjVWT7ECp0Z61c/7cYKCufySA///N+oCAAGAIgA== Date: Tue, 18 Oct 2016 19:07:45 +0000 Message-ID: References: <2074b6dd-ce85-5528-ec3d-a423f92d831d@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.87] Content-Type: text/plain; charset="utf-8" Content-ID: <98F7AB3588694F409B6C3C0A907ABA71@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-ldp-mldp-yang@tools.ietf.org" Subject: Re: [mpls] Seeking WG and chairs feedback on LDP/mLDP Yang doc split [Re: A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 19:07:49 -0000 KyBUYXJlaw0KDQpPbiAyMDE2LTEwLTE4LCA5OjI0IEFNLCAiS2FtcmFuIFJhemEgKHNrcmF6YSki IDxza3JhemFAY2lzY28uY29tPiB3cm90ZToNCg0KPkhpIExvYSwNCj4NCj4xLiBXZSBleHBlY3Qg TERQIGRvY3VtZW50IHRvIGJlIGxpdHRsZSBiaWdnZXIgdGhhbiBtTERQIGFzIGl0IHNldHMgdGhl DQo+YmFzZSBmb3IgYm90aCBMRFAgYW5kIG1MRFAuDQo+Mi4gWWVzLCBib3RoIGRvY3VtZW50cyB3 aWxsIGJlIG1hZGUgcmVsYXRlZCB3aGVyZSBtTERQIG9uZSBiZWluZyBkZXBlbmRlbnQNCj5vbiBM RFAgZG9jdW1lbnQgd2l0aCBwcm9wZXIgeC1yZWYuDQo+DQo+Umdkcy4NCj7igLkNCj5LYW1yYW4N Cj4NCj5PbiAyMDE2LTEwLTE4LCA4OjIyIEFNLCAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4g d3JvdGU6DQo+DQo+PkZvbGtzLA0KPj4NCj4+T25lIHVzZWZ1bCBwaWVjZSBvZiBpbmZvcm1hdGlv biBpcyB3aGF0IHRoZSByZWxhdGl2ZSBzaXplIG9mIHRoZSB0bw0KPj5kb2N1bWVudHMgd291bGQg YmUuIElmIHdlIGNvbWUgdHAgc29tIHNvcnQgb2YgImVxdWFsIHNpemUiIGRvY3VtZW50cw0KPj5J IHNlZSBubyBwcm9ibGVtIHNwbGl0dGluZyB0aGUgY3VycmVudCBkb2N1bWVudC4NCj4+DQo+Pkkg d291bGQgYWR2aWNlIGFkZGluZyBzb21lIGluZm8gdG8gYm90aCBkb2N1bWVudHMgb24gdGhlIHJl bGF0aW9uc2hpcA0KPj5iZXR3ZWVuIHRoZSBkb2N1bWVudHMuDQo+Pg0KPj4vTG9hDQo+Pg0KPj5P biAyMDE2LTEwLTEzIDAyOjA4LCBTYW50b3NoIEVzYWxlIHdyb3RlOg0KPj4+IFRoZSBwcmVzZW50 IGRvY3VtZW50IHdoaWNoIGlzIGFyb3VuZCAxMTUgcGFnZXMgbG9uZyBpcyBvbmx5IGV4cGVjdGVk IHRvDQo+Pj4gZ2V0IGJpZ2dlciBhcyB3ZSBhZGQgbW9yZSBvcGVyYXRpb25hbCBzdGF0ZXMgaW4g dGhlIHVwY29taW5nIHJldmlzaW9uLg0KPj4+IFBsZWFzZQ0KPj4+IGxldCB1cyBrbm93IHlvdXIg Y29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLg0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+IFNhbnRvc2gg KG9uIGJlaGFsZiBvZiBhdXRob3JzKQ0KPj4+IE9uIDEwLzExLzE2LCAxMjowNyBQTSwgIm1wbHMg b24gYmVoYWxmIG9mIEthbXJhbiBSYXphIChza3JhemEpIg0KPj4+IDxtcGxzLWJvdW5jZXNAaWV0 Zi5vcmcgPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZg0KPj4+IHNr cmF6YUBjaXNjby5jb20gPG1haWx0bzpza3JhemFAY2lzY28uY29tPj4gd3JvdGU6DQo+Pj4NCj4+ PiAgICAgSGVsbG8gTVBMUyBXRyBhbmQgV0cgY2hhaXJzLA0KPj4+DQo+Pj4gICAgIFtSZWZlciB0 byBvdXIgZW1haWwgdHdvIHdlZWtzIGFnb10NCj4+Pg0KPj4+ICAgICBLZWVwaW5nIGluIHZpZXcg c29tZSBvZiB0aGUgTVBMUy1SVCByZXZpZXcgY29tbWVudHMgYW5kIHRoZSBjdXJyZW50DQo+Pj4g ICAgIHNpemUgb2YgdGhlIGpvaW4gZG9jdW1lbnQgKGRyYWZ0LWlldGYtbXBscy1sZHAtbWxkcC15 YW5nKSwgd2UsIHRoZQ0KPj4+ICAgICBhdXRob3JzLCBhcmUgdGhpbmtpbmcgb2Ygc3BsaXR0aW5n IHRoZSBMRFAvbUxEUCBZYW5nIG1vZGVsIGludG8gdHdvDQo+Pj4gICAgIHNlcGFyYXRlIGRvY3Vt ZW50cyDCrSBvbmUgZm9yIExEUCBhbmQgb3RoZXIgZm9yIG1MRFAgLSBhbmQgd291bGQNCj4+Pmxp a2UNCj4+PiAgICAgdG8gZ2V0IFdHIGFuZCBjaGFpcnMgZmVlZGJhY2sgb24gdGhpcy4NCj4+Pg0K Pj4+ICAgICBQbGVhc2UgY29tbWVudC9hZHZpc2UgYWNjb3JkaW5nbHkuDQo+Pj4gICAgIFJnZHMu DQo+Pj4gICAgIOKAuQ0KPj4+ICAgICBLYW1yYW4NCj4+PiAgICAgKG9uIGJlaGFsZiBvZiBhdXRo b3JzKQ0KPj4+DQo+Pj4gICAgIEZyb206IFN5ZWQgS2FtcmFuIFJhemEgPHNrcmF6YUBjaXNjby5j b20gPG1haWx0bzpza3JhemFAY2lzY28uY29tPj4NCj4+PiAgICAgRGF0ZTogVHVlc2RheSwgU2Vw dGVtYmVyIDI3LCAyMDE2IGF0IDE6MTQgUE0NCj4+PiAgICAgVG86ICJtcGxzQGlldGYub3JnIDxt YWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYub3JnDQo+Pj4gICAgIDxtYWlsdG86bXBs c0BpZXRmLm9yZz4+LCAibXBscy1jaGFpcnNAaWV0Zi5vcmcNCj4+PiAgICAgPG1haWx0bzptcGxz LWNoYWlyc0BpZXRmLm9yZz4iIDxtcGxzLWNoYWlyc0BpZXRmLm9yZw0KPj4+ICAgICA8bWFpbHRv Om1wbHMtY2hhaXJzQGlldGYub3JnPj4NCj4+PiAgICAgQ2M6ICJSdGcteWFuZy1jb29yZEBpZXRm Lm9yZyA8bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPiINCj4+PiAgICAgPFJ0Zy15YW5n LWNvb3JkQGlldGYub3JnIDxtYWlsdG86UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc+PiwNCj4+PiAg ICAgImRyYWZ0LWlldGYtbXBscy1sZHAtbWxkcC15YW5nQHRvb2xzLmlldGYub3JnDQo+Pj4gICAg IDxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWxkcC1tbGRwLXlhbmdAdG9vbHMuaWV0Zi5vcmc+Ig0K Pj4+ICAgICA8ZHJhZnQtaWV0Zi1tcGxzLWxkcC1tbGRwLXlhbmdAdG9vbHMuaWV0Zi5vcmcNCj4+ PiAgICAgPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtbGRwLW1sZHAteWFuZ0B0b29scy5pZXRmLm9y Zz4+DQo+Pj4gICAgIFN1YmplY3Q6IFttcGxzXSBBIHF1aWNrIHVwZGF0ZSBvbiBMRFAvbUxEUCBZ YW5nIG1vZGVsDQo+Pj4gICAgIChkcmFmdC1pZXRmLW1wbHMtbGRwLW1sZHAteWFuZykNCj4+Pg0K Pj4+ICAgICBIZWxsbyBNUExTIFdHIGFuZCBXRyBjaGFpcnMsDQo+Pj4NCj4+PiAgICAgVGhpcyBl bWFpbCBpcyB0byBnaXZlIGEgcXVpY2sgdXBkYXRlIG9uIHRoZSBjdXJyZW50IHdvcmsgYmVpbmcg ZG9uZQ0KPj4+ICAgICBvbiAgdGhlIElFVEYgTERQL21MRFAgWWFuZyBkcmFmdA0KPj4+KGRyYWZ0 LWlldGYtbXBscy1sZHAtbWxkcC15YW5nLTAwKS4NCj4+Pg0KPj4+ICAgICAgICogTXVsdGktdmVu ZG9yIHRlYW0gaXMgbWVldGluZyB0d2ljZSBhIG1vbnRoIHRvIHByb2dyZXNzIG9uIHRoZQ0KPj4+ ICAgICAgICAgbW9kZWw6DQo+Pj4gICAgICAgICAgIG8gQ2lzY28sIEp1bmlwZXIsIEh1YXdlaSwg Q2llbmEsIEVyaWNzc29uLCBOb2tpYQ0KPj4+ICAgICAgICogVGhlIGN1cnJlbnQgZm9jdXMgb2Yg dGhlIHRlYW0gaXMgdG86DQo+Pj4gICAgICAgICAgIG8gYWRkcmVzcyByZW1haW5pbmcgTVBMUy1S VCBjb21tZW50cw0KPj4+ICAgICAgICAgICBvIGRpdmlkZSB0aGUgbW9kZWwgaW50byDCs2Jhc2XC siBhbmQgwrNleHRlbmRlZMKyIGZlYXR1cmVzDQo+Pj4gICAgICAgICAgIG8gZ2VuZXJhbCBjbGVh bnVwDQo+Pj4gICAgICAgKiBXZSBwbGFuIHRvIHN1Ym1pdCBhIG5leHQgcmV2aXNpb24gYmVmb3Jl IG5leHQgSUVURi4NCj4+PiAgICAgICAqIFdlIGFsc28gd2FudCB0byBnZXQgZmVlZGJhY2sgZnJv bSBXRy9jaGFpcnMgb24gd2hldGhlciBpdCBtYWtlcw0KPj4+ICAgICAgICAgc2Vuc2UgdG8gZGl2 aWRlIHRoaXMgbGFyZ2UgZG9jdW1lbnQgKHdoaWNoIGlzIGFscmVhZHkgPiAxMTUNCj4+PiAgICAg ICAgIHBhZ2VzKSBpbnRvIHR3byBzZXBhcmF0ZSBkb2N1bWVudHMgwq0gb25lIGNvdmVyaW5nIExE UCBZYW5nIGFuZA0KPj4+ICAgICAgICAgb3RoZXIgbUxEUCB5YW5nLg0KPj4+ICAgICAgICAgICBv IFdlIHdpbGwgc3RpbGwga2VlcCBtTERQIG1vZGVsIGRlcGVuZGVudCBvbiBMRFAuDQo+Pj4gICAg ICAgICAgIG8gUGxlYXNlIGFkdmlzZS4NCj4+Pg0KPj4+ICAgICBSZ2RzLg0KPj4+ICAgICDigLkN Cj4+PiAgICAgS2FtcmFuDQo+Pj4gICAgIChvbiBiZWhhbGYgb2YgYXV0aG9ycykNCj4+Pg0KPj4+ DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+DQo+Pg0KPj4tLSANCj4+DQo+ Pg0KPj5Mb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWls MDEuaHVhd2VpLmNvbQ0KPj5TZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAg ICAgIGxvYUBwaS5udQ0KPj5IdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhv bmU6ICs0NiA3MzkgODEgMjEgNjQNCj4NCg0K From nobody Tue Oct 18 12:58:50 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9DB129842; Tue, 18 Oct 2016 12:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvfSirHna3fN; Tue, 18 Oct 2016 12:58:48 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F211296EE; Tue, 18 Oct 2016 12:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6778; q=dns/txt; s=iport; t=1476820727; x=1478030327; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+h0AtpNpqGT0rzn9UyNV/OGUcER2iZ5s3H8CUtpz3PE=; b=c7U3QcgeWnpFrjEoUf3gr1twcI3zic7FAeh5XVqLLciD9KDiQkV2DobS VcfcNE/QpF8e6S87nCsLgITbOBBhwUt5JSHZDc/Ldbmt1ant7fXYID4Qh o3VSj6OK0O6EhB0z3yOkRiYNyeMyCWG5pUeMyq9LbU6S9pBqyoevDC/kr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQDtfQZY/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAR1XfAcBjSyXBZQ4gggcC4V6AhqBaTgUAQIBAQEBAQE?= =?us-ascii?q?BYieEYQEBAQQBAQEgETcDBAcOAgIBCBEDAQIBAgIfBAMCAgIZDAsUAQgIAgQBD?= =?us-ascii?q?QWIUg62Tox4AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFgQKBJoQQgX0IglCEGRE?= =?us-ascii?q?BHBchAoJKLIISHQWaCAGQBYFuhGmJIIcQhWuDfwEeNlSDO4E6coV5gSABfwEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.31,511,1473120000"; d="scan'208";a="161190820" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2016 19:58:46 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u9IJwknt007064 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Oct 2016 19:58:46 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 15:58:45 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Tue, 18 Oct 2016 15:58:45 -0400 From: "Tarek Saad (tsaad)" To: "Kamran Raza (skraza)" , Loa Andersson , Santosh Esale , "mpls@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [mpls] Seeking WG and chairs feedback on LDP/mLDP Yang doc split [Re: A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)] Thread-Index: AQHSJLOkYYt5hDtEyUyUMBKFElbGk6CubmCAgAARDACAAGALgP//yzEA Date: Tue, 18 Oct 2016 19:58:45 +0000 Message-ID: <48713210-D350-4F8D-8355-9B216A74EEE6@cisco.com> References: <2074b6dd-ce85-5528-ec3d-a423f92d831d@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.94] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-ldp-mldp-yang@tools.ietf.org" Subject: Re: [mpls] Seeking WG and chairs feedback on LDP/mLDP Yang doc split [Re: A quick update on LDP/mLDP Yang model (draft-ietf-mpls-ldp-mldp-yang)] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 19:58:49 -0000 SGkgS2FtcmFuLA0KDQpUaGFua3MgZm9yIGFkZGluZy4gSSBhbHNvIGZhdm9yIHRoZSBzcGxpdCB0 byB0d28gZG9jdW1lbnRzIHRoYXQgYWxsb3dzIHRoZSBiYXNlIExEUCBkb2N1bWVudCB0byBwb3Nz aWJseSBtYXR1cmUvYWR2YW5jZSBmYXN0ZXIuDQpBbG9uZyB0aGUgc2FtZSBsaW5lcywgd2lsbCB5 b3UgYmUgY29uc2lkZXJpbmcgbUxEUCBhcyBhIHN0YW5kYWxvbmUgWUFORyBtb2R1bGUgKGUuZy4g YW4gYXVnbWVudGF0aW9uIG9mIGJhc2UgTERQKT8NCg0KUmVnYXJkcywNClRhcmVrDQoNCk9uIDIw MTYtMTAtMTgsIDM6MDcgUE0sICJLYW1yYW4gUmF6YSAoc2tyYXphKSIgPHNrcmF6YUBjaXNjby5j b20+IHdyb3RlOg0KDQogICAgKyBUYXJlaw0KICAgIA0KICAgIE9uIDIwMTYtMTAtMTgsIDk6MjQg QU0sICJLYW1yYW4gUmF6YSAoc2tyYXphKSIgPHNrcmF6YUBjaXNjby5jb20+IHdyb3RlOg0KICAg IA0KICAgID5IaSBMb2EsDQogICAgPg0KICAgID4xLiBXZSBleHBlY3QgTERQIGRvY3VtZW50IHRv IGJlIGxpdHRsZSBiaWdnZXIgdGhhbiBtTERQIGFzIGl0IHNldHMgdGhlDQogICAgPmJhc2UgZm9y IGJvdGggTERQIGFuZCBtTERQLg0KICAgID4yLiBZZXMsIGJvdGggZG9jdW1lbnRzIHdpbGwgYmUg bWFkZSByZWxhdGVkIHdoZXJlIG1MRFAgb25lIGJlaW5nIGRlcGVuZGVudA0KICAgID5vbiBMRFAg ZG9jdW1lbnQgd2l0aCBwcm9wZXIgeC1yZWYuDQogICAgPg0KICAgID5SZ2RzLg0KICAgID7igLkN CiAgICA+S2FtcmFuDQogICAgPg0KICAgID5PbiAyMDE2LTEwLTE4LCA4OjIyIEFNLCAiTG9hIEFu ZGVyc3NvbiIgPGxvYUBwaS5udT4gd3JvdGU6DQogICAgPg0KICAgID4+Rm9sa3MsDQogICAgPj4N CiAgICA+Pk9uZSB1c2VmdWwgcGllY2Ugb2YgaW5mb3JtYXRpb24gaXMgd2hhdCB0aGUgcmVsYXRp dmUgc2l6ZSBvZiB0aGUgdG8NCiAgICA+PmRvY3VtZW50cyB3b3VsZCBiZS4gSWYgd2UgY29tZSB0 cCBzb20gc29ydCBvZiAiZXF1YWwgc2l6ZSIgZG9jdW1lbnRzDQogICAgPj5JIHNlZSBubyBwcm9i bGVtIHNwbGl0dGluZyB0aGUgY3VycmVudCBkb2N1bWVudC4NCiAgICA+Pg0KICAgID4+SSB3b3Vs ZCBhZHZpY2UgYWRkaW5nIHNvbWUgaW5mbyB0byBib3RoIGRvY3VtZW50cyBvbiB0aGUgcmVsYXRp b25zaGlwDQogICAgPj5iZXR3ZWVuIHRoZSBkb2N1bWVudHMuDQogICAgPj4NCiAgICA+Pi9Mb2EN CiAgICA+Pg0KICAgID4+T24gMjAxNi0xMC0xMyAwMjowOCwgU2FudG9zaCBFc2FsZSB3cm90ZToN CiAgICA+Pj4gVGhlIHByZXNlbnQgZG9jdW1lbnQgd2hpY2ggaXMgYXJvdW5kIDExNSBwYWdlcyBs b25nIGlzIG9ubHkgZXhwZWN0ZWQgdG8NCiAgICA+Pj4gZ2V0IGJpZ2dlciBhcyB3ZSBhZGQgbW9y ZSBvcGVyYXRpb25hbCBzdGF0ZXMgaW4gdGhlIHVwY29taW5nIHJldmlzaW9uLg0KICAgID4+PiBQ bGVhc2UNCiAgICA+Pj4gbGV0IHVzIGtub3cgeW91ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMu DQogICAgPj4+DQogICAgPj4+IFRoYW5rcywNCiAgICA+Pj4gU2FudG9zaCAob24gYmVoYWxmIG9m IGF1dGhvcnMpDQogICAgPj4+IE9uIDEwLzExLzE2LCAxMjowNyBQTSwgIm1wbHMgb24gYmVoYWxm IG9mIEthbXJhbiBSYXphIChza3JhemEpIg0KICAgID4+PiA8bXBscy1ib3VuY2VzQGlldGYub3Jn IDxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YNCiAgICA+Pj4gc2ty YXphQGNpc2NvLmNvbSA8bWFpbHRvOnNrcmF6YUBjaXNjby5jb20+PiB3cm90ZToNCiAgICA+Pj4N CiAgICA+Pj4gICAgIEhlbGxvIE1QTFMgV0cgYW5kIFdHIGNoYWlycywNCiAgICA+Pj4NCiAgICA+ Pj4gICAgIFtSZWZlciB0byBvdXIgZW1haWwgdHdvIHdlZWtzIGFnb10NCiAgICA+Pj4NCiAgICA+ Pj4gICAgIEtlZXBpbmcgaW4gdmlldyBzb21lIG9mIHRoZSBNUExTLVJUIHJldmlldyBjb21tZW50 cyBhbmQgdGhlIGN1cnJlbnQNCiAgICA+Pj4gICAgIHNpemUgb2YgdGhlIGpvaW4gZG9jdW1lbnQg KGRyYWZ0LWlldGYtbXBscy1sZHAtbWxkcC15YW5nKSwgd2UsIHRoZQ0KICAgID4+PiAgICAgYXV0 aG9ycywgYXJlIHRoaW5raW5nIG9mIHNwbGl0dGluZyB0aGUgTERQL21MRFAgWWFuZyBtb2RlbCBp bnRvIHR3bw0KICAgID4+PiAgICAgc2VwYXJhdGUgZG9jdW1lbnRzIMKtIG9uZSBmb3IgTERQIGFu ZCBvdGhlciBmb3IgbUxEUCAtIGFuZCB3b3VsZA0KICAgID4+Pmxpa2UNCiAgICA+Pj4gICAgIHRv IGdldCBXRyBhbmQgY2hhaXJzIGZlZWRiYWNrIG9uIHRoaXMuDQogICAgPj4+DQogICAgPj4+ICAg ICBQbGVhc2UgY29tbWVudC9hZHZpc2UgYWNjb3JkaW5nbHkuDQogICAgPj4+ICAgICBSZ2RzLg0K ICAgID4+PiAgICAg4oC5DQogICAgPj4+ICAgICBLYW1yYW4NCiAgICA+Pj4gICAgIChvbiBiZWhh bGYgb2YgYXV0aG9ycykNCiAgICA+Pj4NCiAgICA+Pj4gICAgIEZyb206IFN5ZWQgS2FtcmFuIFJh emEgPHNrcmF6YUBjaXNjby5jb20gPG1haWx0bzpza3JhemFAY2lzY28uY29tPj4NCiAgICA+Pj4g ICAgIERhdGU6IFR1ZXNkYXksIFNlcHRlbWJlciAyNywgMjAxNiBhdCAxOjE0IFBNDQogICAgPj4+ ICAgICBUbzogIm1wbHNAaWV0Zi5vcmcgPG1haWx0bzptcGxzQGlldGYub3JnPiIgPG1wbHNAaWV0 Zi5vcmcNCiAgICA+Pj4gICAgIDxtYWlsdG86bXBsc0BpZXRmLm9yZz4+LCAibXBscy1jaGFpcnNA aWV0Zi5vcmcNCiAgICA+Pj4gICAgIDxtYWlsdG86bXBscy1jaGFpcnNAaWV0Zi5vcmc+IiA8bXBs cy1jaGFpcnNAaWV0Zi5vcmcNCiAgICA+Pj4gICAgIDxtYWlsdG86bXBscy1jaGFpcnNAaWV0Zi5v cmc+Pg0KICAgID4+PiAgICAgQ2M6ICJSdGcteWFuZy1jb29yZEBpZXRmLm9yZyA8bWFpbHRvOlJ0 Zy15YW5nLWNvb3JkQGlldGYub3JnPiINCiAgICA+Pj4gICAgIDxSdGcteWFuZy1jb29yZEBpZXRm Lm9yZyA8bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPj4sDQogICAgPj4+ICAgICAiZHJh ZnQtaWV0Zi1tcGxzLWxkcC1tbGRwLXlhbmdAdG9vbHMuaWV0Zi5vcmcNCiAgICA+Pj4gICAgIDxt YWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWxkcC1tbGRwLXlhbmdAdG9vbHMuaWV0Zi5vcmc+Ig0KICAg ID4+PiAgICAgPGRyYWZ0LWlldGYtbXBscy1sZHAtbWxkcC15YW5nQHRvb2xzLmlldGYub3JnDQog ICAgPj4+ICAgICA8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy1sZHAtbWxkcC15YW5nQHRvb2xzLmll dGYub3JnPj4NCiAgICA+Pj4gICAgIFN1YmplY3Q6IFttcGxzXSBBIHF1aWNrIHVwZGF0ZSBvbiBM RFAvbUxEUCBZYW5nIG1vZGVsDQogICAgPj4+ICAgICAoZHJhZnQtaWV0Zi1tcGxzLWxkcC1tbGRw LXlhbmcpDQogICAgPj4+DQogICAgPj4+ICAgICBIZWxsbyBNUExTIFdHIGFuZCBXRyBjaGFpcnMs DQogICAgPj4+DQogICAgPj4+ICAgICBUaGlzIGVtYWlsIGlzIHRvIGdpdmUgYSBxdWljayB1cGRh dGUgb24gdGhlIGN1cnJlbnQgd29yayBiZWluZyBkb25lDQogICAgPj4+ICAgICBvbiAgdGhlIElF VEYgTERQL21MRFAgWWFuZyBkcmFmdA0KICAgID4+PihkcmFmdC1pZXRmLW1wbHMtbGRwLW1sZHAt eWFuZy0wMCkuDQogICAgPj4+DQogICAgPj4+ICAgICAgICogTXVsdGktdmVuZG9yIHRlYW0gaXMg bWVldGluZyB0d2ljZSBhIG1vbnRoIHRvIHByb2dyZXNzIG9uIHRoZQ0KICAgID4+PiAgICAgICAg IG1vZGVsOg0KICAgID4+PiAgICAgICAgICAgbyBDaXNjbywgSnVuaXBlciwgSHVhd2VpLCBDaWVu YSwgRXJpY3Nzb24sIE5va2lhDQogICAgPj4+ICAgICAgICogVGhlIGN1cnJlbnQgZm9jdXMgb2Yg dGhlIHRlYW0gaXMgdG86DQogICAgPj4+ICAgICAgICAgICBvIGFkZHJlc3MgcmVtYWluaW5nIE1Q TFMtUlQgY29tbWVudHMNCiAgICA+Pj4gICAgICAgICAgIG8gZGl2aWRlIHRoZSBtb2RlbCBpbnRv IMKzYmFzZcKyIGFuZCDCs2V4dGVuZGVkwrIgZmVhdHVyZXMNCiAgICA+Pj4gICAgICAgICAgIG8g Z2VuZXJhbCBjbGVhbnVwDQogICAgPj4+ICAgICAgICogV2UgcGxhbiB0byBzdWJtaXQgYSBuZXh0 IHJldmlzaW9uIGJlZm9yZSBuZXh0IElFVEYuDQogICAgPj4+ICAgICAgICogV2UgYWxzbyB3YW50 IHRvIGdldCBmZWVkYmFjayBmcm9tIFdHL2NoYWlycyBvbiB3aGV0aGVyIGl0IG1ha2VzDQogICAg Pj4+ICAgICAgICAgc2Vuc2UgdG8gZGl2aWRlIHRoaXMgbGFyZ2UgZG9jdW1lbnQgKHdoaWNoIGlz IGFscmVhZHkgPiAxMTUNCiAgICA+Pj4gICAgICAgICBwYWdlcykgaW50byB0d28gc2VwYXJhdGUg ZG9jdW1lbnRzIMKtIG9uZSBjb3ZlcmluZyBMRFAgWWFuZyBhbmQNCiAgICA+Pj4gICAgICAgICBv dGhlciBtTERQIHlhbmcuDQogICAgPj4+ICAgICAgICAgICBvIFdlIHdpbGwgc3RpbGwga2VlcCBt TERQIG1vZGVsIGRlcGVuZGVudCBvbiBMRFAuDQogICAgPj4+ICAgICAgICAgICBvIFBsZWFzZSBh ZHZpc2UuDQogICAgPj4+DQogICAgPj4+ICAgICBSZ2RzLg0KICAgID4+PiAgICAg4oC5DQogICAg Pj4+ICAgICBLYW1yYW4NCiAgICA+Pj4gICAgIChvbiBiZWhhbGYgb2YgYXV0aG9ycykNCiAgICA+ Pj4NCiAgICA+Pj4NCiAgICA+Pj4NCiAgICA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICA+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCiAgICA+Pj4g bXBsc0BpZXRmLm9yZw0KICAgID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCiAgICA+Pj4NCiAgICA+Pg0KICAgID4+LS0gDQogICAgPj4NCiAgICA+Pg0KICAg ID4+TG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAx Lmh1YXdlaS5jb20NCiAgICA+PlNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAg ICAgICAgbG9hQHBpLm51DQogICAgPj5IdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAg ICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCiAgICA+DQogICAgDQogICAgDQoNCg== From nobody Wed Oct 19 00:44:28 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F65C1293E1; Wed, 19 Oct 2016 00:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.331 X-Spam-Level: X-Spam-Status: No, score=-102.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvyvktNHJzBT; Wed, 19 Oct 2016 00:44:19 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B83129533; Wed, 19 Oct 2016 00:44:18 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Oct 2016 16:44:17 +0900 Received: from SMTP2.etri.info ([169.254.2.208]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Wed, 19 Oct 2016 16:44:14 +0900 From: "Ryoo, Jeong-dong " To: Joan Cucchiara Thread-Topic: MIB Dr. review of draft-ietf-tp-linear-mib-09 Thread-Index: AQHSIP5e0riTaryqu0uz9sjSdO93caCk5brDgAgacICAAnOnfw== Date: Wed, 19 Oct 2016 07:44:14 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A29223EC5@SMTP2.etri.info> References: <5B4A6CBE3924BB41A3BEE462A8E0B75A29221AAD@SMTP2.etri.info>, In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZyA= x-originating-ip: [129.254.28.42] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A29223EC5SMTP2etriinfo_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-linear-protection-mib@ietf.org" , "mib-doctors@ietf.org" , "mpls-chairs@ietf.org" , Benoit Claise Subject: Re: [mpls] MIB Dr. review of draft-ietf-tp-linear-mib-09 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 07:44:22 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A29223EC5SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9hbiwNCg0KDQpUaGFuayB5b3Ugc28gbXVjaCBmb3IgeW91ciB3b3JrIG9uIHRoaXMuDQoNClRo ZSBkb2N1bWVudCBoYXMgYmVlbiBncmVhdGx5IGltcHJvdmVkIHRocm91Z2ggeW91ciByZXZpZXcg YW5kIGNvbW1lbnRzIGluIHRoZSBwcmV2aW91cyByZXZpc2lvbnMuDQoNCg0KQmVzdCByZWdhcmRz LA0KDQoNCkplb25nLWRvbmcNCg0KDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQrrs7Trgrgg7IKs656MIDogIkpvYW4gQ3VjY2hpYXJhIiA8amN1Y2NoaWFy YS5pZXRmQGdtYWlsLmNvbT4NCuuztOuCuCDrgqDsp5wgOiAyMDE2LTEwLTE4IDEyOjA1OjUyICgg KzA5OjAwICkNCuuwm+uKlCDsgqzrnowgOiDrpZjsoJXrj5kgPHJ5b29AZXRyaS5yZS5rcj4NCuyw uOyhsCA6IExvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4sIG1wbHNAaWV0Zi5vcmcgPG1wbHNAaWV0 Zi5vcmc+LCBkcmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24tbWliQGlldGYub3Jn IDxkcmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24tbWliQGlldGYub3JnPiwgbXBs cy1jaGFpcnNAaWV0Zi5vcmcgPG1wbHMtY2hhaXJzQGlldGYub3JnPiwgbWliLWRvY3RvcnNAaWV0 Zi5vcmcgPG1pYi1kb2N0b3JzQGlldGYub3JnPiwgQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNj by5jb20+DQrsoJzrqqkgOiBSZTog7ZqM7IugOiBNSUIgRHIuIHJldmlldyBvZiBkcmFmdC1pZXRm LXRwLWxpbmVhci1taWItMDkNCg0KDQoNCkplb25nLWRvbmcsDQoNCg0KDQoNCg0KVGhhbmsgeW91 IGZvciB0aGUgcXVpY2sgdHVybi1hcm91bmQgYW5kIGFsc28gZm9yIHRoZSB0aG9yb3VnaG5lc3Mg b2YgYWRkcmVzc2luZyB0aGlzIGxhc3Qgcm91bmQgb2YgY29tbWVudHMuICAgSSBiZWxpZXZlIHRo ZSBNSUIgcmV2aWV3IGlzIGNvbXBsZXRlLg0KDQoNCg0KDQoNClRoYW5rcyBhZ2FpbiBmb3IgYWxs IHlvdXIgdGltZSBhbmQgZWZmb3J0IGR1cmluZyB0aGlzIHByb2Nlc3MsDQoNCg0KDQotSm9hbg0K DQoNCg0KDQoNCg0KDQpPbiBXZWQsIE9jdCAxMiwgMjAxNiBhdCAxMDoyOSBBTSwg66WY7KCV64+Z IDxyeW9vQGV0cmkucmUua3I8bWFpbHRvOnJ5b29AZXRyaS5yZS5rcj4+IHdyb3RlOg0KDQoNCg0K RGVhciBKb2FuLA0KDQoNCg0KDQoNClRoYW5rIHlvdSBzbyBtdWNoIGZvciB5b3VyIHJldmlldyBh bmQgY29tbWVudHMuDQoNCg0KDQpBbGwgeW91ciBjb21tZW50cyBoYWQgYmVlbiBpbmNvcnBvcmF0 ZWQgaW50byB0aGUgcmV2aXNpb24gcG9zdGVkIGEgZmV3IG1pbnV0ZXMgYWdvIGFzIGZvbGxvd3Mu DQoNCg0KDQoNCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJv dGVjdGlvbi1taWINCg0KDQoNClJldmlzaW9uOiAgICAgICAxMA0KDQoNCg0KVGl0bGU6ICAgICAg ICAgIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgTGluZWFyIFByb3RlY3Rpb24gTUlCDQoNCg0KDQpE b2N1bWVudCBkYXRlOiAgMjAxNi0xMC0xMg0KDQoNCg0KR3JvdXA6ICAgICAgICAgIG1wbHMNCg0K DQoNClBhZ2VzOiAgICAgICAgICA0NQ0KDQoNCg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3Rl Y3Rpb24tbWliLTEwLnR4dA0KDQoNCg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJvdGVjdGlvbi1taWIv DQoNCg0KDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtbXBscy10cC1saW5lYXItcHJvdGVjdGlvbi1taWItMTANCg0KDQoNCkRpZmY6ICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tcGxzLXRw LWxpbmVhci1wcm90ZWN0aW9uLW1pYi0xMA0KDQoNCg0KDQoNCldvdWxkIHlvdSBwbGVhc2UgbGV0 IHVzIGtub3cgaWYgeW91IGhhdmUgYW55IGZ1cnRoZXIgY29tbWVudHMgb24gdGhpcyBkb2N1bWVu dCBhdCB5b3VyIGVhcmxpZXN0IGNvbnZlbmllbmNlPw0KDQoNCg0KDQoNCkJlc3QgcmVhZ3JkcywN Cg0KDQoNCg0KDQpKZW9uZy1kb25nDQoNCg0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQrrs7Trgrgg7IKs656MOiBKb2FuIEN1Y2No aWFyYSBbamN1Y2NoaWFyYS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86amN1Y2NoaWFyYS5pZXRmQGdt YWlsLmNvbT5dDQoNCg0KDQrrs7Trgrgg64Kg7KecOiAyMDE264WEIDEw7JuUIDjsnbwg7Yag7JqU 7J28IOyYpOyghCA5OjUzDQoNCg0KDQrrsJvripQg7IKs656MOiBMb2EgQW5kZXJzc29uOyBtcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1tcGxzLXRwLWxpbmVh ci1wcm90ZWN0aW9uLW1pYkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXRwLWxpbmVh ci1wcm90ZWN0aW9uLW1pYkBpZXRmLm9yZz47IG1wbHMtY2hhaXJzQGlldGYub3JnPG1haWx0bzpt cGxzLWNoYWlyc0BpZXRmLm9yZz47IG1pYi1kb2N0b3JzQGlldGYub3JnPG1haWx0bzptaWItZG9j dG9yc0BpZXRmLm9yZz4NCg0KDQoNCuywuOyhsDog66WY7KCV64+ZOyBCZW5vaXQgQ2xhaXNlDQoN Cg0KDQrsoJzrqqk6IE1JQiBEci4gcmV2aWV3IG9mIGRyYWZ0LWlldGYtdHAtbGluZWFyLW1pYi0w OQ0KDQoNCg0KDQoNCkF1dGhvcnMsDQoNCg0KDQoNCg0KVGhhbmsgeW91IGZvciBhZGRyZXNzaW5n IHRoZSBjb21tZW50cyBzbyB0aG9yb3VnaGx5LCBhbmQgZXNwZWNpYWxseSBmb3INCg0KDQoNCmNs YXJpZnlpbmcgdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiA3LiAgICBNdWNoIGFwcHJlY2lhdGVkLg0K DQoNCg0KDQoNClRoZSBNSUIgY29tcGlsZXMgd2l0aCBzbWlsaW50IGFuZCBzbWljbmdQUk8uICAg Q29tbWVudHMgYXJlIGJlbG93Lg0KDQoNCg0KDQoNClRoYW5rIHlvdSwNCg0KDQoNCi1Kb2FuDQoN Cg0KDQoNCg0KQ29tbWVudHM6DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQoNCg0KMSkg U2VjdGlvbiA2LjEgUmVsYXRpb25zaGlwIHRvIHRoZSBNUExTIE9BTSBNYWludGVuYW5jZSBJZGVu dGlmaWVycyBNSUIgTW9kdWxlDQoNCg0KDQoNCg0KICAgIlRoZSBtcGxzTHBzTWVDb25maWdUYWJs ZSBlbnRyeSBpcyBleHRlbmRlZCBieSB0aGUgZW50cnkgaW4gdGhlDQoNCg0KDQogICBtcGxzT2Ft SWRNZVRhYmxlIGRlZmluZWQgaW4gW1JGQzc2OTddLiINCg0KDQoNCg0KDQpUaGUgYWJvdmUgc3Rh dGVtZW50IGlzIGJhY2t3YXJkcy4uLi50aGluayB0aGUgaW50ZW50aW9uIGlzIHRvIHNheSBzb21l dGhpbmcgbGlrZToNCg0KDQoNCkVudHJpZXMgaW4gdGhlIG1wbHNPYW1JZE1lVGFibGUgW1JGQzc2 OTddIGFyZSBleHRlbmRlZCBieSBlbnRyaWVzIGluIHRoZSBtcGxzTHNwTWVDb25maWdUYWJsZS4N Cg0KDQoNCg0KDQoyKSBsYXRlciBpbiB0aGlzIHNhbWUgc2VjdGlvbiwgc2VjdGlvbiA2LjENCg0K DQoNCg0KDQogICAiQW4gZW50cnkgb2YgdGhpcyB0YWJsZSBpcyByZWxhdGVkIHRvIGEgc2luZ2xl IGVudHJ5IGluIG1wbHNPYW1JZE1lVGFibGUuIg0KDQoNCg0KDQoNClRoZSBhYm92ZSBpcyBjb25m dXNpbmcgYmVjYXVzZSB5b3UndmUgYWxyZWFkeSBkaXNjdXNzIHRoZSBzcGFyc2UgYXVnbWVudHMg cmVsYXRpb25zaGlwLiAgUGxlYXNlIHJlbW92ZQ0KDQoNCg0KdGhlIGFib3ZlIHNlbnRlbmNlLg0K DQoNCg0KDQoNCg0KDQpNSUIgTW9kdWxlDQoNCg0KDQotLS0tLS0tLS0tLS0NCg0KDQoNCjMpICBt cGxzTHBzQ29uZmlnSW5kZXhOZXh0ICAtICAgcGxlYXNlIHJlbmFtZSB0byBtcGxzTHBzQ29uZmln RG9tYWluSW5kZXhOZXh0Lg0KDQoNCg0KU2luY2UgdGhpcyBzY2FsYXIgaXMgb25seSB1c2VkIGZv ciB0aGUgbXBsc0xwc0NvbmZpZ0RvbWFpbkluZGV4IGluZGV4J3MgdmFsdWVzLCB0aGUgbmFtZSBz aG91bGQgcmVmbGVjdCB0aGF0Lg0KDQoNCg0KTk9URTogIHRoaXMgbmFtZSBjaGFuZ2Ugc2hvdWxk IGJlIHByb3BhZ2F0ZWQgZWxzZXdoZXJlIGluIHRoZSBkcmFmdC4gIFBsZWFzZSBkbyBhIHNlYXJj aCBhbmQgcmVwbGFjZS4NCg0KDQoNCg0KDQo0KSBtcGxzTHBzQ29uZmlnRG9tYWluSW5kZXggIChl ZGl0b3JpYWwpDQoNCg0KDQogICJNYW5hZ2VycyBzaG91bGQuLi4iDQoNCg0KDQoNCg0Kcy9NYW5h Z2Vycy9PcGVyYXRvcnMvDQoNCg0KDQoNCg0KDQoNCjUpIG1wbHNMcHNDb25maWdDb21tYW5kDQoN Cg0KDQpXaHkgaXMgdGhlcmUgTk8gREVWQUw/ICAgV291bGRuJ3QgIm5vQ21kIiBiZSBhbiBhcHBy b3ByaWF0ZSBERUZWQUw/DQoNCg0KDQoNCg0KDQoNCjYpIG1wbHNMcHNDb25maWdSb3dTdGF0dXMg REVTQ1JJUFRJT04gY2xhdXNlDQoNCg0KDQoNCg0KUm93U3RhdHVzIG9iamVjdHMgcmVmbGVjdCB0 aGUgc3RhdHVzIG9mIHRoZSBSb3csIG5vdCBhIGRldGVybWluYXRpb24gb2Ygd2hldGhlciBvciBu b3QgdmFsdWVzDQoNCg0KDQphcmUgImFwcHJvcHJpYXRlIi4gIFBsZWFzZSByZW1vdmUgdGhlIGxh c3Qgc2VudGVuY2Ugb2YgdGhpcyBERVNDUklQVElPTjoNCg0KDQoNCg0KDQogICAgICAgICAiLi4u QW4gZW50cnkgbWF5IG5vdCBleGlzdCBpbiB0aGUgYWN0aXZlIHN0YXRlIHVubGVzcyBhbGwNCg0K DQoNCiAgICAgICAgICBvYmplY3RzIGluIHRoZSBlbnRyeSBoYXZlIGFuIGFwcHJvcHJpYXRlIHZh bHVlLiINCg0KDQoNCg0KDQoNCg0KNykgIG1wbHNMcHNDb25maWdEb21haW5JbmRleCBhbmQgbXBs c0xwc01lQ29uZmlnRG9tYWluDQoNCg0KDQoNCg0KU2luY2UgTUlCcyBvZnRlbiBnZXQgc3RyaXBw ZWQgb3V0IG9mIFJGQ3MsIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgbXBsc0xwc0NvbmZp Z0RvbWFpbkluZGV4IGFuZA0KDQoNCg0KdGhlIG1wbHNMcHNNZUNvbmZpZ0RvbWFpbiBuZWVkcyB0 byBiZSBpbmNsdWRlZCBpbiB0aGUgTUlCIE1vZHVsZSBpdHNlbGYuDQoNCg0KDQoNCg0KQm90aCBE RVNDUklQVElPTiBjbGF1c2VzIG5lZWQgdG8gYmUgdXBkYXRlZCB0byBkZXNjcmliZSB0aGUgcmVs YXRpb25zaGlwIGJldHdlZW4gdGhlc2Ugb2JqZWN0cy4gICBWZXJiYWdlIHN1Y2ggYXMgIldoZW4g dGhlDQoNCg0KDQp2YWx1ZSBvZiBtcGxzTHBzQ29uZmlnRG9tYWluSW5kZXggaXMgdGhlIHNhbWUg YXMgdGhlIHZhbHVlIG9mIG1wbHNMcHNNZUNvbmZpZ0RvbWFpbiwgdGhhdCBtZWFucy4uLiIgYW5k IHRoZW4gZXhwbGFpbiB3aGF0DQoNCg0KDQp0aGlzIG1lYW5zLg0KDQoNCg0KDQoNCjgpICBtcGxz THBzTWVDb25maWdEb21haW4gREVTQ1JJUFRJT04gKGVkaXRvcmlhbCkNCg0KDQoNCiAgICAgICAg ICJUaGlzIG9iamVjdCBob2xkcyB0aGUgdmFsdWUgb2YgcHJvdGVjdGlvbiBkb21haW4gaW5kZXgg d2hlcmVpbg0KDQoNCg0KICAgICAgICAgIHRoaXMgTUUgaW5jbHVkZWQgaW4uDQoNCg0KDQoNCg0K cy9pbmNsdWRlZCBpbi9pcyBpbmNsdWRlZC8NCg0KDQoNCg0KDQotLS0NCg0KDQoNCg0KDQoNCg0K DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A29223EC5SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij5Kb2Fu LCA8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxi cj4NCjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+ VGhhbmsgeW91IHNvIG11Y2ggZm9yIHlvdXImbmJzcDt3b3JrIG9uIHRoaXMuPC9wPg0KPHAgc3R5 bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij5UaGUgZG9jdW1lbnQgaGFz IGJlZW4gZ3JlYXRseSBpbXByb3ZlZCZuYnNwO3Rocm91Z2ggeW91ciByZXZpZXcgYW5kIGNvbW1l bnRzJm5ic3A7aW4mbmJzcDt0aGUgcHJldmlvdXMmbmJzcDtyZXZpc2lvbnMuPC9wPg0KPHAgc3R5 bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48YnI+DQo8L3A+DQo8cCBz dHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPkJlc3QgcmVnYXJkcyw8 L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxicj4N CjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+SmVv bmctZG9uZzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBw eCI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDog MHB4Ij48YnI+DQo8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9Q OiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1U T1A6IDBweCI+Jm5ic3A7PC9wPg0KPGRpdiBpZD0iTWFpbFNpZ25TZW50Ij4NCjxwIHN0eWxlPSJN QVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJPUkdNQUlMX0NPTlRFTlQiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8ZGl2PjxiPuuz tOuCuCDsgqzrnowgOiA8L2I+JnF1b3Q7Sm9hbiBDdWNjaGlhcmEmcXVvdDsgJmx0O2pjdWNjaGlh cmEuaWV0ZkBnbWFpbC5jb20mZ3Q7PC9kaXY+DQo8ZGl2PjxiPuuztOuCuCDrgqDsp5wgOiA8L2I+ MjAxNi0xMC0xOCAxMjowNTo1MiAoICYjNDM7MDk6MDAgKTwvZGl2Pg0KPGRpdj48Yj7rsJvripQg 7IKs656MIDogPC9iPuulmOygleuPmSAmbHQ7cnlvb0BldHJpLnJlLmtyJmd0OzwvZGl2Pg0KPGRp dj48Yj7ssLjsobAgOiA8L2I+TG9hIEFuZGVyc3NvbiAmbHQ7bG9hQHBpLm51Jmd0OywgbXBsc0Bp ZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssIGRyYWZ0LWlldGYtbXBscy10cC1saW5lYXIt cHJvdGVjdGlvbi1taWJAaWV0Zi5vcmcgJmx0O2RyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJv dGVjdGlvbi1taWJAaWV0Zi5vcmcmZ3Q7LCBtcGxzLWNoYWlyc0BpZXRmLm9yZyAmbHQ7bXBscy1j aGFpcnNAaWV0Zi5vcmcmZ3Q7LCBtaWItZG9jdG9yc0BpZXRmLm9yZyAmbHQ7bWliLWRvY3RvcnNA aWV0Zi5vcmcmZ3Q7LA0KIEJlbm9pdCBDbGFpc2UgJmx0O2JjbGFpc2VAY2lzY28uY29tJmd0Ozwv ZGl2Pg0KPGRpdj48Yj7soJzrqqkgOiA8L2I+UmU6IO2ajOyLoDogTUlCIERyLiByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi10cC1saW5lYXItbWliLTA5PC9kaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRP TTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxkaXYgZGlyPSJsdHIiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pkplb25nLWRvbmcsDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4 OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAw cHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQpUaGFuayB5b3UgZm9yIHRo ZSBxdWljayB0dXJuLWFyb3VuZCBhbmQgYWxzbyBmb3IgdGhlIHRob3JvdWdobmVzcyBvZiBhZGRy ZXNzaW5nIHRoaXMgbGFzdCByb3VuZCBvZiBjb21tZW50cy4mbmJzcDsmbmJzcDsgSSBiZWxpZXZl IHRoZSBNSUIgcmV2aWV3IGlzIGNvbXBsZXRlLg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBw eDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTog MHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KVGhhbmtzIGFnYWluIGZv ciBhbGwgeW91ciB0aW1lIGFuZCBlZmZvcnQgZHVyaW5nIHRoaXMgcHJvY2VzcywNCjxwIHN0eWxl PSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KPC9kaXY+ DQotSm9hbg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4m bmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgi PiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPHAgc3R5bGU9 Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBPY3QgMTIsIDIwMTYgYXQgMTA6MjkgQU0sIOulmOyg leuPmSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpyeW9vQGV0cmkucmUua3Ii IHRhcmdldD0iX2JsYW5rIj5yeW9vQGV0cmkucmUua3I8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6DQo8 cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4N CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4 OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0 KSAxcHggc29saWQiPg0KRGVhciBKb2FuLA0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsg TUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4 OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NClRoYW5rIHlvdSBzbyBtdWNoIGZvciB5b3Vy IHJldmlldyBhbmQgY29tbWVudHMuDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJH SU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCkFsbCB5b3VyIGNvbW1lbnRzIGhhZCBiZWVuIGluY29y cG9yYXRlZCBpbnRvIHRoZSByZXZpc2lvbiBwb3N0ZWQgYSBmZXcgbWludXRlcyBhZ28gYXMgZm9s bG93cy4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5i c3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4m bmJzcDs8L3A+DQpOYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ZHJhZnQtaWV0Zi1tcGxzLXRwLWxpbmVhci08d2JyPnByb3RlY3Rpb24tbWliDQo8cCBzdHlsZT0i TUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NClJldmlzaW9u OiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzEwDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTog MHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NClRpdGxlOiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSBMaW5lYXIgUHJvdGVjdGlv biBNSUINCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5i c3A7PC9wPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNi0xMC0xMg0KPHAgc3R5bGU9Ik1BUkdJ Ti1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQpHcm91cDombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1wbHMNCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9N OiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KUGFnZXM6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA0NQ0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFS R0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQpVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJvdGVjdGlvbi1taWItMTAudHh0IiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LTx3YnI+ZHJhZnRzL2RyYWZ0LWlldGYtbXBscy10cC08d2JyPmxpbmVhci1wcm90ZWN0aW9u LW1pYi0xMC50eHQ8L2E+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9Q OiAwcHgiPiZuYnNwOzwvcD4NClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1t cGxzLXRwLWxpbmVhci1wcm90ZWN0aW9uLW1pYi8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPHdicj5kb2MvZHJhZnQtaWV0Zi1t cGxzLXRwLWxpbmVhci08d2JyPnByb3RlY3Rpb24tbWliLzwvYT4NCjxwIHN0eWxlPSJNQVJHSU4t Qk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KSHRtbGl6ZWQ6Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJvdGVjdGlvbi1taWItMTAiIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC88d2JyPmRy YWZ0LWlldGYtbXBscy10cC1saW5lYXItPHdicj5wcm90ZWN0aW9uLW1pYi0xMDwvYT4NCjxwIHN0 eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KRGlm ZjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXBy b3RlY3Rpb24tbWliLTEwIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmPzx3YnI+dXJsMj1kcmFmdC1pZXRmLW1wbHMtdHAtPHdicj5s aW5lYXItcHJvdGVjdGlvbi1taWItMTA8L2E+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4 OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAw cHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KV291bGQgeW91IHBsZWFzZSBsZXQgdXMg a25vdyBpZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBjb21tZW50cyBvbiB0aGlzIGRvY3VtZW50IGF0 IHlvdXIgZWFybGllc3QgY29udmVuaWVuY2U/DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4 OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAw cHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KQmVzdCByZWFncmRzLA0KPHAgc3R5bGU9 Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHls ZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCkplb25n LWRvbmcNCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5i c3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4m bmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgi PiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBw eCI+Jm5ic3A7PC9wPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19f X19fDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNw OzwvcD4NCuuztOuCuCDsgqzrnow6IEpvYW4gQ3VjY2hpYXJhIFs8YSBocmVmPSJtYWlsdG86amN1 Y2NoaWFyYS5pZXRmQGdtYWlsLmNvbSI+amN1Y2NoaWFyYS5pZXRmQGdtYWlsLmNvbTwvYT5dDQo8 cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4N CuuztOuCuCDrgqDsp5w6IDIwMTbrhYQgMTDsm5QgOOydvCDthqDsmpTsnbwg7Jik7KCEIDk6NTMN CjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9w Pg0K67Cb64qUIOyCrOuejDogTG9hIEFuZGVyc3NvbjsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0 Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxz LXRwLWxpbmVhci1wcm90ZWN0aW9uLW1pYkBpZXRmLm9yZyI+DQpkcmFmdC1pZXRmLW1wbHMtdHAt bGluZWFyLTx3YnI+cHJvdGVjdGlvbi1taWJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 bXBscy1jaGFpcnNAaWV0Zi5vcmciPg0KbXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVm PSJtYWlsdG86bWliLWRvY3RvcnNAaWV0Zi5vcmciPm1pYi1kb2N0b3JzQGlldGYub3JnPC9hPg0K PHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+ DQrssLjsobA6IOulmOygleuPmTsgQmVub2l0IENsYWlzZQ0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RU T006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQrsoJzrqqk6IE1JQiBEci4gcmV2 aWV3IG9mIGRyYWZ0LWlldGYtdHAtbGluZWFyLW1pYi0wOQ0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RU T006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8ZGl2IGNsYXNzPSJIT0VuWmIi Pg0KPGRpdiBjbGFzcz0iaDUiPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lO LVRPUDogMHB4Ij4mbmJzcDs8L3A+DQpBdXRob3JzLA0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006 IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRP TTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NClRoYW5rIHlvdSBmb3IgYWRkcmVz c2luZyB0aGUgY29tbWVudHMgc28gdGhvcm91Z2hseSwgYW5kIGVzcGVjaWFsbHkgZm9yDQo8cCBz dHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCmNs YXJpZnlpbmcgdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiA3LiZuYnNwOyAmbmJzcDsgTXVjaCBhcHBy ZWNpYXRlZC4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+ Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4 Ij4mbmJzcDs8L3A+DQpUaGUgTUlCIGNvbXBpbGVzIHdpdGggc21pbGludCBhbmQgc21pY25nUFJP LiZuYnNwOyAmbmJzcDtDb21tZW50cyBhcmUgYmVsb3cuDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRP TTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9U VE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KVGhhbmsgeW91LA0KPHAgc3R5 bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQotSm9h bg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8 L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNw OzwvcD4NCkNvbW1lbnRzOg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRP UDogMHB4Ij4mbmJzcDs8L3A+DQotLS0tLS0tLS0tLS0tLS0tDQo8cCBzdHlsZT0iTUFSR0lOLUJP VFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4t Qk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KMSkgU2VjdGlvbiA2LjEg UmVsYXRpb25zaGlwIHRvIHRoZSBNUExTIE9BTSBNYWludGVuYW5jZSBJZGVudGlmaWVycyBNSUIg TW9kdWxlDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZu YnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+ Jm5ic3A7PC9wPg0KJm5ic3A7ICZuYnNwOyZxdW90O1RoZSBtcGxzTHBzTWVDb25maWdUYWJsZSBl bnRyeSBpcyBleHRlbmRlZCBieSB0aGUgZW50cnkgaW4gdGhlDQo8cCBzdHlsZT0iTUFSR0lOLUJP VFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCiZuYnNwOyAmbmJzcDttcGxz T2FtSWRNZVRhYmxlIGRlZmluZWQgaW4gW1JGQzc2OTddLiZxdW90Ow0KPHAgc3R5bGU9Ik1BUkdJ Ti1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFS R0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NClRoZSBhYm92ZSBz dGF0ZW1lbnQgaXMgYmFja3dhcmRzLi4uLnRoaW5rIHRoZSBpbnRlbnRpb24gaXMgdG8gc2F5IHNv bWV0aGluZyBsaWtlOg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDog MHB4Ij4mbmJzcDs8L3A+DQpFbnRyaWVzIGluIHRoZSBtcGxzT2FtSWRNZVRhYmxlIFtSRkM3Njk3 XSBhcmUgZXh0ZW5kZWQgYnkgZW50cmllcyBpbiB0aGUgbXBsc0xzcE1lQ29uZmlnVGFibGUuDQo8 cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4N CjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9w Pg0KMikgbGF0ZXIgaW4gdGhpcyBzYW1lIHNlY3Rpb24sIHNlY3Rpb24gNi4xDQo8cCBzdHlsZT0i TUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxl PSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KJm5ic3A7 ICZuYnNwOyZxdW90O0FuIGVudHJ5IG9mIHRoaXMgdGFibGUgaXMgcmVsYXRlZCB0byBhIHNpbmds ZSBlbnRyeSBpbiBtcGxzT2FtSWRNZVRhYmxlLiZxdW90Ow0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RU T006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJP VFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NClRoZSBhYm92ZSBpcyBjb25m dXNpbmcgYmVjYXVzZSB5b3UndmUgYWxyZWFkeSBkaXNjdXNzIHRoZSBzcGFyc2UgYXVnbWVudHMg cmVsYXRpb25zaGlwLiZuYnNwOyBQbGVhc2UgcmVtb3ZlDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRP TTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCnRoZSBhYm92ZSBzZW50ZW5jZS4N CjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9w Pg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8 L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNw OzwvcD4NCk1JQiBNb2R1bGUNCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1U T1A6IDBweCI+Jm5ic3A7PC9wPg0KLS0tLS0tLS0tLS0tDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRP TTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjMpJm5ic3A7IG1wbHNMcHNDb25m aWdJbmRleE5leHQmbmJzcDsgLSZuYnNwOyAmbmJzcDtwbGVhc2UgcmVuYW1lIHRvIG1wbHNMcHND b25maWdEb21haW5JbmRleE5leHQuDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJH SU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NClNpbmNlIHRoaXMgc2NhbGFyIGlzIG9ubHkgdXNlZCBm b3IgdGhlIG1wbHNMcHNDb25maWdEb21haW5JbmRleCBpbmRleCdzIHZhbHVlcywgdGhlIG5hbWUg c2hvdWxkIHJlZmxlY3QgdGhhdC4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJ Ti1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KTk9URTombmJzcDsgdGhpcyBuYW1lIGNoYW5nZSBzaG91 bGQgYmUgcHJvcGFnYXRlZCBlbHNld2hlcmUgaW4gdGhlIGRyYWZ0LiZuYnNwOyBQbGVhc2UgZG8g YSBzZWFyY2ggYW5kIHJlcGxhY2UuDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJH SU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1B UkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KNCkgbXBsc0xwc0NvbmZpZ0RvbWFpbkluZGV4Jm5i c3A7IChlZGl0b3JpYWwpDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9Q OiAwcHgiPiZuYnNwOzwvcD4NCiZuYnNwOyAmcXVvdDtNYW5hZ2VycyBzaG91bGQuLi4mcXVvdDsN CjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9w Pg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8 L3A+DQpzL01hbmFnZXJzL09wZXJhdG9ycy8NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7 IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBw eDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTog MHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjUpIG1wbHNMcHNDb25maWdDb21tYW5k DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwv cD4NCldoeSBpcyB0aGVyZSBOTyBERVZBTD8mbmJzcDsgJm5ic3A7V291bGRuJ3QgJnF1b3Q7bm9D bWQmcXVvdDsgYmUgYW4gYXBwcm9wcmlhdGUgREVGVkFMPw0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RU T006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJP VFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4t Qk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KNikgbXBsc0xwc0NvbmZp Z1Jvd1N0YXR1cyBERVNDUklQVElPTiBjbGF1c2UNCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAw cHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006 IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQpSb3dTdGF0dXMgb2JqZWN0cyByZWZs ZWN0IHRoZSBzdGF0dXMgb2YgdGhlIFJvdywgbm90IGEgZGV0ZXJtaW5hdGlvbiBvZiB3aGV0aGVy IG9yIG5vdCB2YWx1ZXMNCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6 IDBweCI+Jm5ic3A7PC9wPg0KYXJlICZxdW90O2FwcHJvcHJpYXRlJnF1b3Q7LiZuYnNwOyBQbGVh c2UgcmVtb3ZlIHRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoaXMgREVTQ1JJUFRJT046DQo8cCBzdHls ZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0 eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90Oy4uLkFuIGVudHJ5IG1heSBub3Qg ZXhpc3QgaW4gdGhlIGFjdGl2ZSBzdGF0ZSB1bmxlc3MgYWxsDQo8cCBzdHlsZT0iTUFSR0lOLUJP VFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgb2JqZWN0cyBpbiB0aGUgZW50cnkgaGF2ZSBhbiBhcHByb3ByaWF0 ZSB2YWx1ZS4mcXVvdDsNCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6 IDBweCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRP UDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4t VE9QOiAwcHgiPiZuYnNwOzwvcD4NCjcpJm5ic3A7IG1wbHNMcHNDb25maWdEb21haW5JbmRleCBh bmQgbXBsc0xwc01lQ29uZmlnRG9tYWluDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBN QVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7 IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KU2luY2UgTUlCcyBvZnRlbiBnZXQgc3RyaXBw ZWQgb3V0IG9mIFJGQ3MsIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgbXBsc0xwc0NvbmZp Z0RvbWFpbkluZGV4IGFuZA0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRP UDogMHB4Ij4mbmJzcDs8L3A+DQp0aGUgbXBsc0xwc01lQ29uZmlnRG9tYWluIG5lZWRzIHRvIGJl IGluY2x1ZGVkIGluIHRoZSBNSUIgTW9kdWxlIGl0c2VsZi4NCjxwIHN0eWxlPSJNQVJHSU4tQk9U VE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1C T1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQpCb3RoIERFU0NSSVBUSU9O IGNsYXVzZXMgbmVlZCB0byBiZSB1cGRhdGVkIHRvIGRlc2NyaWJlIHRoZSByZWxhdGlvbnNoaXAg YmV0d2VlbiB0aGVzZSBvYmplY3RzLiZuYnNwOyAmbmJzcDtWZXJiYWdlIHN1Y2ggYXMgJnF1b3Q7 V2hlbiB0aGUNCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+ Jm5ic3A7PC9wPg0KdmFsdWUgb2YgbXBsc0xwc0NvbmZpZ0RvbWFpbkluZGV4IGlzIHRoZSBzYW1l IGFzIHRoZSB2YWx1ZSBvZiBtcGxzTHBzTWVDb25maWdEb21haW4sIHRoYXQgbWVhbnMuLi4mcXVv dDsgYW5kIHRoZW4gZXhwbGFpbiB3aGF0DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBN QVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCnRoaXMgbWVhbnMuDQo8cCBzdHlsZT0iTUFSR0lO LUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJH SU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KOCkmbmJzcDsgbXBs c0xwc01lQ29uZmlnRG9tYWluIERFU0NSSVBUSU9OIChlZGl0b3JpYWwpDQo8cCBzdHlsZT0iTUFS R0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtUaGlzIG9iamVjdCBob2xkcyB0aGUgdmFsdWUg b2YgcHJvdGVjdGlvbiBkb21haW4gaW5kZXggd2hlcmVpbg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RU T006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHRoaXMgTUUgaW5jbHVkZWQgaW4uDQo8cCBzdHlsZT0iTUFSR0lOLUJP VFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4t Qk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0Kcy9pbmNsdWRlZCBpbi9p cyBpbmNsdWRlZC8NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBw eCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDog MHB4Ij4mbmJzcDs8L3A+DQotLS0NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJ Ti1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFS R0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBN QVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+ Jm5ic3A7PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A29223EC5SMTP2etriinfo_-- From nobody Wed Oct 19 02:04:35 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F8C129659; Wed, 19 Oct 2016 02:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YV7k2Vm9HW9t; Wed, 19 Oct 2016 02:04:28 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C4F1295AB; Wed, 19 Oct 2016 02:04:27 -0700 (PDT) X-AuditID: c1b4fb2d-1c7ff700000009f7-b2-58073718072d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id D0.27.02551.81737085; Wed, 19 Oct 2016 11:04:25 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 19 Oct 2016 11:04:24 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lseqx7ZxBinihBFTDnDGRdMCFlCGJUqSuPB5TSzB+Fw=; b=WhNvpQEPnPFoCknh0IyB1cgA0+BT+wM1lmXdnNJbepdyl1zdpfegyfkL7aLeyuqs7AOABycHyACuCTWChcr0ET29h1NrOJ63JivdFAaKdJhh/2cTQTiO9zvYDSEJuysuWDUFzTOBe1wIpBxP3E0Bz95xY5Kpw70eAzHt5kJ3KQU= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0995.eurprd07.prod.outlook.com (10.162.37.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Wed, 19 Oct 2016 09:04:22 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0669.018; Wed, 19 Oct 2016 09:04:22 +0000 From: Daniele Ceccarelli To: "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" , "pce@ietf.org" Thread-Topic: IETF 97 - Joint YANG session slot request Thread-Index: AdIp5rq8/cPAn7OaQie7/lzpgcNg1g== Date: Wed, 19 Oct 2016 09:04:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 20e33ba3-2f25-4a36-daa6-08d3f7feeafb x-microsoft-exchange-diagnostics: 1; AM2PR07MB0995; 6:5OTH7qeUWSIpVaFx1EEUTygkpV70Dra1UQGUevMOafzumoR22uBz72pH1sisjcb4hKMN98V2OrygLZnmAqTKmd99qRSKQ67BzRrUNCLlhXkOF72e7WF217N1gF1cxvlewWXFUKa7iLA3RkEozhp+ja9dSQN3Ogo57WsarBTemvvc0Cz6W8B+tVp5nA9Swrc43K5ZksZBX8P77fLM2tT4z8lvrh0YmsgGnVj9eNirEjNfGsxF6voPF4dNnA2YN4xoVBU3DlsGbGlY5Ec7MvDV9jkET4yr4LyPSTOgaUp87AvHztPhWg9aeXI+fobPJ9XN; 5:c+VRmfzo7cU14xbEjgazWSicb1XeQYFc6fOoVHv/ZMWIUV+Pait/gEaDQTHHLnLObjnOB9vIjZhYh8n5a9EYABpGm71r3f4aNkop3XL1fWAUnBfoR8VeVnp1SniC9n7lVdLwtJyJYa0Xc8Xq9u55Gg==; 24:xCrFCZLAJzH1Xf35cvc2bB6U58ix1pawga+JQ3Om6GUWrvJFKVykpuykx4JKuO+JOzwTQnxAAG1TzbM0XEdTNS1uUF0DV+TRVl7BdKZB28o=; 7:SvvguZoIcOwWE0rSQySVy3JF+mBY3v/7YjBTMo9/qJqpTP4FfKvqYrR5hv8RjdmdZQVWnEseTFEYc+vqs/5TOmBJL25LnzseVV/+cW2U21FNc3hA7AtQ5gJhGxYW83YGjfcyJSYnxKjHx9rP67z3IxVi1FdEeiPVCEgpQSwRu4rLVqLgS0Dimvo/Vhgrnb2RS0Ymww3gwjyekX1xBAxcCEqBIDjxlgqp3FGO4p5RPH0ayv5j2mG3a13tu7C5/K3xBOUM+KyqGvkZW9azWl4QoHQPxEi0Y/1904EHVSO7Xgv//3i8nNSp4H9vcZJ+Bn6V4MBVkfofvX7y1kuAenq2n6M2b9avJdh3a6if4M1PzL0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0995; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM2PR07MB0995; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0995; x-forefront-prvs: 0100732B76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(53754006)(189002)(377424004)(102836003)(87936001)(97736004)(8936002)(790700001)(5002640100001)(2900100001)(2906002)(105586002)(9686002)(19625215002)(6116002)(16236675004)(33656002)(77096005)(229853001)(2501003)(122556002)(86362001)(15975445007)(586003)(8676002)(107886002)(2201001)(3846002)(68736007)(5001770100001)(3280700002)(81156014)(81166006)(11100500001)(7846002)(7906003)(4001150100001)(189998001)(101416001)(99936001)(66066001)(19580395003)(76576001)(19580405001)(50986999)(92566002)(3660700001)(74316002)(54356999)(7736002)(450100001)(7696004)(106356001)(5660300001)(19617315012)(19300405004)(10400500002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0995; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_AM2PR07MB0994452A7D106F7FAA7A5851F0D20AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2016 09:04:22.3838 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0995 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA22SbWxLURjHnd57e+9K46jWHjOJFSOWzWyLNSKYDwyb+ESDhI6brem09HYL 9qVjZavMGqmwhjBm71MarAkjq9fNWIcMs7dOCRkhq9hmjF33Ch98+z3P//+c8/xPDkMovlMR jN5oYc1GXbZaKiNLtQ2q2OnJtDa+NTBb03mhmtIc6H1Ba2zDXnIFkVpePiLZgDbLlu5ks/W5 rHnhsu2yLOtlL7X7hwvtvfOpRGJF7UeQHYUxgJPg4onzhB3JGAV2I7DWOiRC8QBBY9tHki9I XEzAqOc0JShOCQy+tFL8vALfQ+BummJHDCPFSyDoS+PbSmyCn87LJM9TcQI0fh0jeIsSJ4PD vUawxMGjHg/NM4nnQk/zk98nyvFWKPN1EDwjPA2GWuokPBM4HDqDZyTC1koItD+UCqyC96/H KMGfAW6bV/REgb/GJXI6jIZuIn59wJ9pqPzwUxRWQUlgWGQDnLMVUgKvA9+NJkoYuI2gtnBI vC0SQvf7CUHwSOFVfpf4ECxU1tuQkDgCup8ViRwJ77oaKT49gfVQf22ikHIKNJcGSQeKdv0T zvXX5frHJbRN0NwpFdxx8OK4U+QYqCgbIASOhZNjPvJ//Ttt92iBo+BQw8HxWdk4VyE4dz5E CUIqFHfYiT8m55EAfRbJa5CKYzluV2ZCYhxr1u/gOJMxzshaPGj8HzZdGY31otqBFB/CDFJP ks/aIdUqKF0ut2+XD80ZP6f/Uq0fRZBGk5FVK+VJi2mtQr5Tt28/azZtM+dks5wPzWBIdbh8 cXXvJgXO1FlYA8vuZs1/VAkTFmFFpSmrc9J6Kq629tU5B+P7SnKDrrxbRbGG3C/qgoY33THE 9Q2GY6qzHv30wFuCXm55Xpc359TdZ/U0kzhS2DJxFV5WVF6wZWbUnkOkIzo8ZrM74Fe/Whs/ CU/QVD5tT2dWDl4aTi2ogrb5R/PXz8tfmfFY6521cfLhzhRLyP+tXKImuSzdogWEmdP9AjCl 3IePAwAA Archived-At: Subject: [mpls] IETF 97 - Joint YANG session slot request X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 09:04:30 -0000 --_004_AM2PR07MB0994452A7D106F7FAA7A5851F0D20AM2PR07MB0994eurp_ Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994452A7D106F7FAA7A5851F0D20AM2PR07MB0994eurp_" --_000_AM2PR07MB0994452A7D106F7FAA7A5851F0D20AM2PR07MB0994eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everyone, At the IETF 97 the joint YANG session (TEAS, MPLS, PCE, CCAMP) will be host= ed by CCAMP. The session is scheduled for Monday Nov 14th (15:50-17:50 - Monday Afterno= on session II). If you are willing to present a draft please request a slot using the link = below identifying if you believe that your draft should be presented only i= n the joint YANG session or also in the regular session of the relevant WGs= . We will share the results with the chairs of TEAS, MPLS and PCE, which will= decide how to allocate the slots. Thanks TEAS-MPLS-PCE-CCAMP co-chairs From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Oscar Gonz=E1lez d= e Dios Sent: mercoled=EC 19 ottobre 2016 10:48 To: CCAMP Subject: [CCAMP] IETF 97 - CCAMP slot request Dear CCAMPers, IETF 97 meeting @ Seoul is approaching and it's time to start collecting ag= enda slots requests. Please, keep this in mind: WG Draft authors are expected to present if there are open issues to discus= s, or to send status to the list *1 week* prior to the WG meeting if not p= resenting. Status includes review of: any recent changes, any open discussi= ons or issues, and planned next steps. Agenda Requests: - To submit a request, please fill the survey at the following link: http:/= /www.surveygizmo.com/s3/3124554/IETF-97-CCAMP-sessions-slot-requests - As there will be also a joint Yang session with other working groups, ple= ase indicate in the slot request if the authors believe that the draft shou= ld be presented in this joint YANG session only, in the CCAMP session only = or in both. - Please fill the survey no later than Thursday, October 27th. Presentations: If you are presenting slides please make sure you send them to all *indi= viduals* listed above (Chairs, Secretary and exclude CCAMP) no later than = Sunday, November 13th. Reminder about a few important dates: * 2016-10-31 (Monday): Internet Draft submission cut-off (for all drafts, i= ncluding -00) by UTC 23:59, upload using IETF ID Submission Tool. * 2016-10-31 (Monday): Draft Working Group agendas due by UTC 23:59, upload= using IETF Meeting Materials Management Tool. * 2016-11-07 (Monday): Revised Working Group agendas due by UTC 23:59, uplo= ad using IETF Meeting Materials Management Tool. * 2016-11-13 - 2016-11-18: IETF 97 in Seoul, South Korea Best Regards, =D3scar CCAMP WG Secretary --_000_AM2PR07MB0994452A7D106F7FAA7A5851F0D20AM2PR07MB0994eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello eve= ryone,

&nbs= p;

At the IE= TF 97 the joint YANG session (TEAS, MPLS, PCE, CCAMP) will be hosted by CCA= MP.

&nbs= p;

The sessi= on is scheduled for Monday  Nov 14th (15:50-17:50 - Monday = Afternoon session II).

&nbs= p;

If you ar= e willing to present a draft please request a slot using the link below ide= ntifying if you believe that your draft should be presented only in the joint YANG session or also in the regular session of= the relevant WGs.

We will s= hare the results with the chairs of TEAS, MPLS and PCE, which will decide h= ow to allocate the slots.

&nbs= p;

Thanks

TEAS-MPLS= -PCE-CCAMP co-chairs

&nbs= p;

&nbs= p;

&nbs= p;

From: = CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Oscar Gonz=E1lez de Dios
Sent: mercoled=EC 19 ottobre 2016 10:48
To: CCAMP <ccamp@ietf.org>
Subject: [CCAMP] IETF 97 - CCAMP slot request

 

Dear CCAMPers,

 =

IETF 97 meeting @ S= eoul is approaching and it’s time to start collecting agenda slo= ts requests.

 

Please, keep this in mind:

 =

WG Draft authors are expected to present if there are= open issues to discuss, or to send status to the list  *1 week* prior to the WG meeting if not presenting. Status incl= udes review of: any recent changes, any open discussions or issues, and pla= nned next steps.

 

= Agenda Requests:

- To submit a request, please fill the su= rvey at the following link: htt= p://www.surveygizmo.com/s3/3124554/IETF-97-CCAMP-sessions-slot-requests 

- As there will be also = a joint Yang session with other working groups, please indicate in the slot= request if the authors believe that the draft should be presented in this joint YANG session only, in the CCAMP session only or= in both.

 

- Please fill the survey no later than Thursd= ay, October 27th.

 

= Presentations:

  If you are presenting slides please make sure = you send them to  all *individuals* listed above (Chairs, Secretary and exclude CCAMP) no later  than Sunday, November = 13th.

 

= Reminder about a few important dates= :

 =

* 2016-10-3= 1 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload us= ing IETF ID Su= bmission Tool.

* 2016-10-3= 1 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeti= ng Materials Management Tool.

* 2016-= 11-07 (Monday): Revised Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.

* 2016-11-1= 3 - 2016-11-18: IETF 97 in Seoul, South Korea

 

Best Regards,=

 =

=D3scar 

 

        CCAMP WG Se= cretary

--_000_AM2PR07MB0994452A7D106F7FAA7A5851F0D20AM2PR07MB0994eurp_-- --_004_AM2PR07MB0994452A7D106F7FAA7A5851F0D20AM2PR07MB0994eurp_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=130; creation-date="Wed, 19 Oct 2016 08:48:27 GMT"; modification-date="Wed, 19 Oct 2016 08:48:27 GMT" Content-ID: <0BCC43A91CD22D4882F3849A4617C854@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1h aWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2NhbXANCg== --_004_AM2PR07MB0994452A7D106F7FAA7A5851F0D20AM2PR07MB0994eurp_-- From nobody Wed Oct 19 03:14:58 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCCE129442; Wed, 19 Oct 2016 03:14:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147687209370.8852.7992909075862568264.idtracker@ietfa.amsl.com> Date: Wed, 19 Oct 2016 03:14:53 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-kompella-mpls-larp-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 10:14:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Label Distribution Using ARP Authors : Kireeti Kompella Balaji Rajagopalan George Swallow Filename : draft-kompella-mpls-larp-06.txt Pages : 16 Date : 2016-10-19 Abstract: This document describes extensions to the Address Resolution Protocol to distribute MPLS labels for IPv4 and IPv6 host addresses. Distribution of labels via ARP enables simple plug-and-play operation of MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kompella-mpls-larp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-kompella-mpls-larp-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-kompella-mpls-larp-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 20 01:14:08 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E49F127735; Thu, 20 Oct 2016 01:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.033 X-Spam-Level: X-Spam-Status: No, score=-3.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzOS6ORz0sUC; Thu, 20 Oct 2016 01:14:05 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97D0129432; Thu, 20 Oct 2016 01:14:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2FE48101699; Thu, 20 Oct 2016 10:14:02 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsefYHaLeRtT; Thu, 20 Oct 2016 10:14:02 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 0DC23101665; Thu, 20 Oct 2016 10:13:52 +0200 (CEST) Received: from HYDRA.office.hd ([169.254.4.39]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 10:13:51 +0200 From: Rolf Winter To: "BRUNGARD, DEBORAH A" , Loa Andersson , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements Thread-Index: AQHSEZj7spx1qqSFskizzMzQwxEY9qCbDRGAgABZJvCAACpRgIAVn4yg Date: Thu, 20 Oct 2016 08:13:49 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295DAF12C76F@Hydra.office.hd> References: <06102f2d-8f1d-aac6-9d34-10a27d600bf8@pi.nu> <791AD3077F94194BB2BDD13565B6295DAF1196AD@PALLENE.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 08:14:07 -0000 Hi, FWIW, to me personally, what Deborah suggests seems the most sensible way f= orward. Best, Rolf -----Original Message----- From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]=20 Sent: Donnerstag, 6. Oktober 2016 18:00 To: Rolf Winter; Loa Andersson; mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and-requirements@= ietf.org Subject: RE: working group last call on draft-ietf-mpls-tp-mfp-use-case-and= -requirements Hi, I agree with Loa on this is not an update of RFC5654. RFC5654 is a document= reflecting ITU-T requirements for MPLS-TP. This draft is not a result of a= request by ITU-T. The document is building on RFC6372, but it doesn't necessarily "update" RF= C6372. RFC6372 covers a wide range of mechanisms. An implementer of RFC6372= does not have to also implement this document unless they want to support = this extra capability. So this capability is not required for any of those = existing requirements, it's only needed if one wants this capability, so th= e requirements can stand on their own. Note, RFC6372 did not update RFC5654= . I'm recommending to hold this document in the WG until a solution document = is initiated. By doing a solution document, it will help determine if these= requirements and the resulting solution are an update for any of the exist= ing solution documents. As the document only has two requirements, it can be part of an appendix to= a solution document. PCE recently did such a document: https://www.ietf.org/id/draft-ietf-pce-pcep-service-aware-13.txt Of more concern, I've not seen any mailing list discussion on this document= or any solution document proposed indicating interest by the WG, I strongl= y encourage the list be used as progress a solution document. Working in pa= rallel on requirements and a solution is always the best approach. Requirem= ents documents do not need to be published as RFCs, especially these very s= hort type of documents. The IETF Chair summarized this in his May blog on t= he IESG retreat: https://www.ietf.org/blog/2016/05/ Thanks, Deborah > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Rolf Winter > Sent: Thursday, October 06, 2016 7:37 AM > To: Loa Andersson ; mpls@ietf.org > Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and- > requirements@ietf.org > Subject: Re: [mpls] working group last call on=20 > draft-ietf-mpls-tp-mfp-use-case- and-requirements >=20 > Hi, >=20 > please see inline. >=20 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Donnerstag, 6. Oktober 2016 10:09 > To: mpls@ietf.org > Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and- > requirements@ietf.org > Subject: Re: working group last call on=20 > draft-ietf-mpls-tp-mfp-use-case-and- > requirements >=20 > Working Group, authors, >=20 > We are past the closing date for this wglc. I'm reluctant to close the la= st call. > The reason is that I received some comments off-line that I'd like to=20 > hear feed back on. >=20 > 1. Existing solution mechanism(s) > ------------------------------ > It is said that even though we have no existing implementations of > m:n, there are existing solutions mechanisms that meet the > requirements. > I would like to have this verified if possible. >=20 > 2. Not an update of 5654 > --------------------- > This is probably correct, this document adds two new requirements, > but does in no way change RFC 5654. >=20 > --- RW > This is the text concerning updates of RFC in RFC2223 (it has recently=20 > been obsoleted by RFC 7322, but text regarding the reasoning behind=20 > updates has basically vanished there as far as I can tell): >=20 > Updates >=20 > To be used as a reference from a new item that cannot be used > alone (i.e., one that supplements a previous document), to refer > to the previous document. The newer publication is a part that > will supplement or be added on to the existing document; e.g., an > addendum, or separate, extra information that is to be added to > the original document. >=20 > I think this makes this document an update as it contains an addendum=20 > essentially. Or the other way round, if you read 5654, there is no way=20 > the reader can tell there are more requirements. An update will make that= clear. > --- >=20 > 3. Document structure > ------------------ > IESG members has recently expressed opinions that we should not > publish small stand alone document with a small number of use cases > or requirements, thes should rather be kept with the working and > published as appendices to the solutions document. > I would like to hear comments on this. >=20 > --- RW > I can understand this and usually I would agree. But then, given the=20 > above that solution document would need to update RFC5654 and that=20 > would be strange, having a solution document update a requirements=20 > document. It would mix two things I believe should be separate. You=20 > unfortunately cannot restrict an update of an RFC to a section of a diffe= rent RFC. >=20 > --- >=20 > 4. The document need to be liaised to ITU-T SG15 > --------------------------------------------- > I agree with this, normally we liaise wg consensus texts, and the > document could be liaised when the wglc closes. >=20 > --- RW >=20 > Yes, that should be done. >=20 > Best, >=20 > Rolf >=20 > --- >=20 > To hear the feedback on this I will keep the wglc open for another=20 > week starting today. >=20 > /Loa > mpls wg co-chair >=20 > On 18/09/2016 18:39, Loa Andersson wrote: > > Working Group, > > > > This is to initiate a two week working group last call on=20 > > draft-ietf-mpls-tp-mfp-use-case-and-requirements-02. > > > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > > > There were no IPR disclosures against this document. > > > > All the authors and contributors have stated on the working group=20 > > mailing list that they are not aware of any IPRs that relates to=20 > > this document. > > > > This working group last call ends Oct 2, 2016. > > > > > > /Loa > > for the MPLS wg chairs >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Oct 20 18:37:04 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331B9129488; Thu, 20 Oct 2016 18:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBziHL9nZ-_Y; Thu, 20 Oct 2016 18:37:01 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B841293F2; Thu, 20 Oct 2016 18:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9918; q=dns/txt; s=iport; t=1477013821; x=1478223421; h=from:to:cc:subject:date:message-id:mime-version; bh=OxVFYtr4bfNbUo49vYtc9vEjpkqCrcIlRrWUsVE4he4=; b=etsvCp43BtlIND6ZnWgSAse2SqlQLdyJjudKxNf9jt0l10vwzvJvRt8F +4o+6merA7UCXIbRyZDCe1JGfPeUOMSicN6VSbc43Qb1aJQOUR7riLoAi BMsha66xFlFO60TF9bAYDOo/jnQ0CJrHSWD8554BrWhCBBYRElAUvS1lE Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQD/bwlY/4oNJK1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBgwg2AQEBAQEdV30HjS2mJIMGgg+CCCeFehyBXD8UAQIBAQEBAQEBYh0LhGk?= =?us-ascii?q?jVhIBSgIEMCcEDohXDrZWjH4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYY9gX0Ih?= =?us-ascii?q?y6CbSyCLwWORYtJAYE7hG6JY4FuhGmJJIcThWyDfwEeNliEeHIBhmkEgSuBAAE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.31,521,1473120000"; d="scan'208,217";a="160287564" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2016 01:37:00 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u9L1axup011042 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Oct 2016 01:37:00 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Oct 2016 21:36:59 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Thu, 20 Oct 2016 21:36:59 -0400 From: "Tarek Saad (tsaad)" To: "mpls@ietf.org" Thread-Topic: Building agenda for MPLS WG session - Seoul IETF97 Thread-Index: AQHSKzudGJ9KXqClkE+e89mM8aYt1w== Date: Fri, 21 Oct 2016 01:36:58 +0000 Message-ID: <532EC4D1-12AB-4506-B1C4-A98AC84AD5B4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.208.190] Content-Type: multipart/alternative; boundary="_000_532EC4D112AB4506B1C4A98AC84AD5B4ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls-chairs@ietf.org" Subject: [mpls] Building agenda for MPLS WG session - Seoul IETF97 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 01:37:03 -0000 --_000_532EC4D112AB4506B1C4A98AC84AD5B4ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpXZSBhcmUgc3RhcnRpbmcgdG8gYnVpbGQgdGhlIE1QTFMgV0cgYWdlbmRhIGZv ciBJRVRGOTcgaW4gU2VvdWwsIFNvdXRoIEtvcmVhLiBUaGUgcHJlbGltaW5hcnkgYWdlbmRhLCBp cyBub3cgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5n Lzk3L2FnZW5kYS5odG1sDQoNClRoZSBNUExTIFdHIHNlc3Npb24gaXMgc2NoZWR1bGVkIGZvcjoN ClRodXJzZGF5LCBOb3ZlbWJlciAxNywgMjAxNiAoS1NUKSAtIDE1OjIwLTE3OjUwIFRodXJzZGF5 IEFmdGVybm9vbiBzZXNzaW9uIElJDQoNClRoZXJlIGlzIGEgam9pbnQgc2Vzc2lvbiBmb3IgTVBM UywgVEVBUyBhbmQgUENFIFdHcyBmb3IgdG9waWNzIG9mIGNvbW1vbiBpbnRlcmVzdCAoaW5jbHVk aW5nIFlBTkcgbW9kZWxzKSDigJMgaG9zdGVkIGJ5IFBDRSBXRyB0aGlzIHRpbWUgYW5kIHNjaGVk dWxlZCBmb3I6DQpNb25kYXksIE5vdmVtYmVyIDE0LCAyMDE2IChLU1QpIC0gMTU6NTAtMTc6NTAg TW9uZGF5IEFmdGVybm9vbiBzZXNzaW9uIElJDQoNClBsZWFzZSBzZW5kIHNsb3QgcmVxdWVzdHMg Zm9yIHRoZSBNUExTIHNlc3Npb24gZGlyZWN0ZWQgdG8gbXlzZWxmIGFuZCB0aGUgV0cgY2hhaXJz IGJ5IFN1bmRheSwgT2N0b2JlciAzMHRoaCAtIGluZGljYXRpbmcgZHJhZnQgbmFtZSwgc3BlYWtl ciBhbmQgZGVzaXJlZCBkdXJhdGlvbi4NCklmIHByZXNlbnRpbmcsIHlvdXIgc2xpZGVzIHdpbGwg YmUgZHVlIGJ5IFN1bmRheSBOb3ZlbWJlciAxM3RoLiBQbGVhc2Ugc2VuZCBzbGlkZXMgYWxzbyB0 byB0aGUgYWRkcmVzc2VzIGFib3ZlLg0KDQpBIHJlbWluZGVyIHRvIGF1dGhvcnMvZWRpdG9ycyBv ZiBXRyBkcmFmdHMgdGhhdCB3aWxsIG5vdCBiZSBkaXNjdXNzZWQvcHJlc2VudGVkIGF0IElFVDk3 IHRvIHNlbmQgc3RhdHVzIHVwZGF0ZSByZXBvcnQgdG8gdGhlIFdHIGxpc3QgYnkgU3VuZGF5IE5v dmVtYmVyIDEzdGggc28gaXQgaXMgaW5jbHVkZWQgaW4gdGhlIFdHIHByb2dyZXNzIHJlcG9ydC4N Cg0KUmVnYXJkcywNClRhcmVrIGFuZCBNUExTIFdHIGNoYWlycw0KDQpJbXBvcnRhbnQgZGF0ZXM6 DQoyMDE2LTEwLTMxIChNb25kYXkpOiBJbnRlcm5ldCBEcmFmdCBzdWJtaXNzaW9uIGN1dC1vZmYg KGZvciBhbGwgZHJhZnRzLCBpbmNsdWRpbmcgLTAwKSBieSBVVEMgMjM6NTksIHVwbG9hZCB1c2lu ZyBJRVRGIElEIFN1Ym1pc3Npb24gVG9vbC4NCjIwMTYtMTAtMzEgKE1vbmRheSk6IERyYWZ0IFdv cmtpbmcgR3JvdXAgYWdlbmRhcyBkdWUgYnkgVVRDIDIzOjU5LCB1cGxvYWQgdXNpbmcgSUVURiBN ZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuDQoyMDE2LTExLTA0IChGcmlkYXkpOiBF YXJseSBCaXJkIHJlZ2lzdHJhdGlvbiBhbmQgcGF5bWVudCBjdXQtb2ZmIGF0IFVUQyAyMzo1OS4N CjIwMTYtMTEtMDcgKE1vbmRheSk6IFJldmlzZWQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBi eSBVVEMgMjM6NTksIHVwbG9hZCB1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1l bnQgVG9vbC4NCjIwMTYtMTEtMDcgKE1vbmRheSk6IFJlZ2lzdHJhdGlvbiBjYW5jZWxsYXRpb24g Y3V0LW9mZiBhdCBVVEMgMjM6NTkuDQoyMDE2LTExLTExIChGcmlkYXkpOiBGaW5hbCBQcmUtUmVn aXN0cmF0aW9uIGFuZCBQcmUtUGF5bWVudCBjdXQtb2ZmIGF0IDE3OjAwIGxvY2FsIG1lZXRpbmcg dGltZS4NCjIwMTYtMTEtMTMgLSAyMDE2LTExLTE4OiBJRVRGIDk3IGluIFNlb3VsLCBTb3V0aCBL b3JlYQ0KDQo= --_000_532EC4D112AB4506B1C4A98AC84AD5B4ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0D0F54D9B6824748B2BF07756C245C4C@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+SGkg YWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0 b3NwYWNlOm5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPldlIGFyZSBzdGFydGluZyB0byBidWlsZCB0aGUg TVBMUyBXRyBhZ2VuZGEgZm9yIElFVEY5NyBpbiBTZW91bCwgU291dGggS29yZWEuIFRoZSBwcmVs aW1pbmFyeSBhZ2VuZGEsIGlzIG5vdyBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk3L2FnZW5kYS5odG1sIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTcvYWdlbmRhLmh0bWw8L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h dXRvc3BhY2U6bm9uZSI+VGhlIE1QTFMgV0cgc2Vzc2lvbiBpcyBzY2hlZHVsZWQgZm9yOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5v bmUiPlRodXJzZGF5LCBOb3ZlbWJlciAxNywgMjAxNiAoS1NUKSAtIDE1OjIwLTE3OjUwIFRodXJz ZGF5IEFmdGVybm9vbiBzZXNzaW9uIElJPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+VGhlcmUgaXMg YSBqb2ludCBzZXNzaW9uIGZvciBNUExTLCBURUFTIGFuZCBQQ0UgV0dzIGZvciB0b3BpY3Mgb2Yg Y29tbW9uIGludGVyZXN0IChpbmNsdWRpbmcgWUFORyBtb2RlbHMpIOKAkyBob3N0ZWQgYnkgUENF IFdHIHRoaXMgdGltZSBhbmQgc2NoZWR1bGVkIGZvcjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj5Nb25kYXksIE5vdmVtYmVy IDE0LCAyMDE2IChLU1QpIC0gMTU6NTAtMTc6NTAgTW9uZGF5IEFmdGVybm9vbiBzZXNzaW9uIElJ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3Bh Y2U6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+UGxlYXNlIHNlbmQgc2xvdCByZXF1ZXN0cyBmb3IgdGhl IE1QTFMgc2Vzc2lvbiBkaXJlY3RlZCB0byBteXNlbGYgYW5kIHRoZSBXRyBjaGFpcnMgYnkgU3Vu ZGF5LCBPY3RvYmVyIDMwdGg8c3VwPmg8L3N1cD4gLSBpbmRpY2F0aW5nIGRyYWZ0IG5hbWUsIHNw ZWFrZXIgYW5kIGRlc2lyZWQgZHVyYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+SWYgcHJlc2VudGluZywgeW91ciBz bGlkZXMgd2lsbCBiZSBkdWUgYnkmbmJzcDtTdW5kYXkgTm92ZW1iZXIgMTN0aC4gUGxlYXNlIHNl bmQgc2xpZGVzIGFsc28gdG8gdGhlIGFkZHJlc3NlcyBhYm92ZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpu b25lIj5BIHJlbWluZGVyIHRvIGF1dGhvcnMvZWRpdG9ycyBvZiBXRyBkcmFmdHMgdGhhdCB3aWxs IG5vdCBiZSBkaXNjdXNzZWQvcHJlc2VudGVkIGF0IElFVDk3IHRvIHNlbmQgc3RhdHVzIHVwZGF0 ZSByZXBvcnQgdG8gdGhlIFdHIGxpc3QgYnkgU3VuZGF5IE5vdmVtYmVyIDEzPHN1cD50aDwvc3Vw PiBzbyBpdCBpcyBpbmNsdWRlZCBpbiB0aGUgV0cgcHJvZ3Jlc3MgcmVwb3J0LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0 b3NwYWNlOm5vbmUiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+VGFyZWsgYW5kIE1QTFMgV0cgY2hhaXJzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6 bm9uZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hdXRvc3BhY2U6bm9uZSI+SW1wb3J0YW50IGRhdGVzOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjIwMTYtMTAtMzEg KE1vbmRheSk6IEludGVybmV0IERyYWZ0IHN1Ym1pc3Npb24gY3V0LW9mZiAoZm9yIGFsbCBkcmFm dHMsIGluY2x1ZGluZyAtMDApIGJ5IFVUQyAyMzo1OSwgdXBsb2FkIHVzaW5nIElFVEYgSUQgU3Vi bWlzc2lvbiBUb29sLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtYXV0b3NwYWNlOm5vbmUiPjIwMTYtMTAtMzEgKE1vbmRheSk6IERyYWZ0IFdvcmtpbmcg R3JvdXAgYWdlbmRhcyBkdWUgYnkgVVRDIDIzOjU5LCB1cGxvYWQgdXNpbmcgSUVURiBNZWV0aW5n IE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+MjAxNi0xMS0wNCAoRnJpZGF5KTog RWFybHkgQmlyZCByZWdpc3RyYXRpb24gYW5kIHBheW1lbnQgY3V0LW9mZiBhdCBVVEMgMjM6NTku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3Bh Y2U6bm9uZSI+MjAxNi0xMS0wNyAoTW9uZGF5KTogUmV2aXNlZCBXb3JraW5nIEdyb3VwIGFnZW5k YXMgZHVlIGJ5IFVUQyAyMzo1OSwgdXBsb2FkIHVzaW5nIElFVEYgTWVldGluZyBNYXRlcmlhbHMg TWFuYWdlbWVudCBUb29sLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjIwMTYtMTEtMDcgKE1vbmRheSk6IFJlZ2lzdHJhdGlv biBjYW5jZWxsYXRpb24gY3V0LW9mZiBhdCBVVEMgMjM6NTkuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+MjAxNi0xMS0xMSAo RnJpZGF5KTogRmluYWwgUHJlLVJlZ2lzdHJhdGlvbiBhbmQgUHJlLVBheW1lbnQgY3V0LW9mZiBh dCAxNzowMCBsb2NhbCBtZWV0aW5nIHRpbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+MjAxNi0xMS0xMyAtIDIwMTYtMTEt MTg6IElFVEYgOTcgaW4gU2VvdWwsIFNvdXRoIEtvcmVhPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_532EC4D112AB4506B1C4A98AC84AD5B4ciscocom_-- From nobody Fri Oct 21 16:24:42 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BC2129888; Fri, 21 Oct 2016 16:21:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207307.28214.14741547715657550729.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:13 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] mpls - Requested session has been scheduled for IETF 97 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:13 -0000 Dear Tarek Saad, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mpls Session 1 (2:30:00) Thursday, Afternoon Session II 1520-1750 Room Name: Park Ballroom 1 size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Multiprotocol Label Switching Area Name: Routing Area Session Requester: Tarek Saad Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: teas ccamp pce bess bfd idr pals bier detnet Second Priority: nvo3 sfc spring i2rs rtgarea rtgwg Third Priority: ospf isis sidr Special Requests: --------------------------------------------------------- From nobody Fri Oct 21 19:38:50 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E909129451; Fri, 21 Oct 2016 19:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZanYZjvwO1EM; Fri, 21 Oct 2016 19:38:45 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E46129454; Fri, 21 Oct 2016 19:38:45 -0700 (PDT) Received: from [192.168.1.8] (unknown [49.146.50.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 06CB318013BE; Sat, 22 Oct 2016 04:38:40 +0200 (CEST) To: Rolf Winter , "BRUNGARD, DEBORAH A" , "mpls@ietf.org" References: <06102f2d-8f1d-aac6-9d34-10a27d600bf8@pi.nu> <791AD3077F94194BB2BDD13565B6295DAF1196AD@PALLENE.office.hd> <791AD3077F94194BB2BDD13565B6295DAF12C76F@Hydra.office.hd> From: Loa Andersson Message-ID: Date: Sat, 22 Oct 2016 10:38:36 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <791AD3077F94194BB2BDD13565B6295DAF12C76F@Hydra.office.hd> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 02:38:49 -0000 Rolf, et.al., Yes that might be the only route open to us, but as you said early we will lose requirement trceability and I don't like that. Does anyone have an idea how to fix that? /Loa On 2016-10-20 16:13, Rolf Winter wrote: > Hi, > > FWIW, to me personally, what Deborah suggests seems the most sensible way forward. > > Best, > > Rolf > > -----Original Message----- > From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] > Sent: Donnerstag, 6. Oktober 2016 18:00 > To: Rolf Winter; Loa Andersson; mpls@ietf.org > Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org > Subject: RE: working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements > > Hi, > > I agree with Loa on this is not an update of RFC5654. RFC5654 is a document reflecting ITU-T requirements for MPLS-TP. This draft is not a result of a request by ITU-T. > > The document is building on RFC6372, but it doesn't necessarily "update" RFC6372. RFC6372 covers a wide range of mechanisms. An implementer of RFC6372 does not have to also implement this document unless they want to support this extra capability. So this capability is not required for any of those existing requirements, it's only needed if one wants this capability, so the requirements can stand on their own. Note, RFC6372 did not update RFC5654. > > I'm recommending to hold this document in the WG until a solution document is initiated. By doing a solution document, it will help determine if these requirements and the resulting solution are an update for any of the existing solution documents. > > As the document only has two requirements, it can be part of an appendix to a solution document. PCE recently did such a document: > https://www.ietf.org/id/draft-ietf-pce-pcep-service-aware-13.txt > > Of more concern, I've not seen any mailing list discussion on this document or any solution document proposed indicating interest by the WG, I strongly encourage the list be used as progress a solution document. Working in parallel on requirements and a solution is always the best approach. Requirements documents do not need to be published as RFCs, especially these very short type of documents. The IETF Chair summarized this in his May blog on the IESG retreat: > https://www.ietf.org/blog/2016/05/ > > Thanks, > Deborah > >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Rolf Winter >> Sent: Thursday, October 06, 2016 7:37 AM >> To: Loa Andersson ; mpls@ietf.org >> Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and- >> requirements@ietf.org >> Subject: Re: [mpls] working group last call on >> draft-ietf-mpls-tp-mfp-use-case- and-requirements >> >> Hi, >> >> please see inline. >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Donnerstag, 6. Oktober 2016 10:09 >> To: mpls@ietf.org >> Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and- >> requirements@ietf.org >> Subject: Re: working group last call on >> draft-ietf-mpls-tp-mfp-use-case-and- >> requirements >> >> Working Group, authors, >> >> We are past the closing date for this wglc. I'm reluctant to close the last call. >> The reason is that I received some comments off-line that I'd like to >> hear feed back on. >> >> 1. Existing solution mechanism(s) >> ------------------------------ >> It is said that even though we have no existing implementations of >> m:n, there are existing solutions mechanisms that meet the >> requirements. >> I would like to have this verified if possible. >> >> 2. Not an update of 5654 >> --------------------- >> This is probably correct, this document adds two new requirements, >> but does in no way change RFC 5654. >> >> --- RW >> This is the text concerning updates of RFC in RFC2223 (it has recently >> been obsoleted by RFC 7322, but text regarding the reasoning behind >> updates has basically vanished there as far as I can tell): >> >> Updates >> >> To be used as a reference from a new item that cannot be used >> alone (i.e., one that supplements a previous document), to refer >> to the previous document. The newer publication is a part that >> will supplement or be added on to the existing document; e.g., an >> addendum, or separate, extra information that is to be added to >> the original document. >> >> I think this makes this document an update as it contains an addendum >> essentially. Or the other way round, if you read 5654, there is no way >> the reader can tell there are more requirements. An update will make that clear. >> --- >> >> 3. Document structure >> ------------------ >> IESG members has recently expressed opinions that we should not >> publish small stand alone document with a small number of use cases >> or requirements, thes should rather be kept with the working and >> published as appendices to the solutions document. >> I would like to hear comments on this. >> >> --- RW >> I can understand this and usually I would agree. But then, given the >> above that solution document would need to update RFC5654 and that >> would be strange, having a solution document update a requirements >> document. It would mix two things I believe should be separate. You >> unfortunately cannot restrict an update of an RFC to a section of a different RFC. >> >> --- >> >> 4. The document need to be liaised to ITU-T SG15 >> --------------------------------------------- >> I agree with this, normally we liaise wg consensus texts, and the >> document could be liaised when the wglc closes. >> >> --- RW >> >> Yes, that should be done. >> >> Best, >> >> Rolf >> >> --- >> >> To hear the feedback on this I will keep the wglc open for another >> week starting today. >> >> /Loa >> mpls wg co-chair >> >> On 18/09/2016 18:39, Loa Andersson wrote: >>> Working Group, >>> >>> This is to initiate a two week working group last call on >>> draft-ietf-mpls-tp-mfp-use-case-and-requirements-02. >>> >>> Please send your comments to the mpls wg mailing list (mpls@ietf.org). >>> >>> There were no IPR disclosures against this document. >>> >>> All the authors and contributors have stated on the working group >>> mailing list that they are not aware of any IPRs that relates to >>> this document. >>> >>> This working group last call ends Oct 2, 2016. >>> >>> >>> /Loa >>> for the MPLS wg chairs >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Oct 21 21:33:55 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41FD1294F5; Fri, 21 Oct 2016 21:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vz0_8Z-AEyy; Fri, 21 Oct 2016 21:33:52 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BEB1294ED; Fri, 21 Oct 2016 21:33:49 -0700 (PDT) Received: from [192.168.1.8] (unknown [49.146.50.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8CD3418013BE; Sat, 22 Oct 2016 06:33:46 +0200 (CEST) To: "mpls@ietf.org" From: Loa Andersson Message-ID: Date: Sat, 22 Oct 2016 12:33:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mpls-flow-ident@ietf.org, "mpls-chairs@ietf.org" Subject: [mpls] IPR poll on draft-ietf-mpls-flow-ident X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 04:33:54 -0000 Working Group, We are currently preparing draft-ietf-mpls-flow-ident-02 for working group last call. We will do an IPR poll prior to the wglc. This is to start the IPR Poll. Are you aware of any IPR that applies to draft-ietf-mpls-flow-ident? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There is no IPR disclosure filed directly against this documents. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Oct 23 19:35:10 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA521293F0; Sun, 23 Oct 2016 19:35:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147727650890.16090.2207899850368272898.idtracker@ietfa.amsl.com> Date: Sun, 23 Oct 2016 19:35:08 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ijln-mpls-rfc5036bis-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 02:35:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : LDP Specification Authors : Xia Chen Loa Andersson Nic Leymann Ina Minei Kamran Raza Filename : draft-ijln-mpls-rfc5036bis-03.txt Pages : 141 Date : 2016-10-23 Abstract: The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ijln-mpls-rfc5036bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ijln-mpls-rfc5036bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ijln-mpls-rfc5036bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 23 19:41:53 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8708F1294AC; Sun, 23 Oct 2016 19:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CEVpAfU8Dzg; Sun, 23 Oct 2016 19:41:50 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF746129575; Sun, 23 Oct 2016 19:41:49 -0700 (PDT) Received: from [192.168.1.8] (unknown [49.146.50.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 12F8F18013E2; Mon, 24 Oct 2016 04:41:40 +0200 (CEST) References: <147727650890.16090.2207899850368272898.idtracker@ietfa.amsl.com> To: "mpls@ietf.org" From: Loa Andersson X-Forwarded-Message-Id: <147727650890.16090.2207899850368272898.idtracker@ietfa.amsl.com> Message-ID: <0d2966a9-02c6-628a-5b29-2d84806087ce@pi.nu> Date: Mon, 24 Oct 2016 10:41:31 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147727650890.16090.2207899850368272898.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ijln-mpls-rfc5036bis@ietf.org, "mpls-chairs@ietf.org" Subject: [mpls] Fwd: I-D Action: draft-ijln-mpls-rfc5036bis-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 02:41:52 -0000 Working Group, We have posted a new version of draft-ijln-mpls-rfc5036bis, sadly enough it is nothing but an administrative update (change of dates and version number). We have two very well defined tasks to undertake as soon as we have time: - rewrite/update the IANA section according to the instructions from IANA - incorporate documents that will be obsoleted /Loa -------- Forwarded Message -------- Subject: [mpls] I-D Action: draft-ijln-mpls-rfc5036bis-03.txt Date: Sun, 23 Oct 2016 19:35:08 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : LDP Specification Authors : Xia Chen Loa Andersson Nic Leymann Ina Minei Kamran Raza Filename : draft-ijln-mpls-rfc5036bis-03.txt Pages : 141 Date : 2016-10-23 Abstract: The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ijln-mpls-rfc5036bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ijln-mpls-rfc5036bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ijln-mpls-rfc5036bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Oct 24 02:34:11 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BBA129663; Mon, 24 Oct 2016 02:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJTPc9LK4hAr; Mon, 24 Oct 2016 02:34:09 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 DC1C4129661; Mon, 24 Oct 2016 02:34:08 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id f134so26088924lfg.2; Mon, 24 Oct 2016 02:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=3qf1v8XfKe7gYIU+E3Cmxutne3hLPfdAS6lS+1noQvg=; b=ktS2Gk2DLR40nWQlF8U/OqsuYmlmE8Pq1oMkNXS68b7bF7Zel4VqHJ95A/zB6jwgIm Shn6M2fOevD2s4okZeIJHk22ng+Ys4WMfbrOMdlIUbZazQz0iPRAgLzACg8qp/L1zaUr aP6boQkEcM9W5EMHKCoBadeqYbdaRSTDcGiPsIUB8QrZLUOHOpCi+e8IRqux+HaVsBHV WiJ0qNXcWxdphm/TzJmCLU0MkYDm2B8RlOo7GIo0EmgeZDSLpaWtlT0FyJmEMcOEFDq2 tcOeHmOnCS7rbk6oFdGYyhfUfbtHqiJcvqoLrGKamNWKTSGsBxUbMPGAWTisfpLH3C1n nMEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3qf1v8XfKe7gYIU+E3Cmxutne3hLPfdAS6lS+1noQvg=; b=JzhVr9pq/ilLc7WUIcBAizeoog1Vts8lSJowhNklCggOU3GQPrvM89JZvGp211ehcJ epJ+RYEGvOKABe4PhU9izaVB6W0utg6/jNs+F/4TT1aUOyi4+0rIr4mpOIHw6+EKW5+V nasxRiCH4HHO/05Kr/JjfX3rTlNmTPUZ94agEsdbdBa5NNCGfoPfYMXsJ8zzg+AruzBz wyyjSz3eoWnOyja1tLv8aDDkgNLqYO1xOOCAdrox7JFQkiH2OvFikExcT45pTfHZqvNL rIlCgKRQCKch97nofljWGEuBGblYtS6swdwLSObt2atIcV1EFc+X4qe2yCrPYNfO/u+l t6Bg== X-Gm-Message-State: ABUngvedSgrZD3iwWBq+x0k2TdQN834x6D2EnX7IeiQP779/EzIXJWIlQLjFyKk/2MCmsw== X-Received: by 10.194.16.161 with SMTP id h1mr10951194wjd.164.1477301646916; Mon, 24 Oct 2016 02:34:06 -0700 (PDT) Received: from [192.168.2.104] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id o1sm18334272wjh.9.2016.10.24.02.34.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Oct 2016 02:34:05 -0700 (PDT) To: Loa Andersson , "mpls@ietf.org" References: From: Stewart Bryant Message-ID: <4d64aaea-9d3d-e391-24c7-b294fed95716@gmail.com> Date: Mon, 24 Oct 2016 10:34:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mpls-flow-ident@ietf.org, "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-flow-ident X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 09:34:10 -0000 There is IPR on the SL work which follows on from this (already declared against those documents). This text calls up draft-tempia-ippm-p3m-03 which has IPR, whether it needs to be formally declared I leave to the chairs to decide. I know of no other IPR that relates directly to this document. Stewart On 22/10/2016 05:33, Loa Andersson wrote: > Working Group, > > We are currently preparing draft-ietf-mpls-flow-ident-02 for working > group last call. We will do an IPR poll prior to the wglc. > > This is to start the IPR Poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-flow-ident? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > There is no IPR disclosure filed directly against this documents. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > /Loa > mpls wg co-chair > From nobody Mon Oct 24 04:44:33 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9DC12969F; Mon, 24 Oct 2016 04:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.033 X-Spam-Level: X-Spam-Status: No, score=-3.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1p97PbU_h25; Mon, 24 Oct 2016 04:44:29 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C5112969A; Mon, 24 Oct 2016 04:44:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9014310168F; Mon, 24 Oct 2016 13:44:27 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE78ry1gPWLm; Mon, 24 Oct 2016 13:44:27 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 70ADB1015D4; Mon, 24 Oct 2016 13:44:17 +0200 (CEST) Received: from HYDRA.office.hd ([169.254.4.39]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0319.002; Mon, 24 Oct 2016 13:44:17 +0200 From: Rolf Winter To: Loa Andersson , "BRUNGARD, DEBORAH A" , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements Thread-Index: AQHSEZj7spx1qqSFskizzMzQwxEY9qCbDRGAgABZJvCAACpRgIAVn4yggAKl+QCAA95scA== Date: Mon, 24 Oct 2016 11:44:16 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295DAF1352E4@Hydra.office.hd> References: <06102f2d-8f1d-aac6-9d34-10a27d600bf8@pi.nu> <791AD3077F94194BB2BDD13565B6295DAF1196AD@PALLENE.office.hd> <791AD3077F94194BB2BDD13565B6295DAF12C76F@Hydra.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 11:44:31 -0000 Loa, I guess we can postpone that question until we actually publish this. Best, Rolf -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Samstag, 22. Oktober 2016 04:39 To: Rolf Winter; BRUNGARD, DEBORAH A; mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and-requirements@= ietf.org Subject: Re: working group last call on draft-ietf-mpls-tp-mfp-use-case-and= -requirements Rolf, et.al., Yes that might be the only route open to us, but as you said early we will = lose requirement trceability and I don't like that. Does anyone have an ide= a how to fix that? /Loa On 2016-10-20 16:13, Rolf Winter wrote: > Hi, > > FWIW, to me personally, what Deborah suggests seems the most sensible way= forward. > > Best, > > Rolf > > -----Original Message----- > From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] > Sent: Donnerstag, 6. Oktober 2016 18:00 > To: Rolf Winter; Loa Andersson; mpls@ietf.org > Cc: mpls-chairs@ietf.org;=20 > draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org > Subject: RE: working group last call on=20 > draft-ietf-mpls-tp-mfp-use-case-and-requirements > > Hi, > > I agree with Loa on this is not an update of RFC5654. RFC5654 is a docume= nt reflecting ITU-T requirements for MPLS-TP. This draft is not a result of= a request by ITU-T. > > The document is building on RFC6372, but it doesn't necessarily "update" = RFC6372. RFC6372 covers a wide range of mechanisms. An implementer of RFC63= 72 does not have to also implement this document unless they want to suppor= t this extra capability. So this capability is not required for any of thos= e existing requirements, it's only needed if one wants this capability, so = the requirements can stand on their own. Note, RFC6372 did not update RFC56= 54. > > I'm recommending to hold this document in the WG until a solution documen= t is initiated. By doing a solution document, it will help determine if the= se requirements and the resulting solution are an update for any of the exi= sting solution documents. > > As the document only has two requirements, it can be part of an appendix = to a solution document. PCE recently did such a document: > https://www.ietf.org/id/draft-ietf-pce-pcep-service-aware-13.txt > > Of more concern, I've not seen any mailing list discussion on this docume= nt or any solution document proposed indicating interest by the WG, I stron= gly encourage the list be used as progress a solution document. Working in = parallel on requirements and a solution is always the best approach. Requir= ements documents do not need to be published as RFCs, especially these very= short type of documents. The IETF Chair summarized this in his May blog on= the IESG retreat: > https://www.ietf.org/blog/2016/05/ > > Thanks, > Deborah > >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Rolf Winter >> Sent: Thursday, October 06, 2016 7:37 AM >> To: Loa Andersson ; mpls@ietf.org >> Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and- >> requirements@ietf.org >> Subject: Re: [mpls] working group last call on >> draft-ietf-mpls-tp-mfp-use-case- and-requirements >> >> Hi, >> >> please see inline. >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Donnerstag, 6. Oktober 2016 10:09 >> To: mpls@ietf.org >> Cc: mpls-chairs@ietf.org; draft-ietf-mpls-tp-mfp-use-case-and- >> requirements@ietf.org >> Subject: Re: working group last call on >> draft-ietf-mpls-tp-mfp-use-case-and- >> requirements >> >> Working Group, authors, >> >> We are past the closing date for this wglc. I'm reluctant to close the l= ast call. >> The reason is that I received some comments off-line that I'd like to=20 >> hear feed back on. >> >> 1. Existing solution mechanism(s) >> ------------------------------ >> It is said that even though we have no existing implementations of >> m:n, there are existing solutions mechanisms that meet the >> requirements. >> I would like to have this verified if possible. >> >> 2. Not an update of 5654 >> --------------------- >> This is probably correct, this document adds two new requirements, >> but does in no way change RFC 5654. >> >> --- RW >> This is the text concerning updates of RFC in RFC2223 (it has=20 >> recently been obsoleted by RFC 7322, but text regarding the reasoning=20 >> behind updates has basically vanished there as far as I can tell): >> >> Updates >> >> To be used as a reference from a new item that cannot be used >> alone (i.e., one that supplements a previous document), to refer >> to the previous document. The newer publication is a part that >> will supplement or be added on to the existing document; e.g., an >> addendum, or separate, extra information that is to be added to >> the original document. >> >> I think this makes this document an update as it contains an addendum=20 >> essentially. Or the other way round, if you read 5654, there is no=20 >> way the reader can tell there are more requirements. An update will make= that clear. >> --- >> >> 3. Document structure >> ------------------ >> IESG members has recently expressed opinions that we should not >> publish small stand alone document with a small number of use cases >> or requirements, thes should rather be kept with the working and >> published as appendices to the solutions document. >> I would like to hear comments on this. >> >> --- RW >> I can understand this and usually I would agree. But then, given the=20 >> above that solution document would need to update RFC5654 and that=20 >> would be strange, having a solution document update a requirements=20 >> document. It would mix two things I believe should be separate. You=20 >> unfortunately cannot restrict an update of an RFC to a section of a diff= erent RFC. >> >> --- >> >> 4. The document need to be liaised to ITU-T SG15 >> --------------------------------------------- >> I agree with this, normally we liaise wg consensus texts, and the >> document could be liaised when the wglc closes. >> >> --- RW >> >> Yes, that should be done. >> >> Best, >> >> Rolf >> >> --- >> >> To hear the feedback on this I will keep the wglc open for another=20 >> week starting today. >> >> /Loa >> mpls wg co-chair >> >> On 18/09/2016 18:39, Loa Andersson wrote: >>> Working Group, >>> >>> This is to initiate a two week working group last call on=20 >>> draft-ietf-mpls-tp-mfp-use-case-and-requirements-02. >>> >>> Please send your comments to the mpls wg mailing list (mpls@ietf.org). >>> >>> There were no IPR disclosures against this document. >>> >>> All the authors and contributors have stated on the working group=20 >>> mailing list that they are not aware of any IPRs that relates to=20 >>> this document. >>> >>> This working group last call ends Oct 2, 2016. >>> >>> >>> /Loa >>> for the MPLS wg chairs >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Oct 24 08:34:54 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBC5129884; Mon, 24 Oct 2016 08:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNJwRE0nTClY; Mon, 24 Oct 2016 08:34:46 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 9D8FC12988A; Mon, 24 Oct 2016 08:34:46 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id y2so45159444oie.0; Mon, 24 Oct 2016 08:34:46 -0700 (PDT) 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; bh=aljDkdxNiPBv54QzbN6wcF6cstZxpl1ZCd8bB9rSiqk=; b=IJIr6zwIXWuVMwHgWRusiPK/A/NFSy2nRTujnSn2qiTWPuMHrd+hrbGtxZBNuA89GE yEOHJdLDoBDAJPQV/Y78TXAjKVxJM79f6T6aZ7fvbZUIW+kMU3UyMKkRzveaMXxSoT8A vRmL5WNj0yk2N8bLRqN3w159BNIvM8NI8GUqHt4+gY9t+vwo+h9I3NjWV6UgXCk/Ll1n aa6rCJtutoAb6cFTfaSQ4p/nLgeFVyUFnLzOcFYkV8H3W5DwxQRy5fy6HtEQL9GO50P+ 8TOnYv7rSjn4PMOlDXm335lxa97g2RTTKJJs3baNdx5Rud3CDD1RvvhxdbuxOzhrXwXM CLhQ== 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; bh=aljDkdxNiPBv54QzbN6wcF6cstZxpl1ZCd8bB9rSiqk=; b=MKpeKVkNnzS8iXlUjxpBmhnlXbM3QY/z8UH467gNvq1Z0tRPgol3YaUr2G1k/p1Xq9 6s8Qb2QdAMU6d61RrvdsxJLiIIoYExMwZSy2lkrexJ5nlolsnLghdEaaKRBg/x0jDiBA tqaKStj7hrxepZITnUm30UfenGOAl2ngZKSxMwkw8rn6gV936R+4PUzJ2uO3lAbPfDqH PwjqXQ2ZVr8gIpDfpOmtf2t2yn4EIV15f+DuA1MxefSJwsB0VXcTTcEUm5qqX8b6oi9i GpOV3BZNvM2FKCCYCfzhC5ijroLd9TBWFLZzANHK60KdfibPXvlB+bfUMFITho0faUCs Itww== X-Gm-Message-State: ABUngvfNCM6iGi3EHCbatOPl+D8JDohDaVX9Y/+FG+xSCix/ZSLdNx3jD2GJRauvUAZiuRBDBQ1MrKrC78vDzw== X-Received: by 10.202.224.87 with SMTP id x84mr10147825oig.21.1477323285955; Mon, 24 Oct 2016 08:34:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.49.116 with HTTP; Mon, 24 Oct 2016 08:34:45 -0700 (PDT) In-Reply-To: <4d64aaea-9d3d-e391-24c7-b294fed95716@gmail.com> References: <4d64aaea-9d3d-e391-24c7-b294fed95716@gmail.com> From: Greg Mirsky Date: Mon, 24 Oct 2016 08:34:45 -0700 Message-ID: To: Loa Andersson , "mpls@ietf.org" , mpls-chairs@ietf.org Content-Type: multipart/alternative; boundary=001a113d3880ad8b7b053f9e21ec Archived-At: Cc: draft-ietf-mpls-flow-ident@ietf.org Subject: Re: [mpls] IPR poll on draft-ietf-mpls-flow-ident X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 15:34:51 -0000 --001a113d3880ad8b7b053f9e21ec Content-Type: text/plain; charset=UTF-8 Dear All, I'm not aware of any IPR other than mentioned by Stewart. Regards, Greg On Mon, Oct 24, 2016 at 2:34 AM, Stewart Bryant wrote: > There is IPR on the SL work which follows on from this (already declared > against those documents). > > This text calls up draft-tempia-ippm-p3m-03 which has IPR, whether it > needs to be formally declared I leave to the chairs to decide. > > I know of no other IPR that relates directly to this document. > > Stewart > > > On 22/10/2016 05:33, Loa Andersson wrote: > >> Working Group, >> >> We are currently preparing draft-ietf-mpls-flow-ident-02 for working >> group last call. We will do an IPR poll prior to the wglc. >> >> This is to start the IPR Poll. >> >> Are you aware of any IPR that applies to draft-ietf-mpls-flow-ident? >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> There is no IPR disclosure filed directly against this documents. >> >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >> document will not advance to the next stage until a response has been >> received from each author and contributor. >> >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of any >> IPR that has not yet been disclosed in conformance with IETF rules. >> >> /Loa >> mpls wg co-chair >> >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a113d3880ad8b7b053f9e21ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
I'm not aware of any IPR other than ment= ioned by Stewart.

Regards,
Greg

On Mon, Oct 24= , 2016 at 2:34 AM, Stewart Bryant <stewart.bryant@gmail.com>= wrote:
There is IPR on the SL wor= k which follows on from this (already declared against those documents).
This text calls up=C2=A0 draft-tempia-ippm-p3m-03 which has IPR, whether it= needs to be formally declared I leave to the chairs to decide.

I know of no other IPR that relates directly to this document.

Stewart


On 22/10/2016 05:33, Loa Andersson wrote:
Working Group,

We are currently preparing draft-ietf-mpls-flow-ident-02 for working
group last call. We will do an IPR poll prior to the wglc.

This is to start the IPR Poll.

Are you aware of any IPR that applies to draft-ietf-mpls-flow-ident?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

There is no IPR disclosure filed directly against this documents.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

/Loa
mpls wg co-chair


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

--001a113d3880ad8b7b053f9e21ec-- From nobody Mon Oct 24 08:43:39 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDCB1298C2; Mon, 24 Oct 2016 08:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTcXEI3CSGID; Mon, 24 Oct 2016 08:43:36 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D071298C3; Mon, 24 Oct 2016 08:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6278; q=dns/txt; s=iport; t=1477323814; x=1478533414; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EJtw3CtAogJnU15mteC768qMc/avk80l0kQ7QgeKYkc=; b=LgRbOaV7dllIvh3uWlg+N/Gpie0pZdDqeR6IZz+ijRaCwUwPFgvPISuq kb39BFw+c0oC3SfWtOYinhKAk4BmLXQUfepwXYR50scdJFo/ntzA8ciXW FdMkqy9/zJ1GVg9gy0qad1S78PjJEinUpt2QMxBzBL93FHbXjW/IcXFRc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAgC3Kw5Y/5RdJa1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBgyoBAQEBAR1YfY00nlqHS4UWggccAQqFegKBZj8UAQIBAQEBAQEBYiiEYwE?= =?us-ascii?q?BBAEBAWsGBRACAQg/ByEGCxQRAgQOBRuIHQMXDr1VDYNlAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFwWGPYF9gliCR4FSEQGDTIIvBZQ3hSg1AYx5gxmBboRtiSeIbIQ?= =?us-ascii?q?ahAABHjZeglmCKXKGIYIgAQEB?= X-IronPort-AV: E=Sophos;i="5.31,542,1473120000"; d="scan'208,217";a="337727151" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2016 15:43:33 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u9OFhX8v002916 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Oct 2016 15:43:33 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Oct 2016 11:43:32 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 24 Oct 2016 11:43:32 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-flow-ident Thread-Index: AQHSLB2APKcCvfFqXUilu+gbu5qkz6C3nlaAgABkyID//79mBQ== Date: Mon, 24 Oct 2016 15:43:32 +0000 Message-ID: <7E688250-218F-477F-955B-E1BA843140F6@cisco.com> References: <4d64aaea-9d3d-e391-24c7-b294fed95716@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_7E688250218F477F955BE1BA843140F6ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-flow-ident@ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-flow-ident X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 15:43:38 -0000 --_000_7E688250218F477F955BE1BA843140F6ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ditto. I know of no IPR applicable directly to this document. I know there is disc= losed IPR against solutions. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Oct 24, 2016, at 08:34, Greg Mirsky > wrote: Dear All, I'm not aware of any IPR other than mentioned by Stewart. Regards, Greg On Mon, Oct 24, 2016 at 2:34 AM, Stewart Bryant > wrote: There is IPR on the SL work which follows on from this (already declared ag= ainst those documents). This text calls up draft-tempia-ippm-p3m-03 which has IPR, whether it need= s to be formally declared I leave to the chairs to decide. I know of no other IPR that relates directly to this document. Stewart On 22/10/2016 05:33, Loa Andersson wrote: Working Group, We are currently preparing draft-ietf-mpls-flow-ident-02 for working group last call. We will do an IPR poll prior to the wglc. This is to start the IPR Poll. Are you aware of any IPR that applies to draft-ietf-mpls-flow-ident? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There is no IPR disclosure filed directly against this documents. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. /Loa mpls wg co-chair _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_7E688250218F477F955BE1BA843140F6ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ditto.

I know of no IPR applicable directly to this= document. I know there is disclosed IPR against solutions. 

Excuze typofraphicak errows

On Oct 24, 2016, at 08:34, Greg Mirsky <gregimirsky@gmail.com> wrote:

Dear All,
I'm not aware of any IPR other than mentioned by Stewart.

Regards,
Greg

On Mon, Oct 24, 2016 at 2:34 AM, Stewart Bryant = <stewart.b= ryant@gmail.com> wrote:
There is IPR on the SL work which follows on from this (already declared ag= ainst those documents).

This text calls up  draft-tempia-ippm-p3m-03 which has IPR, whether it= needs to be formally declared I leave to the chairs to decide.

I know of no other IPR that relates directly to this document.

Stewart


On 22/10/2016 05:33, Loa Andersson wrote:
Working Group,

We are currently preparing draft-ietf-mpls-flow-ident-02 for working
group last call. We will do an IPR poll prior to the wglc.

This is to start the IPR Poll.

Are you aware of any IPR that applies to draft-ietf-mpls-flow-ident?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

There is no IPR disclosure filed directly against this documents.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

/Loa
mpls wg co-chair
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--_000_7E688250218F477F955BE1BA843140F6ciscocom_-- From nobody Mon Oct 24 19:40:46 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03C1129455; Mon, 24 Oct 2016 19:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNOiZrnukYhm; Mon, 24 Oct 2016 19:40:43 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B221293DF; Mon, 24 Oct 2016 19:40:42 -0700 (PDT) Received: from [192.168.1.8] (unknown [49.146.50.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9387318013BE; Tue, 25 Oct 2016 04:40:39 +0200 (CEST) To: "mpls@ietf.org" From: Loa Andersson Message-ID: Date: Tue, 25 Oct 2016 10:40:32 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-ietf-mpls-tp-mfp-use-case-and-requirements@ietf.org" Subject: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 02:40:45 -0000 Working Group, Even though there is a (albeit tepid) wg consensus to request publication for this draft, we cannot proceed at this time. Our AD and the IESG recommend working in parallel with requirements and solutions. The fact is that have been no drafts on solutions. Once there is reasonable progress on a solutions document we can proceed. We will therefore keep draft-ietf-mpls-tp-mfp-use-case-and-requirements alive while waiting for a solutions document to mature, and then revisit the decision to publish this document or include some or all of the information in it in the solutions document. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Oct 25 00:36:05 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DA6129ACF; Tue, 25 Oct 2016 00:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT2I6ejRgg8G; Tue, 25 Oct 2016 00:36:01 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 6F3141294D1; Tue, 25 Oct 2016 00:36:01 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id c78so7235727wme.0; Tue, 25 Oct 2016 00:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=RJ+vWSIYfdFYWkyEZXNnYPmdlrwh1T03l44iouh+xDI=; b=rP5mqQOn+XK3o/zJqMqE9QYkwi1OoG1BCYQuZ58oWFReSBcrouO8MrAPDiUSycZO6s lsz9vca9e0q4SEBcAJWKFklMUKj2rU67NtZ+w9TWwOPD98A6UznEmrSKyLiESeDqdELQ runzd1dLE1SPQxooL+kSFosi5MZ1HDSdtUd9RrdUGWmFS639SKtzYnapn5EqR0vaWi5c NuqgkYJ1qoHMNCTl2KL4oJ9+MjO770zr+pk6EgKBpUSRdCUYA79nqJkimEcdGIBtyyXQ vmZpZqMu9bq3+fvoNPlRW88yXz8RSsMdU9BInuBRMZP0B8tNUN8lCuxVnhNiLl0ttps5 Ivyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RJ+vWSIYfdFYWkyEZXNnYPmdlrwh1T03l44iouh+xDI=; b=l91SnZsXo5b9WQ+8DlGmJkAhQOOP4v46DWkAgKBI5IPgU2ZW3xzKgQavEQWvNQXzVS Xhdm12fiZ6xwjRydYME9w9myrWhq4Mv9WC5uPM0n+gyV9KYpsZxSYqCL0EdoTghuogMt 9Cf2FxCGPJHxHlBtP/4w5FxquvI1A/Fa3FP751FTCpTH4l3Bld76QXpcPW3wSkh+yXLn xPaK7fJso7ZDGZUgQ2kY6E/lrvNXmUsCISfWBV620urfknk/5LGMa2fqO/RTgrSP0TCr LfVxxEnxlK733L+cMRo+3zeSxU8zvApGhWOmUgI1+8JhCw5NFOzwi5vqaWv1svuZ1XEa tUig== X-Gm-Message-State: ABUngveFUlEV6aox2XsDJ5JiGzL4b9Fb71zpXZojQW/ilNcoMMXaAH/khZUZcgZGGEUS5w== X-Received: by 10.28.93.137 with SMTP id r131mr1581621wmb.2.1477380959759; Tue, 25 Oct 2016 00:35:59 -0700 (PDT) Received: from [192.168.2.104] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id pe5sm23501699wjb.15.2016.10.25.00.35.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Oct 2016 00:35:58 -0700 (PDT) To: mpls@ietf.org, "" References: From: Stewart Bryant Message-ID: Date: Tue, 25 Oct 2016 08:35:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 07:36:04 -0000 On 25/10/2016 03:40, Loa Andersson wrote: > Working Group, > > > Our AD and the IESG recommend working in parallel with requirements > and solutions. The fact is that have been no drafts on solutions. > Once there is reasonable progress on a solutions document we can > proceed. This change of policy by the IESG is something that I think needs wider discussion. Sometimes this is right, but other times it is useful to establish the requirements in the absence of a decision on the solution to harden the foundations of the project. It is not uncommon for people to game the requirements to give the edge to their preferred solution. In these circumstances, taking an objective look at the requirements and freezing them through publication can help. Also in some cases there may be a matter of IESG policy that needs to be frozen before important decisions in the solution can be made. Now I am not sure that this applies to this specific case, but I am worried about this new IESG policy preventing WGs approaching their problems in the manner that best suits each problem. Perhaps a discussion for the open meeting? Stewart From nobody Tue Oct 25 05:37:53 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B798A129504; Tue, 25 Oct 2016 05:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.033 X-Spam-Level: X-Spam-Status: No, score=-3.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYV_J8YDQaQo; Tue, 25 Oct 2016 05:37:48 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517D11293E1; Tue, 25 Oct 2016 05:37:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 872F8101750; Tue, 25 Oct 2016 14:37:46 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkR4Dhy-9Vhr; Tue, 25 Oct 2016 14:37:46 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 69680101749; Tue, 25 Oct 2016 14:37:40 +0200 (CEST) Received: from HYDRA.office.hd ([169.254.4.39]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0319.002; Tue, 25 Oct 2016 14:37:40 +0200 From: Rolf Winter To: Stewart Bryant , "mpls@ietf.org" , "" Thread-Topic: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed Thread-Index: AQHSLmkycgEX27v0tkyGCGlK9PFxP6C4pn+AgABykOA= Date: Tue, 25 Oct 2016 12:37:39 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295DAF13566B@Hydra.office.hd> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.203] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 12:37:53 -0000 Hi Stewart, I don't think the IESG has made a strict policy in this regard. Below is th= e blog post extract that talks about this. I read it as a recommendation to= focus on protocol work and not let requirements work stall important proto= col specifications and as a clarification that there is no actual need to g= o through a problem definition/use cases/requirements stage before protocol= work can start. But, as the text states, there is no one-size-fits-all app= roach. Not sure this is actually controversial and needs further discussion= . "We also discussed the role of requirement, use case, and problem definitio= n documents in IETF work. There is no one-size-fits-all approach to differe= nt working groups. But the IESG wanted to be clear that the essence of IETF= work and the energy often comes from working on protocol solutions. We wer= e concerned about cases where it takes a long time to get to that work. Wor= king groups should NOT feel they need to sequence their work in waterfall s= tyle. In fact, working in parallel with solutions and other supporting docu= ments (and code!) is often the best approach. And some of the supporting do= cuments need not necessarily always be RFCs; wikis, for instance, are a fin= e approach as well." From: https://www.ietf.org/blog/2016/05/=20 Best, Rolf -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Dienstag, 25. Oktober 2016 09:36 To: mpls@ietf.org; Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-r= equirements - Working Group Last Call closed On 25/10/2016 03:40, Loa Andersson wrote: > Working Group, > > > Our AD and the IESG recommend working in parallel with requirements=20 > and solutions. The fact is that have been no drafts on solutions. > Once there is reasonable progress on a solutions document we can=20 > proceed. This change of policy by the IESG is something that I think needs wider dis= cussion. Sometimes this is right, but other times it is useful to establish the requ= irements in the absence of a decision on the solution to harden the foundat= ions of the project. It is not uncommon for people to game the requirements to give the edge to = their preferred solution. In these circumstances, taking an objective look = at the requirements and freezing them through publication can help. Also in some cases there may be a matter of IESG policy that needs to be fr= ozen before important decisions in the solution can be made. Now I am not sure that this applies to this specific case, but I am worried= about this new IESG policy preventing WGs approaching their problems in th= e manner that best suits each problem. Perhaps a discussion for the open meeting? Stewart _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 25 06:28:16 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4A712950F; Tue, 25 Oct 2016 06:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8b6zdYX0zpb; Tue, 25 Oct 2016 06:28:10 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 BD1241294FE; Tue, 25 Oct 2016 06:28:09 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id d128so27558309wmf.1; Tue, 25 Oct 2016 06:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=5oIs4h6NY3jy56ZmGkF2XojcU9nJNdz1QqLUH+jYzYM=; b=Skd5XwZpFL2Os5UL7P0iD/kUst3p9Lm3h+23EzpiatrTrv8ZzM1ahIUtXK8FLGOyEL cCDKuU/yvo8L/A21cJ9smfp1MCCYWy8nuhkrmN0tQUY8N4JylrLHfIloiYMEI9sf2Zs7 Mu4OT2lZsuPP4yL3/flS6p2U49G1DUtb5Gb2lz7kh8ZvbRUUvktB/EH/mZ3MQv1REzr5 7s4TMmfp6gzlaP6RpHtcHnXn05VbsU+9NeiMgVm7x+aNeJWF0Ck7lXPGcfwLsQBbxOS/ Vj8dzhyd2jCL7B8RuIowb3d/7VdM0Osi82fml0kgFGGzOZ9phIV1XfCY4BZlbgzH+6Ci t4Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5oIs4h6NY3jy56ZmGkF2XojcU9nJNdz1QqLUH+jYzYM=; b=cenu75S810xtBAI/AJ4oMhekMu6s3VOhiVf9cTVDeDLR92567iRfMCzHyJ/kmMNgka hHZTDcUjSyHC3X2kERaxfSddFpoE+KMZh43sqCWiTjUCXsoiTQg3eGfQC2ulLq+sOirB 8PmgaE2ZhAATFOWCU6OzXMSrKmJ+SqHXQqlQYqxYme5YvW+6JegmSnD6gesQckMEDwf+ Os/g+l8w+D9lGfqo1OO0GNJsCnczMjWMuDLj7PVc4NiPeDjYVsxjzmk2T7dAX0qgz8Ws 1qKmSADTiTDWaugLex/JwL/ge5ukgR84vRmiG9Ye8jvK/ApXBVsglc3HOcGXSk04GqcH a0WQ== X-Gm-Message-State: ABUngvfAUN5KRJxM6N6+e2kRUeaRR8Y/ZpMrd9BMgpygL+EFcbGCEcKlfgGsbnmFrIyIYA== X-Received: by 10.28.150.20 with SMTP id y20mr3117458wmd.67.1477402088275; Tue, 25 Oct 2016 06:28:08 -0700 (PDT) Received: from [192.168.2.104] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id x138sm3700770wme.14.2016.10.25.06.28.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Oct 2016 06:28:07 -0700 (PDT) To: Rolf Winter , "mpls@ietf.org" , "" References: <791AD3077F94194BB2BDD13565B6295DAF13566B@Hydra.office.hd> From: Stewart Bryant Message-ID: <2c104f51-ddd1-6dde-7628-a14b6bb54a02@gmail.com> Date: Tue, 25 Oct 2016 14:28:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <791AD3077F94194BB2BDD13565B6295DAF13566B@Hydra.office.hd> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 13:28:14 -0000 Hi Rolf It needs further discussion if chairs have drafts rejected out of policy rather than on a case by case basis. My understanding of Loa's comment is that policy is the high order bit. Maybe the RTG ADs can provide some guidelines? Stewart On 25/10/2016 13:37, Rolf Winter wrote: > Hi Stewart, > > I don't think the IESG has made a strict policy in this regard. Below is the blog post extract that talks about this. I read it as a recommendation to focus on protocol work and not let requirements work stall important protocol specifications and as a clarification that there is no actual need to go through a problem definition/use cases/requirements stage before protocol work can start. But, as the text states, there is no one-size-fits-all approach. Not sure this is actually controversial and needs further discussion. > > > "We also discussed the role of requirement, use case, and problem definition documents in IETF work. There is no one-size-fits-all approach to different working groups. But the IESG wanted to be clear that the essence of IETF work and the energy often comes from working on protocol solutions. We were concerned about cases where it takes a long time to get to that work. Working groups should NOT feel they need to sequence their work in waterfall style. In fact, working in parallel with solutions and other supporting documents (and code!) is often the best approach. And some of the supporting documents need not necessarily always be RFCs; wikis, for instance, are a fine approach as well." > > From: https://www.ietf.org/blog/2016/05/ > > Best, > > Rolf > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Dienstag, 25. Oktober 2016 09:36 > To: mpls@ietf.org; > Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed > > > > On 25/10/2016 03:40, Loa Andersson wrote: >> Working Group, >> >> >> Our AD and the IESG recommend working in parallel with requirements >> and solutions. The fact is that have been no drafts on solutions. >> Once there is reasonable progress on a solutions document we can >> proceed. > This change of policy by the IESG is something that I think needs wider discussion. > > Sometimes this is right, but other times it is useful to establish the requirements in the absence of a decision on the solution to harden the foundations of the project. > > It is not uncommon for people to game the requirements to give the edge to their preferred solution. In these circumstances, taking an objective look at the requirements and freezing them through publication can help. > Also in some cases there may be a matter of IESG policy that needs to be frozen before important decisions in the solution can be made. > > Now I am not sure that this applies to this specific case, but I am worried about this new IESG policy preventing WGs approaching their problems in the manner that best suits each problem. > > Perhaps a discussion for the open meeting? > > Stewart > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 25 10:17:29 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E3712956E; Tue, 25 Oct 2016 10:17:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147741584535.1460.12946112077402152362.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2016 10:17:25 -0700 Archived-At: Cc: draft-ietf-mpls-rfc4379bis@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org Subject: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-rfc4379bis-07: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 17:17:25 -0000 Ben Campbell has entered the following ballot position for draft-ietf-mpls-rfc4379bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There are comments in the gen-art review that I think need to be considered: https://mailarchive.ietf.org/arch/msg/gen-art/NCnpeM8V5bWmrw_eLEuiT0FPP_E From nobody Tue Oct 25 11:17:12 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D51531295FD; Tue, 25 Oct 2016 11:17:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147741942986.1480.9692706368109608681.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2016 11:17:09 -0700 Archived-At: Cc: draft-ietf-mpls-rfc4379bis@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org Subject: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-rfc4379bis-07=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 18:17:10 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mpls-rfc4379bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few not very important comments: 1) To me it seems a bit unfortunate that this draft points to rfc6425 and rfc6426 for the definition of the T and R flags, given the goal was to have all specifications in one doc. Not sure if that can or should be fixed. Just wanted to mention it. 2) I would expect that the security section recommends border filtering of MPLS ping message, given that these are usually used within one domain, no? 3) I know this is a bis doc but I'm still wondering why this TTL trick is used here. For ICMP that was a way that utilizes the existing specification and implementation to get further information. However here, you could just have used a flag in the header either saying 'only forward to the end' or 'reply and still forward', or something like this, to cover the two modes. This would also allow to just send one packet to the end instead of sending one for each hop. Is there a rational for copying this ICMP hack? From nobody Tue Oct 25 15:18:33 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45381295FF; Tue, 25 Oct 2016 15:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bzrgdqyS8Lr; Tue, 25 Oct 2016 15:18:30 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006881295F9; Tue, 25 Oct 2016 15:18:29 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u9PMHSds020739; Tue, 25 Oct 2016 18:18:28 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 26ag2d81as-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Oct 2016 18:18:25 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9PMINjX008806; Tue, 25 Oct 2016 18:18:25 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9PMICDt008230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Oct 2016 18:18:19 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 25 Oct 2016 22:17:57 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.170]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0319.002; Tue, 25 Oct 2016 18:17:57 -0400 From: "BRUNGARD, DEBORAH A" To: Stewart Bryant , Rolf Winter , "mpls@ietf.org" , "" Thread-Topic: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed Thread-Index: AQHSLmk0GsGUNpKU8kehc5nLPi19BqC5CxWAgABUS4CAAA4XgIAATuLg Date: Tue, 25 Oct 2016 22:17:56 +0000 Message-ID: References: <791AD3077F94194BB2BDD13565B6295DAF13566B@Hydra.office.hd> <2c104f51-ddd1-6dde-7628-a14b6bb54a02@gmail.com> In-Reply-To: <2c104f51-ddd1-6dde-7628-a14b6bb54a02@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.192.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-25_21:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610250364 Archived-At: Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 22:18:32 -0000 Hi Stewart, You may have missed the earlier mails and discussion on this thread. Rolf h= as summarized accurately that Loa's mail is referring to this draft and not= to a policy change. Thanks, Deborah > -----Original Message----- > From: Stewart Bryant [mailto:stewart.bryant@gmail.com] > Sent: Tuesday, October 25, 2016 9:28 AM > To: Rolf Winter ; mpls@ietf.org; > > Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and= - > requirements - Working Group Last Call closed >=20 > Hi Rolf >=20 > It needs further discussion if chairs have drafts rejected out of policy > rather than on a case by case basis. >=20 > My understanding of Loa's comment is that policy is the high order bit. >=20 > Maybe the RTG ADs can provide some guidelines? >=20 > Stewart >=20 >=20 > On 25/10/2016 13:37, Rolf Winter wrote: > > Hi Stewart, > > > > I don't think the IESG has made a strict policy in this regard. Below i= s the > blog post extract that talks about this. I read it as a recommendation to= focus > on protocol work and not let requirements work stall important protocol > specifications and as a clarification that there is no actual need to go = through > a problem definition/use cases/requirements stage before protocol work ca= n > start. But, as the text states, there is no one-size-fits-all approach. N= ot sure > this is actually controversial and needs further discussion. > > > > > > "We also discussed the role of requirement, use case, and problem > definition documents in IETF work. There is no one-size-fits-all approach= to > different working groups. But the IESG wanted to be clear that the essenc= e of > IETF work and the energy often comes from working on protocol solutions. > We were concerned about cases where it takes a long time to get to that > work. Working groups should NOT feel they need to sequence their work in > waterfall style. In fact, working in parallel with solutions and other su= pporting > documents (and code!) is often the best approach. And some of the > supporting documents need not necessarily always be RFCs; wikis, for > instance, are a fine approach as well." > > > > From: https://www.ietf.org/blog/2016/05/ > > > > Best, > > > > Rolf > > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > > Sent: Dienstag, 25. Oktober 2016 09:36 > > To: mpls@ietf.org; > > Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-a= nd- > requirements - Working Group Last Call closed > > > > > > > > On 25/10/2016 03:40, Loa Andersson wrote: > >> Working Group, > >> > >> > >> Our AD and the IESG recommend working in parallel with requirements > >> and solutions. The fact is that have been no drafts on solutions. > >> Once there is reasonable progress on a solutions document we can > >> proceed. > > This change of policy by the IESG is something that I think needs wider > discussion. > > > > Sometimes this is right, but other times it is useful to establish the > requirements in the absence of a decision on the solution to harden the > foundations of the project. > > > > It is not uncommon for people to game the requirements to give the edge= to > their preferred solution. In these circumstances, taking an objective loo= k at > the requirements and freezing them through publication can help. > > Also in some cases there may be a matter of IESG policy that needs to b= e > frozen before important decisions in the solution can be made. > > > > Now I am not sure that this applies to this specific case, but I am wor= ried > about this new IESG policy preventing WGs approaching their problems in t= he > manner that best suits each problem. > > > > Perhaps a discussion for the open meeting? > > > > Stewart > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Oct 25 20:10:59 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C4D12940C; Tue, 25 Oct 2016 20:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POIqGWK8dOxB; Tue, 25 Oct 2016 20:10:55 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A98127071; Tue, 25 Oct 2016 20:10:55 -0700 (PDT) Received: from [192.168.1.8] (unknown [49.146.50.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 090B81802AB1; Wed, 26 Oct 2016 05:10:50 +0200 (CEST) To: "BRUNGARD, DEBORAH A" , Stewart Bryant , Rolf Winter , "mpls@ietf.org" , "" References: <791AD3077F94194BB2BDD13565B6295DAF13566B@Hydra.office.hd> <2c104f51-ddd1-6dde-7628-a14b6bb54a02@gmail.com> From: Loa Andersson Message-ID: <5a67f818-bb6f-d562-b432-11374a8757e2@pi.nu> Date: Wed, 26 Oct 2016 11:10:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 03:10:58 -0000 Deborah, with all due respect and without getting into "he said, she said, he said. ... " debate, but I find what you say here not fully accurate. I find myself quoted in such a way that inply that I without reservations support the change in document procedures that I seen developing over a little more than a year. In fact I have very strong reservations. First, mail mail say that we can not proceed at this time, and then point to the change in procedure that stops us. The earlier procedure were captured in RFC 4929 "Whenever any extension or change to the (G)MPLS protocols is desired, a problem statement and/or requirements statement must be produced and must be submitted to IETF as an Internet-Draft." The draft under discussion is a perfect example of this. The RFC goes on and says that the IETF will evaluate the requirments, praxis has been that the requirements has been published. The earlier procedure hasa served us well. Only that in this case we fail because the IESG has changed the the procedure to "work in parallel". I think that two years ago (to be on the safe side) there would have been no problem publishing the ID as an RFC, at lest not for the reasons that stop it now. It surprises me that we don't accept what Jari said in his report from the IESG retreat - "one size does not fit all". That said I don't exclude that we will tweak the model to be more iterative, but: - first, we should not change in mid-process - second, agreement on requirements, will always precede agreement on architecture, frameworks, solutions and operational models. The time span needed for "predede" is a matter of case by case. I think that the ue of the word "parallel" is misleading, I guess what we are looking for is "iterative", i.e. an early step does not have to be fully completed before the next step is started, the latter step should be allowed to have an impact on the earlier. It should also be noted that we have players within the industry that communicate with us through requirements, but has no immediate intention to be involved in the solutions work. /Loa On 2016-10-26 06:17, BRUNGARD, DEBORAH A wrote: > Hi Stewart, > > You may have missed the earlier mails and discussion on this thread. Rolf has summarized accurately that Loa's mail is referring to this draft and not to a policy change. > > Thanks, > Deborah > >> -----Original Message----- >> From: Stewart Bryant [mailto:stewart.bryant@gmail.com] >> Sent: Tuesday, October 25, 2016 9:28 AM >> To: Rolf Winter ; mpls@ietf.org; >> >> Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and- >> requirements - Working Group Last Call closed >> >> Hi Rolf >> >> It needs further discussion if chairs have drafts rejected out of policy >> rather than on a case by case basis. >> >> My understanding of Loa's comment is that policy is the high order bit. >> >> Maybe the RTG ADs can provide some guidelines? >> >> Stewart >> >> >> On 25/10/2016 13:37, Rolf Winter wrote: >>> Hi Stewart, >>> >>> I don't think the IESG has made a strict policy in this regard. Below is the >> blog post extract that talks about this. I read it as a recommendation to focus >> on protocol work and not let requirements work stall important protocol >> specifications and as a clarification that there is no actual need to go through >> a problem definition/use cases/requirements stage before protocol work can >> start. But, as the text states, there is no one-size-fits-all approach. Not sure >> this is actually controversial and needs further discussion. >>> >>> >>> "We also discussed the role of requirement, use case, and problem >> definition documents in IETF work. There is no one-size-fits-all approach to >> different working groups. But the IESG wanted to be clear that the essence of >> IETF work and the energy often comes from working on protocol solutions. >> We were concerned about cases where it takes a long time to get to that >> work. Working groups should NOT feel they need to sequence their work in >> waterfall style. In fact, working in parallel with solutions and other supporting >> documents (and code!) is often the best approach. And some of the >> supporting documents need not necessarily always be RFCs; wikis, for >> instance, are a fine approach as well." >>> >>> From: https://www.ietf.org/blog/2016/05/ >>> >>> Best, >>> >>> Rolf >>> >>> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant >>> Sent: Dienstag, 25. Oktober 2016 09:36 >>> To: mpls@ietf.org; >>> Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and- >> requirements - Working Group Last Call closed >>> >>> >>> >>> On 25/10/2016 03:40, Loa Andersson wrote: >>>> Working Group, >>>> >>>> >>>> Our AD and the IESG recommend working in parallel with requirements >>>> and solutions. The fact is that have been no drafts on solutions. >>>> Once there is reasonable progress on a solutions document we can >>>> proceed. >>> This change of policy by the IESG is something that I think needs wider >> discussion. >>> >>> Sometimes this is right, but other times it is useful to establish the >> requirements in the absence of a decision on the solution to harden the >> foundations of the project. >>> >>> It is not uncommon for people to game the requirements to give the edge to >> their preferred solution. In these circumstances, taking an objective look at >> the requirements and freezing them through publication can help. >>> Also in some cases there may be a matter of IESG policy that needs to be >> frozen before important decisions in the solution can be made. >>> >>> Now I am not sure that this applies to this specific case, but I am worried >> about this new IESG policy preventing WGs approaching their problems in the >> manner that best suits each problem. >>> >>> Perhaps a discussion for the open meeting? >>> >>> Stewart >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Oct 25 22:14:23 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F28212952B; Tue, 25 Oct 2016 22:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z79lkAatGum; Tue, 25 Oct 2016 22:14:20 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB24B129576; Tue, 25 Oct 2016 22:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9080; q=dns/txt; s=iport; t=1477458859; x=1478668459; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2XKg4/2dA5xK6sCyHC5rKyyLbViszJK5QIxbaA02FPg=; b=Dx6+re56QxKEPpm1u/EFVev0Qe6uI1RRiuOHHv1lRfL0Uuexn9u8LC+3 vm32+mTIDni9WLBqdvLih9J92LAAYJfYOOw2pJpcGgQxx0YIC9HVj/GvX 9bo7yvsfEU2WkCsjedggE5sTCX5QUDXcnZEIaLOjhcGvenFKodGVTIRYK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAQC7OhBY/5pdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM3AQEBAQEdWH0HjS6mJ4MHgg+CBymFeQIagVo/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGMBAQQjVhACAQg/AwICAjAUEQIEDgWIVA6zHYx1AQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBFwWGPYF9gliHSyyCLwWIRYtzhV4BhimJbpADjQiEAAEeNl6DTIE6cod?= =?us-ascii?q?dgQkBAQE?= X-IronPort-AV: E=Sophos;i="5.31,549,1473120000"; d="scan'208,217";a="338450375" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2016 05:14:18 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9Q5EISc026034 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Oct 2016 05:14:18 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Oct 2016 01:14:17 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 26 Oct 2016 01:14:18 -0400 From: "Carlos Pignataro (cpignata)" To: Ben Campbell Thread-Topic: Ben Campbell's No Objection on draft-ietf-mpls-rfc4379bis-07: (with COMMENT) Thread-Index: AQHSLuOrf81NWBytikmS/M7WvN5yIKC6dKUA Date: Wed, 26 Oct 2016 05:14:17 +0000 Message-ID: References: <147741584535.1460.12946112077402152362.idtracker@ietfa.amsl.com> In-Reply-To: <147741584535.1460.12946112077402152362.idtracker@ietfa.amsl.com> 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.24.5.58] Content-Type: multipart/alternative; boundary="_000_B56AFE9C7C4F4C8EB968DF7F0BD368BFciscocom_" MIME-Version: 1.0 Archived-At: Cc: mpls-chairs , "draft-ietf-mpls-rfc4379bis@ietf.org" , "mpls@ietf.org" , The IESG Subject: Re: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-rfc4379bis-07: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 05:14:22 -0000 --_000_B56AFE9C7C4F4C8EB968DF7F0BD368BFciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBPY3QgMjUsIDIwMTYsIGF0IDEwOjE3IEFNLCBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVt LmNvbTxtYWlsdG86YmVuQG5vc3RydW0uY29tPj4gd3JvdGU6DQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNP TU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoZXJlIGFyZSBjb21tZW50cyBpbiB0aGUgZ2VuLWFy dCByZXZpZXcgdGhhdCBJIHRoaW5rIG5lZWQgdG8gYmUNCmNvbnNpZGVyZWQ6DQoNCmh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZ2VuLWFydC9OQ25wZU04VjViV21yd19lTEV1 aVQwRlBQX0UNCg0KVGhhbmtzIEJlbiENCg0KSW5kZWVkLCB3ZSB3aWxsIGFkZHJlc3MgZXZlcnkg Y29tbWVudCBvbiB0aGF0IGV4Y2VsbGVudCBnZW4tYXJ0IHJldmlldy4NCg0KVGhhbmtzLA0KDQri gJQgQ2FybG9zLg0K --_000_B56AFE9C7C4F4C8EB968DF7F0BD368BFciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IE9jdCAyNSwgMjAxNiwgYXQgMTA6MTcgQU0sIEJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJlbkBub3N0cnVtLmNvbSIgY2xhc3M9IiI+YmVuQG5vc3RydW0uY29tPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBj bGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxh eTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5DT01NRU5UOjwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiIGNsYXNzPSIiPlRoZXJlDQogYXJlIGNvbW1lbnRzIGluIHRoZSBnZW4tYXJ0IHJl dmlldyB0aGF0IEkgdGhpbmsgbmVlZCB0byBiZTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Y29uc2lkZXJlZDo8L3NwYW4+PGJyIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2dlbi1hcnQvTkNucGVNOFY1Yldt cndfZUxFdWlUMEZQUF9FIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2dl bi1hcnQvTkNucGVNOFY1YldtcndfZUxFdWlUMEZQUF9FPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBCZW4hPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbmRl ZWQsIHdlIHdpbGwgYWRkcmVzcyBldmVyeSBjb21tZW50IG9uIHRoYXQgZXhjZWxsZW50IGdlbi1h cnQgcmV2aWV3LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCUIENhcmxvcy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_B56AFE9C7C4F4C8EB968DF7F0BD368BFciscocom_-- From nobody Tue Oct 25 22:26:59 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C62712959F; Tue, 25 Oct 2016 22:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DpXAdonY5b7; Tue, 25 Oct 2016 22:26:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609BF12957A; Tue, 25 Oct 2016 22:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10940; q=dns/txt; s=iport; t=1477459610; x=1478669210; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TaJGEefUcpA/DZWudtjeMokUtmjNX1EqbMl7+fZuW1A=; b=b8yE6PMAqzItSiHGj7AFOZ9j24b8cjxtclyCUIXOano/uwf2Qz8efO1m rlNEFrnzZ045+lUyPk1kGyvYe0gdBFiAEltjdrkuWOoWJHfeHU+WvXUH0 uNICFXMLSEXjkCGaM82M98HF6uomu1z+8JsEB8L0YkAtN/QWeQctLkKuI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AgBEPhBY/5ldJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR1YfQeNLqYnTII7gg+CByeFewIagVo/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGMBAQICI1YQAgEIDjEDAgICMBQGCwIEDgWIVA6zIox1AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFwWGPYF9gliEGREBgyAsgi8FiEWRUQGGKYlugW6EbYkojQiEAAE?= =?us-ascii?q?eNl6DGBwYgTpyAYY8gSCBCQEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,549,1473120000"; d="scan'208,217";a="340343718" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2016 05:26:35 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u9Q5QYKc030792 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Oct 2016 05:26:35 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Oct 2016 01:26:34 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 26 Oct 2016 01:26:34 -0400 From: "Carlos Pignataro (cpignata)" To: Mirja Kuehlewind Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-mpls-rfc4379bis-07:_(with_COMMENT)?= Thread-Index: AQHSLuwCUkRRcOc7F0yHrkMcXjN6t6C6eDyA Date: Wed, 26 Oct 2016 05:26:34 +0000 Message-ID: <23E7818F-7EC2-4D11-8F48-87BBE8B5FEB0@cisco.com> References: <147741942986.1480.9692706368109608681.idtracker@ietfa.amsl.com> In-Reply-To: <147741942986.1480.9692706368109608681.idtracker@ietfa.amsl.com> 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.24.5.58] Content-Type: multipart/alternative; boundary="_000_23E7818F7EC24D118F4887BBE8B5FEB0ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-ietf-mpls-rfc4379bis@ietf.org" , "mpls@ietf.org" , The IESG Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-rfc4379bis-07=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 05:26:52 -0000 --_000_23E7818F7EC24D118F4887BBE8B5FEB0ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIE1pcmphLA0KDQpUaGFua3MsIHBsZWFzZSBzZWUgaW5saW5lLg0KDQpPbiBPY3QgMjUsIDIw MTYsIGF0IDExOjE3IEFNLCBNaXJqYSBLdWVobGV3aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0PG1h aWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0Pj4gd3JvdGU6DQoNCk1pcmphIEvDvGhsZXdpbmQgaGFz IGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLW1w bHMtcmZjNDM3OWJpcy0wNzogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNl IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRk cmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0 IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZl ciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlh Lmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVO VCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBw b3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1tcGxzLXJmYzQzNzliaXMvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpD T01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpBIGZldyBub3QgdmVyeSBpbXBvcnRhbnQgY29tbWVu dHM6DQoNCjEpIFRvIG1lIGl0IHNlZW1zIGEgYml0IHVuZm9ydHVuYXRlIHRoYXQgdGhpcyBkcmFm dCBwb2ludHMgdG8gcmZjNjQyNSBhbmQNCnJmYzY0MjYgZm9yIHRoZSBkZWZpbml0aW9uIG9mIHRo ZSBUIGFuZCBSIGZsYWdzLCBnaXZlbiB0aGUgZ29hbCB3YXMgdG8NCmhhdmUgYWxsIHNwZWNpZmlj YXRpb25zIGluIG9uZSBkb2MuIE5vdCBzdXJlIGlmIHRoYXQgY2FuIG9yIHNob3VsZCBiZQ0KZml4 ZWQuIEp1c3Qgd2FudGVkIHRvIG1lbnRpb24gaXQuDQoNClRoYW5rcyBmb3IgbWVudGlvbmluZyBp dC4gVGhlIFdHIGRpZCBkaXNjdXNzIHRoaXMuIFlvdSBjYW4gc2VlIGh0dHBzOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtbXBscy0yLnBkZg0KDQpTaW5jZSA0 Mzc5YmlzIGlzIG5vdCBvYnNvbGV0aW5nIHJmYzY1MjUgYW5kIHJmYzY1MjYsIHRoZSBpZGVhIHdh cyB0byBrZWVwIHRoZSBkZWZpbml0aW9uIGluIHRob3NlIFJGQ3MsIGJ1dCBtZW50aW9uIHRoZW0g aW4gdGhlIGJpcy4NCg0KDQoyKSBJIHdvdWxkIGV4cGVjdCB0aGF0IHRoZSBzZWN1cml0eSBzZWN0 aW9uIHJlY29tbWVuZHMgYm9yZGVyIGZpbHRlcmluZw0Kb2YgTVBMUyBwaW5nIG1lc3NhZ2UsIGdp dmVuIHRoYXQgdGhlc2UgYXJlIHVzdWFsbHkgdXNlZCB3aXRoaW4gb25lDQpkb21haW4sIG5vPw0K DQoNClRoZXJlIGlzIGludGVyLWFzIGFuZCBpbnRlciBkb21haW4gbHNwIHBpbmcuDQoNCjMpIEkg a25vdyB0aGlzIGlzIGEgYmlzIGRvYyBidXQgSSdtIHN0aWxsIHdvbmRlcmluZyB3aHkgdGhpcyBU VEwgdHJpY2sgaXMNCnVzZWQgaGVyZS4gRm9yIElDTVAgdGhhdCB3YXMgYSB3YXkgdGhhdCB1dGls aXplcyB0aGUgZXhpc3RpbmcNCnNwZWNpZmljYXRpb24gYW5kIGltcGxlbWVudGF0aW9uIHRvIGdl dCBmdXJ0aGVyIGluZm9ybWF0aW9uLg0KDQpIZXJlLCB0aGUgVFRMIGV4cGlyYXRpb24gaW4gdHJh Y2Vyb3V0ZSBtb2RlIGlzIHVzZWQgdG8gaW50ZXJjZXB0IHRoZSBwYWNrZXQgYW5kIHNlbmQgaXQg dG8gdGhlIGNvbnRyb2wgcGxhbmUuIEFkZGl0aW9uYWxseSBzZWUgYmVsb3cuDQoNCkhvd2V2ZXIN CmhlcmUsIHlvdSBjb3VsZCBqdXN0IGhhdmUgdXNlZCBhIGZsYWcgaW4gdGhlIGhlYWRlciBlaXRo ZXIgc2F5aW5nICdvbmx5DQpmb3J3YXJkIHRvIHRoZSBlbmQnIG9yICdyZXBseSBhbmQgc3RpbGwg Zm9yd2FyZCcsIG9yIHNvbWV0aGluZyBsaWtlIHRoaXMsDQp0byBjb3ZlciB0aGUgdHdvIG1vZGVz LiBUaGlzIHdvdWxkIGFsc28gYWxsb3cgdG8ganVzdCBzZW5kIG9uZSBwYWNrZXQgdG8NCnRoZSBl bmQgaW5zdGVhZCBvZiBzZW5kaW5nIG9uZSBmb3IgZWFjaCBob3AuDQoNClRoYXTigJlzIGEgZ3Jl YXQgcXVlc3Rpb24gZm9yIFJGQzQzNzksIGJ1dCBub3QgZm9yIHRoZSBiaXMgOi0pIENvdWxkIGhh dmUgZG9uZSBhIGxvdCBvZiB0aGluZ3MgYXQgdGhlIHRpbWUuDQoNCkEgbWFqb3IgZGVwYXJ0dXJl IGZyb20gdGhlIGV4aXN0aW5nIHBhcmFkaWdtLCBhbmQgYSBwb3RlbnRpYWxseSBuaWNlIGF0dGFj ayB2ZWN0b3IsIHdvdWxkIGJlIHRvIGdlbmVyYXRlIG11bHRpcGxlIHJlc3BvbnNlIHBhY2tldHMg ZnJvbSBhIHNpbmdsZSBwYWNrZXQuIEJ1dCBub25ldGhlbGVzcywgdGhhdCB3b3VsZCBiZSBhIGRp ZmZlcmVudCBwcm90b2NvbCBhbmQgbm90IGEgYmlzLg0KDQpJcyB0aGVyZSBhIHJhdGlvbmFsIGZv cg0KY29weWluZyB0aGlzIElDTVAgaGFjaz8NCg0KDQpIYWNrIGZvciBvbmUsIGVsZWdhbnQgZW5n aW5lZXJpbmcgZm9yIGFub3RoZXIsIG1heWJlIGJvdGggOi0pDQoNClRoYW5rcywNCg0K4oCUIENh cmxvcy4NCg0KDQoNCg== --_000_23E7818F7EC24D118F4887BBE8B5FEB0ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3630149443E0B4439EAD0DF7D3C3AB25@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksJm5ic3A7TWlyamEsDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsIHBs ZWFzZSBzZWUgaW5saW5lLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE9j dCAyNSwgMjAxNiwgYXQgMTE6MTcgQU0sIE1pcmphIEt1ZWhsZXdpbmQgJmx0OzxhIGhyZWY9Im1h aWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0IiBjbGFzcz0iIj5pZXRmQGt1ZWhsZXdpbmQubmV0PC9h PiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+TWlyamEgS8O8aGxld2luZCBoYXMgZW50 ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8YnIgY2xhc3M9IiI+DQpkcmFm dC1pZXRmLW1wbHMtcmZjNDM3OWJpcy0wNzogTm8gT2JqZWN0aW9uPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5l IGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJyIGNsYXNzPSIiPg0KZW1haWwgYWRkcmVzc2VzIGlu Y2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8YnIg Y2xhc3M9IiI+DQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2UgcmVmZXIgdG8gPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1s IiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3Mt Y3JpdGVyaWEuaHRtbDwvYT48YnIgY2xhc3M9IiI+DQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBi YWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZTo8YnIgY2xhc3M9IiI+DQo8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtcmZjNDM3 OWJpcy8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtbXBscy1yZmM0Mzc5YmlzLzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KQ09N TUVOVDo8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KQSBmZXcgbm90IHZlcnkgaW1wb3J0YW50IGNvbW1lbnRzOjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjEpIFRvIG1lIGl0IHNlZW1zIGEgYml0IHVuZm9ydHVuYXRlIHRoYXQgdGhp cyBkcmFmdCBwb2ludHMgdG8gcmZjNjQyNSBhbmQ8YnIgY2xhc3M9IiI+DQpyZmM2NDI2IGZvciB0 aGUgZGVmaW5pdGlvbiBvZiB0aGUgVCBhbmQgUiBmbGFncywgZ2l2ZW4gdGhlIGdvYWwgd2FzIHRv PGJyIGNsYXNzPSIiPg0KaGF2ZSBhbGwgc3BlY2lmaWNhdGlvbnMgaW4gb25lIGRvYy4gTm90IHN1 cmUgaWYgdGhhdCBjYW4gb3Igc2hvdWxkIGJlPGJyIGNsYXNzPSIiPg0KZml4ZWQuIEp1c3Qgd2Fu dGVkIHRvIG1lbnRpb24gaXQuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyBmb3IgbWVudGlv bmluZyBpdC4gVGhlIFdHIGRpZCBkaXNjdXNzIHRoaXMuIFlvdSBjYW4gc2VlJm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni1t cGxzLTIucGRmIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9z bGlkZXMvc2xpZGVzLTk2LW1wbHMtMi5wZGY8L2E+PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj5TaW5jZSA0Mzc5YmlzIGlzIG5vdCBvYnNvbGV0aW5nIHJmYzY1MjUgYW5k IHJmYzY1MjYsIHRoZSBpZGVhIHdhcyB0byBrZWVwIHRoZSBkZWZpbml0aW9uIGluIHRob3NlIFJG Q3MsIGJ1dCBtZW50aW9uIHRoZW0gaW4gdGhlIGJpcy48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KMikgSSB3b3VsZCBleHBlY3QgdGhhdCB0aGUgc2VjdXJpdHkg c2VjdGlvbiByZWNvbW1lbmRzIGJvcmRlciBmaWx0ZXJpbmc8YnIgY2xhc3M9IiI+DQpvZiBNUExT IHBpbmcgbWVzc2FnZSwgZ2l2ZW4gdGhhdCB0aGVzZSBhcmUgdXN1YWxseSB1c2VkIHdpdGhpbiBv bmU8YnIgY2xhc3M9IiI+DQpkb21haW4sIG5vPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdj5UaGVyZSBpcyBpbnRlci1hcyBhbmQgaW50ZXIgZG9tYWluIGxzcCBwaW5nLiZuYnNw OzwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4zKSBJIGtub3cgdGhpcyBpcyBhIGJpcyBk b2MgYnV0IEknbSBzdGlsbCB3b25kZXJpbmcgd2h5IHRoaXMgVFRMIHRyaWNrIGlzPGJyIGNsYXNz PSIiPg0KdXNlZCBoZXJlLiBGb3IgSUNNUCB0aGF0IHdhcyBhIHdheSB0aGF0IHV0aWxpemVzIHRo ZSBleGlzdGluZzxiciBjbGFzcz0iIj4NCnNwZWNpZmljYXRpb24gYW5kIGltcGxlbWVudGF0aW9u IHRvIGdldCBmdXJ0aGVyIGluZm9ybWF0aW9uLiA8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SGVyZSwgdGhlIFRUTCBleHBpcmF0 aW9uIGluIHRyYWNlcm91dGUgbW9kZSBpcyB1c2VkIHRvIGludGVyY2VwdCB0aGUgcGFja2V0IGFu ZCBzZW5kIGl0IHRvIHRoZSBjb250cm9sIHBsYW5lLiBBZGRpdGlvbmFsbHkgc2VlIGJlbG93Ljwv ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Ib3dldmVyPGJyIGNsYXNzPSIiPg0KaGVyZSwg eW91IGNvdWxkIGp1c3QgaGF2ZSB1c2VkIGEgZmxhZyBpbiB0aGUgaGVhZGVyIGVpdGhlciBzYXlp bmcgJ29ubHk8YnIgY2xhc3M9IiI+DQpmb3J3YXJkIHRvIHRoZSBlbmQnIG9yICdyZXBseSBhbmQg c3RpbGwgZm9yd2FyZCcsIG9yIHNvbWV0aGluZyBsaWtlIHRoaXMsPGJyIGNsYXNzPSIiPg0KdG8g Y292ZXIgdGhlIHR3byBtb2Rlcy4gVGhpcyB3b3VsZCBhbHNvIGFsbG93IHRvIGp1c3Qgc2VuZCBv bmUgcGFja2V0IHRvPGJyIGNsYXNzPSIiPg0KdGhlIGVuZCBpbnN0ZWFkIG9mIHNlbmRpbmcgb25l IGZvciBlYWNoIGhvcC48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhhdOKAmXMgYSBncmVhdCBxdWVzdGlvbiBmb3IgUkZDNDM3 OSwgYnV0IG5vdCBmb3IgdGhlIGJpcyA6LSkgQ291bGQgaGF2ZSBkb25lIGEgbG90IG9mIHRoaW5n cyBhdCB0aGUgdGltZS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkEg bWFqb3IgZGVwYXJ0dXJlIGZyb20gdGhlIGV4aXN0aW5nIHBhcmFkaWdtLCBhbmQgYSBwb3RlbnRp YWxseSBuaWNlIGF0dGFjayB2ZWN0b3IsIHdvdWxkIGJlIHRvIGdlbmVyYXRlIG11bHRpcGxlIHJl c3BvbnNlIHBhY2tldHMgZnJvbSBhIHNpbmdsZSBwYWNrZXQuIEJ1dCBub25ldGhlbGVzcywgdGhh dCB3b3VsZCBiZSBhIGRpZmZlcmVudCBwcm90b2NvbCBhbmQgbm90IGEgYmlzLjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj5JcyB0aGVyZSBhIHJhdGlvbmFsIGZvcjxiciBjbGFzcz0iIj4N CmNvcHlpbmcgdGhpcyBJQ01QIGhhY2s/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PkhhY2sgZm9yIG9uZSwgZWxlZ2FudCBlbmdpbmVlcmluZyBmb3IgYW5vdGhlciwgbWF5YmUg Ym90aCA6LSk8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8 L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PuKAlCBDYXJsb3MuPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_23E7818F7EC24D118F4887BBE8B5FEB0ciscocom_-- From nobody Wed Oct 26 06:15:51 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5002012967E; Wed, 26 Oct 2016 06:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.951 X-Spam-Level: X-Spam-Status: No, score=-14.951 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y74T6uiPrFXj; Wed, 26 Oct 2016 06:15:45 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D46129BBF; Wed, 26 Oct 2016 06:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13437; q=dns/txt; s=iport; t=1477487738; x=1478697338; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/h5ygItlbXx+yskd7muNjTbd0tPoe+ekC4rEJqa+hVE=; b=TRwHrFjG/OkvuUXoes47996KdXxIyMg8UOExB9r/ACAn8ozs81GnF2ze GQ/S3lGwUdm3PSb8a2J0/6totYP6dFjjTbQumr+V6SvXoVyHnlo2IDzON lI5ZswgKTSijc+WRgdoKpJD4r6V9kSzjL9fPEQS+TfLVrE5MErZ//Sf/R I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAQAPqxBY/5hdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnM3AQEBAQEdWH0HjS6Wfodeh0uDB4IPggknhXsCgX4/FAECAQEBAQE?= =?us-ascii?q?BAWIohGIBAQECAnkQAgEIEQMBAigHIREUCQgCBAENBYg6AxcOvBUNg3ABAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEXBYsSgkeBUhEBIxkYhScFiEWGQIpcNQGGK4ZRgyO?= =?us-ascii?q?BboRtiSmIcIQahAABHjZegxkcGIE6cgGGLw0XB4ECgQkBAQE?= X-IronPort-AV: E=Sophos;i="5.31,550,1473120000"; d="scan'208,217";a="338975063" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2016 13:15:37 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u9QDFbru029349 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Oct 2016 13:15:37 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Oct 2016 08:15:36 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Wed, 26 Oct 2016 08:15:36 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Carlos Pignataro (cpignata)" , Mirja Kuehlewind Thread-Topic: =?iso-8859-1?Q?Mirja_K=FChlewind's_No_Objection_on_draft-ietf-mpls-rfc437?= =?iso-8859-1?Q?9bis-07:_(with_COMMENT)?= Thread-Index: AQHSLuwBtgjqFU6gEEeW1K5hHrffDqC6iQEAgAA/+oA= Date: Wed, 26 Oct 2016 13:15:36 +0000 Message-ID: References: <147741942986.1480.9692706368109608681.idtracker@ietfa.amsl.com> <23E7818F-7EC2-4D11-8F48-87BBE8B5FEB0@cisco.com> In-Reply-To: <23E7818F-7EC2-4D11-8F48-87BBE8B5FEB0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.18.92] Content-Type: multipart/alternative; boundary="_000_D43623D019F996naikumarciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls-chairs@ietf.org" , "draft-ietf-mpls-rfc4379bis@ietf.org" , "mpls@ietf.org" , The IESG Subject: Re: [mpls] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-mpls-rfc4379bis-07=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 13:15:49 -0000 --_000_D43623D019F996naikumarciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mirja, Is there a rational for copying this ICMP hack? Using a flag in the header and sending it hop-by-hop will end up= taking soft path (CPU punt path) and may not validate the actual data path= . Use of TTL trick will help validate if the transit nodes are forwarding i= t as per control plane. With this machinery, we get the Downstream TLV deta= ils as per control plane, include it in the next probe and validate it wit= h the actual Downstream node. Thanks, Nagendra From: "Carlos Pignataro (cpignata)" > Date: Wednesday, October 26, 2016 at 1:26 AM To: Mirja Kuehlewind > Cc: The IESG >, "draft-ietf-mpls-rfc437= 9bis@ietf.org" >, Loa Ande= rsson >, "mpls-chairs@ietf.org" >, "mpls@ie= tf.org" > Subject: Re: Mirja K=FChlewind's No Objection on draft-ietf-mpls-rfc4379bis= -07: (with COMMENT) Resent-From: > Resent-To: >,= >, Nagendra Kumar Nainar >, >, > Resent-Date: Wednesday, October 26, 2016 at 1:26 AM Hi, Mirja, Thanks, please see inline. On Oct 25, 2016, at 11:17 AM, Mirja Kuehlewind > wrote: Mirja K=FChlewind has entered the following ballot position for draft-ietf-mpls-rfc4379bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few not very important comments: 1) To me it seems a bit unfortunate that this draft points to rfc6425 and rfc6426 for the definition of the T and R flags, given the goal was to have all specifications in one doc. Not sure if that can or should be fixed. Just wanted to mention it. Thanks for mentioning it. The WG did discuss this. You can see https://www.= ietf.org/proceedings/96/slides/slides-96-mpls-2.pdf Since 4379bis is not obsoleting rfc6525 and rfc6526, the idea was to keep t= he definition in those RFCs, but mention them in the bis. 2) I would expect that the security section recommends border filtering of MPLS ping message, given that these are usually used within one domain, no? There is inter-as and inter domain lsp ping. 3) I know this is a bis doc but I'm still wondering why this TTL trick is used here. For ICMP that was a way that utilizes the existing specification and implementation to get further information. Here, the TTL expiration in traceroute mode is used to intercept the packet= and send it to the control plane. Additionally see below. However here, you could just have used a flag in the header either saying 'only forward to the end' or 'reply and still forward', or something like this, to cover the two modes. This would also allow to just send one packet to the end instead of sending one for each hop. That's a great question for RFC4379, but not for the bis :-) Could have don= e a lot of things at the time. A major departure from the existing paradigm, and a potentially nice attack= vector, would be to generate multiple response packets from a single packe= t. But nonetheless, that would be a different protocol and not a bis. Is there a rational for copying this ICMP hack? Hack for one, elegant engineering for another, maybe both :-) Thanks, - Carlos. --_000_D43623D019F996naikumarciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Is there a rational for
copying this ICMP hack?

<Nagendra> Using a flag in the header and sending it = hop-by-hop will end up taking soft path (CPU punt path) and may not validat= e the actual data path. Use of TTL trick will help validate if the transit = nodes are forwarding it as per control plane. With this machinery, we get the Downstream TLV details as per control plan= e, include it in the next probe  and validate it with the actual Downs= tream node.

Thanks,
Nagendra 

From: "Carlos Pignataro (cpign= ata)" <cpignata@cisco.com= >
Date: Wednesday, October 26, 2016 a= t 1:26 AM
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-mpls-rfc4379bis@ietf.org" <<= a href=3D"mailto:draft-ietf-mpls-rfc4379bis@ietf.org">draft-ietf-mpls-rfc43= 79bis@ietf.org>, Loa Andersson <loa@pi.nu>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "<= a href=3D"mailto:mpls@ietf.org">mpls@ietf.org" <mpls@ietf.org>
Subject: Re: Mirja K=FChlewind's No= Objection on draft-ietf-mpls-rfc4379bis-07: (with COMMENT)
Resent-From: <alias-bounces@ietf.org>
Resent-To: <kireeti.kompella@gmail.com>, <cpignata@cisco.com>, Nagendra Kumar N= ainar <naikumar@cisco.com>, <aldrin.ietf@gmail.com>= , <mach.chen@huawei.com><= br> Resent-Date: Wednesday, October 26,= 2016 at 1:26 AM

Hi, Mirja,

Thanks, please see inline.

On Oct 25, 2016, at 11:17 AM, Mirja Kuehlewind <ietf@kuehlewind.net> wrot= e:

Mirja K=FChlewind has entered the following ballot position= for
draft-ietf-mpls-rfc4379bis-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few not very important comments:

1) To me it seems a bit unfortunate that this draft points to rfc6425 and rfc6426 for the definition of the T and R flags, given the goal was to
have all specifications in one doc. Not sure if that can or should be
fixed. Just wanted to mention it.

Thanks for mentioning it. The WG did discuss this. You can see https://www.ietf.org/proceedings/96/slides/slides-96-mpls-2.pdf

Since 4379bis is not obsoleting rfc6525 and rfc6526, the idea was to k= eep the definition in those RFCs, but mention them in the bis.


2) I would expect that the security section recommends border filtering
of MPLS ping message, given that these are usually used within one
domain, no?


There is inter-as and inter domain lsp ping. 

3) I know this is a bis doc but I'm still wondering why thi= s TTL trick is
used here. For ICMP that was a way that utilizes the existing
specification and implementation to get further information.

Here, the TTL expiration in traceroute mode is used to intercept the p= acket and send it to the control plane. Additionally see below.

However
here, you could just have used a flag in the header either saying 'only
forward to the end' or 'reply and still forward', or something like this, to cover the two modes. This would also allow to just send one packet to the end instead of sending one for each hop.

That’s a great question for RFC4379, but not for the bis :-) Cou= ld have done a lot of things at the time.

A major departure from the existing paradigm, and a potentially nice a= ttack vector, would be to generate multiple response packets from a single = packet. But nonetheless, that would be a different protocol and not a bis.<= /div>
Is there a rational for
copying this ICMP hack?


Hack for one, elegant engineering for another, maybe both :-)

Thanks,

— Carlos.



--_000_D43623D019F996naikumarciscocom_-- From nobody Wed Oct 26 15:03:22 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6994412969B; Wed, 26 Oct 2016 15:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHiXzPkIhJKB; Wed, 26 Oct 2016 15:03:06 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6BB129601; Wed, 26 Oct 2016 15:03:05 -0700 (PDT) X-AuditID: c1b4fb2d-1dbff700000009f7-9a-581128163a11 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 34.C5.02551.61821185; Thu, 27 Oct 2016 00:03:04 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 27 Oct 2016 00:03:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xsKZ/PO3BPcCfSm/g4OvWvCWWKaqIHtZ+optPxzT3Dg=; b=XDC8wInc+JFR6C7bOAfkijcUIQOGIEaQxxw79pKJ6Jmbpv1dIZrj5HWn8fpxoGLtUix3QcPCUalYeX+P38cJxiBvl/lL1VXu5pzFq4I60mpQtmNr5gNkd9q6gGLsUfMfvvCiIv1LV7rfCxGlsftw3/wqWsECEgN5xZdWxX+Y+Nc= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Wed, 26 Oct 2016 22:03:01 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0693.009; Wed, 26 Oct 2016 22:03:01 +0000 From: Daniele Ceccarelli To: CCAMP , "pce@ietf.org" , "mpls@ietf.org" , "TEAS WG (teas@ietf.org)" Thread-Topic: IETF 97 - CCAMP slot request Thread-Index: AQHSKeVu3A5GZ7L3H0q/RYeVYpmAgKC7VPqQ Date: Wed, 26 Oct 2016 22:03:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [185.113.96.72] x-ms-office365-filtering-correlation-id: fa9af1f2-8b11-400b-cd3f-08d3fdebdaa1 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0994; 7:8joOlB5QxzRKa6PmF/4F6rTT4yEJcGgNkGO6FRrzKFYluhr8J93LbpNtHiqz5gvXwSQrfnztj1kNqhXG1+tb39gXu47KZiADo7zGs8rp94ktX4ey74nFbO+I58xhwHmGUZQ5htFxlbdEVZw34ZKM0C6v7uDcLADHMSwKh8QuyFmEDALaTPfaFDVk+H0UYOMq7t7+gYoODex3WgwOE13zRF2DIHVA3i9s1Y45o/Q/w7KdmcbzBZI8oHtTf7JTN/Pe360cmFUSrpQRzymJk9uByS+KLjs2p3DPJOU0Hn1nbY5fjsfJ8kykS+jUrpJIB5m2VSLS1hTiosXk0k/B1YBy6UhS6ReynuCv1fXYuemz2sQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0994; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM2PR07MB0994; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0994; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(7916002)(377424004)(53754006)(199003)(189002)(107886002)(97736004)(5001770100001)(4001150100001)(33656002)(189998001)(106116001)(19625215002)(5002640100001)(76576001)(7846002)(2201001)(7696004)(92566002)(450100001)(2950100002)(7906003)(9686002)(74316002)(5660300001)(106356001)(8936002)(87936001)(7736002)(19300405004)(77096005)(19580395003)(19580405001)(3280700002)(16236675004)(86362001)(15975445007)(2900100001)(3660700001)(790700001)(102836003)(3846002)(122556002)(6116002)(50986999)(586003)(54356999)(76176999)(66066001)(19617315012)(2501003)(101416001)(81166006)(10400500002)(105586002)(8676002)(81156014)(68736007)(2906002)(11100500001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0994; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB09942F091489EB167451664EF0AB0AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2016 22:03:01.3578 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0994 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHeXfO2c7Exevy8qBSuArMmHdqiYT2oQtekr40ItKZBxXnpR2V 9ENpYeU0S3OgJmXl3Wq1NGfaxVmiKykhbdlFYSu8YIlL0rzlPAv89nuf//Pnef4PL02IH1Du dHJaJqNKUyglfAeyUt4eLQVvJ7n/20axzFJtImUjdU2U7PyoSSArmNeTYeSh2toFXgw67hCa wCiTsxmV3744h6Sylh8ooyL3TIdVjfLQZKoaCWnAwfBenc9TIwdajLUIGr8vI5sgxn0Ibn6M tzGJrxBQXZTFNWl48ChvmeAevQhGFkfXHDTNxyFgMUTa6s74EoK/2iWBzb0Z7wSNYZZvY2fs A4+NXXYOhDe6QpKbsAN0d2fWJ4vwCSiw5pPcFuGw0PqZsrEQ74flzp/rjLAr/DHe49mYwG4w YrnF4+JgqO16R3DsAhPmFXt/PGgL9PYeL5iZK6U4joLJ2SK+bWnANQR0D14gOeEAvOz8jThO gRLrkt0QAYaubooz6BEUNxrtgic8nx60CzN8MFcPUVwEBhruFyDuFO7w9UOhnT1h/Msz6hry rtqQguN0sPS+4FetX8MJ+istJFf3BZOmnM/xLqi/PUVwLIWKFQO5sV6DBM3IhWVYNjUxMMiX USWfYtn0NN80JlOH1n5Rd+uiVI9apsINCNNI4igae4LlYkqRzeakGhDQhMRZxG5zkotFCYqc XEaVHqvKUjKsAXnQpMRNtLtp9JgYJyoymRSGyWBU/1UeLXTPQ676XxFLkeNKYUfzZbdvbbNb G9TFyjJ1s7mtPvro9brTe1dn+hWvb8wFTxQfWS0yDfRo++YvxvZYrWF+ySf9n5413w4RaKy6 YuTIF5SYEhLjtke5nht0+nR4eDq1lJzwp8TDoUFXPaRDMV663PI9cQ+Nd2racwI2jQ+MCV8Z Dm6RkGySIsCHULGKfxvqJRZBAwAA Archived-At: Subject: Re: [mpls] IETF 97 - CCAMP slot request X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 22:03:08 -0000 --_000_AM2PR07MB09942F091489EB167451664EF0AB0AM2PR07MB0994eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, A friendly reminder. Please note that the deadline for asking a slot for th= e CCAMP session or the joint YANG session is TODAY. Thanks Daniele From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Oscar Gonz=E1lez d= e Dios Sent: mercoled=EC 19 ottobre 2016 10:48 To: CCAMP Subject: [CCAMP] IETF 97 - CCAMP slot request Dear CCAMPers, IETF 97 meeting @ Seoul is approaching and it's time to start collecting ag= enda slots requests. Please, keep this in mind: WG Draft authors are expected to present if there are open issues to discus= s, or to send status to the list *1 week* prior to the WG meeting if not p= resenting. Status includes review of: any recent changes, any open discussi= ons or issues, and planned next steps. Agenda Requests: - To submit a request, please fill the survey at the following link: http:/= /www.surveygizmo.com/s3/3124554/IETF-97-CCAMP-sessions-slot-requests - As there will be also a joint Yang session with other working groups, ple= ase indicate in the slot request if the authors believe that the draft shou= ld be presented in this joint YANG session only, in the CCAMP session only = or in both. - Please fill the survey no later than Thursday, October 27th. Presentations: If you are presenting slides please make sure you send them to all *indi= viduals* listed above (Chairs, Secretary and exclude CCAMP) no later than = Sunday, November 13th. Reminder about a few important dates: * 2016-10-31 (Monday): Internet Draft submission cut-off (for all drafts, i= ncluding -00) by UTC 23:59, upload using IETF ID Submission Tool. * 2016-10-31 (Monday): Draft Working Group agendas due by UTC 23:59, upload= using IETF Meeting Materials Management Tool. * 2016-11-07 (Monday): Revised Working Group agendas due by UTC 23:59, uplo= ad using IETF Meeting Materials Management Tool. * 2016-11-13 - 2016-11-18: IETF 97 in Seoul, South Korea Best Regards, =D3scar CCAMP WG Secretary --_000_AM2PR07MB09942F091489EB167451664EF0AB0AM2PR07MB0994eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

&nbs= p;

A friendl= y reminder. Please note that the deadline for asking a slot for the CCAMP s= ession or the joint YANG session is TODAY.

&nbs= p;

Thanks Daniele 

&nbs= p;

From: = CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Oscar Gonz=E1lez de Dios
Sent: mercoled=EC 19 ottobre 2016 10:48
To: CCAMP <ccamp@ietf.org>
Subject: [CCAMP] IETF 97 - CCAMP slot request

 

Dear CCAMPers,

 =

IETF 97 meeting @ S= eoul is approaching and it’s time to start collecting agenda slo= ts requests.

 

Please, keep this in mind:

 

WG Draft authors are expected to present if there are= open issues to discuss, or to send status to the list  *1 week* prior to the WG meeting if not presenting. Status incl= udes review of: any recent changes, any open discussions or issues, and pla= nned next steps.

 

= Agenda Requests:

- To submit a request, please fill the su= rvey at the following link: http://ww= w.surveygizmo.com/s3/3124554/IETF-97-CCAMP-sessions-slot-requests =

- As there will be also a joint Yang se= ssion with other working groups, please indicate in the slot request if the= authors believe that the draft should be presented in this joint YANG session only, in the CCAMP session only or in both.

- Please fill the survey no later than Thursd= ay, October 27th.

 

= Presentations:

  If you are presenting slides please make sure = you send them to  all *individuals* listed above (Chairs, Secretary and exclude CCAMP) no later  than Sunday, November = 13th.

 

= Reminder about a few important dates= :

 

* 2016-10-31 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool.

* 2016-10-31 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.

* 2016-11-07 (Monday): Revised Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool.

* 2016-11-13 - 2016-11-18:= IETF 97 in Seoul, South Korea

 

Best Regards,

 

=D3scar 

 

        CCAMP WG Se= cretary

--_000_AM2PR07MB09942F091489EB167451664EF0AB0AM2PR07MB0994eurp_-- From nobody Wed Oct 26 15:30:01 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C90E128B38; Wed, 26 Oct 2016 15:30:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147752100043.2959.17936359559442686266.idtracker@ietfa.amsl.com> Date: Wed, 26 Oct 2016 15:30:00 -0700 Archived-At: Cc: draft-ietf-mpls-rfc4379bis@ietf.org, mpls@ietf.org, elwynd@dial.pipex.com, mpls-chairs@ietf.org Subject: [mpls] Jari Arkko's Discuss on draft-ietf-mpls-rfc4379bis-07: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 22:30:00 -0000 Jari Arkko has entered the following ballot position for draft-ietf-mpls-rfc4379bis-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for writing this document. I will recommend its approval, but before that we have a fix a couple of issues. A Gen-ART review by Elwyn Davies raised a number of valid points. The ones worthy of a Discuss are the following: 1. Section 3.4 protocol definition refers to Appendix A.2 which is depracated/non-normative. I think you have to decide which parts are still in the normative spec, and keep those in the body of the document. 2. Reference to the R flag in 6.2.3 seems wrong, as the flag isn't actually allocated in RFC 6426 due to an oversight. Maybe either explain the situation and the existing errata, or just define the flag in this RFC and be done with it? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please work with the Gen-ART reviewer on the remaining issues as well. From nobody Thu Oct 27 00:47:08 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F341294A0; Thu, 27 Oct 2016 00:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd5RPOwDakJz; Thu, 27 Oct 2016 00:47:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2B112947D; Thu, 27 Oct 2016 00:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2081; q=dns/txt; s=iport; t=1477554424; x=1478764024; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y4tiBsVtDG7itQtLDqNjAqSTYLx/bDWxo2sIY5nYArE=; b=aAo9bKpbAvXkU4DogSZUO6NFGynT4d7Sk680EQrG6qPP34wYUzroaBHb 9P/hKSe5KGwJfGPdGIuVR2DA8NFZvMq1c7tNSGukm2FYpUG61du9NeSD6 kjEzBiVCVi0LX/Oo882Vkt2rrpNTGgpIqU/xZcvL6d/d0I+2zj7pXtS4I Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAQDQsBFY/4oNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR1YfY03ln+SMIIPggcnhXsCgX8/FAECAQEBAQEBAWIohGI?= =?us-ascii?q?BAQEDATo/BQsCAQgYHhAyJQIEDgWITAgOv3wBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEXBYY9gX0IglCEGQoHARwygn6CLwWIRZFRAYYsiXWBboRtiSmNC4QAAR42X4N?= =?us-ascii?q?PgTpyAYYmDxeCEgEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,404,1473120000"; d="scan'208";a="164307482" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Oct 2016 07:46:43 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u9R7khpM001263 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Oct 2016 07:46:43 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Oct 2016 03:46:42 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Thu, 27 Oct 2016 03:46:42 -0400 From: "Carlos Pignataro (cpignata)" To: Jari Arkko Thread-Topic: Jari Arkko's Discuss on draft-ietf-mpls-rfc4379bis-07: (with DISCUSS and COMMENT) Thread-Index: AQHSL9h/YOdeaSWJy0ObxpDLStORH6C77NND Date: Thu, 27 Oct 2016 07:46:42 +0000 Message-ID: <2659BFA9-D9C6-42EC-9485-2C9EBD012E69@cisco.com> References: <147752100043.2959.17936359559442686266.idtracker@ietfa.amsl.com> In-Reply-To: <147752100043.2959.17936359559442686266.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-rfc4379bis@ietf.org" , "mpls-chairs@ietf.org" , The IESG , "elwynd@dial.pipex.com" Subject: Re: [mpls] Jari Arkko's Discuss on draft-ietf-mpls-rfc4379bis-07: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 07:47:07 -0000 Thank you Jari for raising this Discuss. We are working on addressing all t= he comments, including but not limited to the two below.=20 New rev forthcoming.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Oct 26, 2016, at 15:30, Jari Arkko wrote: >=20 > Jari Arkko has entered the following ballot position for > draft-ietf-mpls-rfc4379bis-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thank you for writing this document. I will recommend its approval, but > before that we have a fix a couple of issues. >=20 > A Gen-ART review by Elwyn Davies raised a number of valid points. The > ones worthy of a Discuss are the following: >=20 > 1. Section 3.4 protocol definition refers to Appendix A.2 which is > depracated/non-normative. I think you have to decide which parts are > still in the normative spec, and keep those in the body of the document. >=20 > 2. Reference to the R flag in 6.2.3 seems wrong, as the flag isn't > actually allocated in RFC 6426 due to an oversight. Maybe either explain > the situation and the existing errata, or just define the flag in this > RFC and be done with it? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Please work with the Gen-ART reviewer on the remaining issues as well. >=20 >=20 From nobody Thu Oct 27 18:31:41 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B618129424; Thu, 27 Oct 2016 18:31:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147761830056.24630.17908310665172285689.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 18:31:40 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rfc4379bis-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 01:31:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Authors : Kireeti Kompella George Swallow Carlos Pignataro Nagendra Kumar Sam Aldrin Mach(Guoyi) Chen Filename : draft-ietf-mpls-rfc4379bis-08.txt Pages : 73 Date : 2016-10-27 Abstract: This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. This document obsoletes RFCs 4379, 6424, 6829, and 7537. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-rfc4379bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rfc4379bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 27 18:33:52 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4E7129476; Thu, 27 Oct 2016 18:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ3TaNQlceKs; Thu, 27 Oct 2016 18:33:43 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644FE12999E; Thu, 27 Oct 2016 18:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2694; q=dns/txt; s=iport; t=1477618423; x=1478828023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Hu0ZklGLuJsEMNHLt5wPn1cZQy3Nr8qVSxY+AixG0jk=; b=dv0aW+GFm45XYqUzs5EsF5CDMfS3kEDppD/jvp8g10voT8Rl9pD7r7mS RzOgetNJaJQXQPtqXKVk30yvDzXvj7aQmWJ/uNQ0BEXNw/JBpvqoZvP7+ 1m1bWU0mAH5T8zOP1/IcZW7IHjRiKpbR2N7q9n/HIdc0UhVa9zyaFWjTb w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQB6qhJY/4YNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR1YfQeNL5Z+kjCCD4IHKIV7AhqBZj8UAQIBAQEBAQEBYii?= =?us-ascii?q?EYgEBAQMBIxFFBQsCAQgYAgImAgICMBUQAgQOBYhMCA6xTYx5AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwWBB4U2gX0IglCEGREBHIMELIIvBYhFkVEBhiyJdoFuhG2?= =?us-ascii?q?JKY0LhAABHjZfg0+BOnIBhXCBIIEJAQEB?= X-IronPort-AV: E=Sophos;i="5.31,406,1473120000"; d="scan'208";a="340557595" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Oct 2016 01:33:42 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u9S1XgqU024734 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Oct 2016 01:33:42 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Oct 2016 21:33:41 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Thu, 27 Oct 2016 21:33:41 -0400 From: "Carlos Pignataro (cpignata)" To: Jari Arkko Thread-Topic: Jari Arkko's Discuss on draft-ietf-mpls-rfc4379bis-07: (with DISCUSS and COMMENT) Thread-Index: AQHSL9h/YOdeaSWJy0ObxpDLStORH6C9WfIA Date: Fri, 28 Oct 2016 01:33:41 +0000 Message-ID: <3E43C605-85FF-4CF0-8662-8E8798D4A2D2@cisco.com> References: <147752100043.2959.17936359559442686266.idtracker@ietfa.amsl.com> In-Reply-To: <147752100043.2959.17936359559442686266.idtracker@ietfa.amsl.com> 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.82.225.82] Content-Type: text/plain; charset="utf-8" Content-ID: <5FD2E895FE8E5047ABC97E9F2A52FC69@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-rfc4379bis@ietf.org" , "mpls-chairs@ietf.org" , The IESG , "elwynd@dial.pipex.com" Subject: Re: [mpls] Jari Arkko's Discuss on draft-ietf-mpls-rfc4379bis-07: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 01:33:45 -0000 SmFyaSwNCg0KUmV2aXNpb24gLTA4LCB3aGljaCBqdXN0IHBvc3RlZCwgc2hvdWxkIGFkZHJlc3Mg YWxsIG9mIHRoZSBpc3N1ZXMgYW5kIG5pdHMgZnJvbSBFbHd5biBEYXZpZXPigJlzIEdlbi1BUlQg cmV2aWV3Lg0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCj4gT24gT2N0IDI2LCAyMDE2LCBh dCA1OjMwIFBNLCBKYXJpIEFya2tvIDxqYXJpLmFya2tvQHBpdWhhLm5ldD4gd3JvdGU6DQo+IA0K PiBKYXJpIEFya2tvIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZv cg0KPiBkcmFmdC1pZXRmLW1wbHMtcmZjNDM3OWJpcy0wNzogRGlzY3Vzcw0KPiANCj4gV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVz LiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2 ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNn L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUg ZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5k IGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBs cy1yZmM0Mzc5YmlzLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoYW5rIHlvdSBmb3Igd3JpdGluZyB0aGlzIGRvY3VtZW50 LiBJIHdpbGwgcmVjb21tZW5kIGl0cyBhcHByb3ZhbCwgYnV0DQo+IGJlZm9yZSB0aGF0IHdlIGhh dmUgYSBmaXggYSBjb3VwbGUgb2YgaXNzdWVzLg0KPiANCj4gQSBHZW4tQVJUIHJldmlldyBieSBF bHd5biBEYXZpZXMgcmFpc2VkIGEgbnVtYmVyIG9mIHZhbGlkIHBvaW50cy4gVGhlDQo+IG9uZXMg d29ydGh5IG9mIGEgRGlzY3VzcyBhcmUgdGhlIGZvbGxvd2luZzoNCj4gDQo+IDEuIFNlY3Rpb24g My40IHByb3RvY29sIGRlZmluaXRpb24gcmVmZXJzIHRvIEFwcGVuZGl4IEEuMiB3aGljaCBpcw0K PiBkZXByYWNhdGVkL25vbi1ub3JtYXRpdmUuIEkgdGhpbmsgeW91IGhhdmUgdG8gZGVjaWRlIHdo aWNoIHBhcnRzIGFyZQ0KPiBzdGlsbCBpbiB0aGUgbm9ybWF0aXZlIHNwZWMsIGFuZCBrZWVwIHRo b3NlIGluIHRoZSBib2R5IG9mIHRoZSBkb2N1bWVudC4NCj4gDQo+IDIuIFJlZmVyZW5jZSB0byB0 aGUgUiBmbGFnIGluIDYuMi4zIHNlZW1zIHdyb25nLCBhcyB0aGUgZmxhZyBpc24ndA0KPiBhY3R1 YWxseSBhbGxvY2F0ZWQgaW4gUkZDIDY0MjYgZHVlIHRvIGFuIG92ZXJzaWdodC4gTWF5YmUgZWl0 aGVyIGV4cGxhaW4NCj4gdGhlIHNpdHVhdGlvbiBhbmQgdGhlIGV4aXN0aW5nIGVycmF0YSwgb3Ig anVzdCBkZWZpbmUgdGhlIGZsYWcgaW4gdGhpcw0KPiBSRkMgYW5kIGJlIGRvbmUgd2l0aCBpdD8N Cj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+IFBsZWFzZSB3b3JrIHdpdGggdGhlIEdlbi1BUlQgcmV2aWV3ZXIgb24gdGhlIHJlbWFpbmlu ZyBpc3N1ZXMgYXMgd2VsbC4NCj4gDQo+IA0KDQo= From nobody Fri Oct 28 04:30:27 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDC0129607; Fri, 28 Oct 2016 04:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrXO733z99jy; Fri, 28 Oct 2016 04:30:22 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF67129499; Fri, 28 Oct 2016 04:30:21 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9SBUH6U022874; Fri, 28 Oct 2016 12:30:17 +0100 Received: from 950129200 (28.200.114.87.dyn.plus.net [87.114.200.28]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9SBUFg8022856 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2016 12:30:16 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , "'BRUNGARD, DEBORAH A'" , "'Stewart Bryant'" , "'Rolf Winter'" , , References: <791AD3077F94194BB2BDD13565B6295DAF13566B@Hydra.office.hd> <2c104f51-ddd1-6dde-7628-a14b6bb54a02@gmail.com> <5a67f818-bb6f-d562-b432-11374a8757e2@pi.nu> In-Reply-To: <5a67f818-bb6f-d562-b432-11374a8757e2@pi.nu> Date: Fri, 28 Oct 2016 12:30:14 +0100 Message-ID: <0a9b01d2310e$a7b2ecf0$f718c6d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJatvM2XaE5ntcR+A9NYbkOOoFM9gF5nOdEAgK6siQCAUbIUwKX0Od9Ae1cvAqfXI89oA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22664.006 X-TM-AS-Result: No--31.939-10.0-31-10 X-imss-scan-details: No--31.939-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFrYfPOPCpnfAnBRIrj8R47F3Uzu4eQif9xb0xWe53iJxSFk I89EnZRXDZFIu8KLdapZpgBZgcDt6/g/BD/quKxRoiN8YTmq+csyo9hO24/XxRtxV+e7ZseKiky rgGzY/ECekrOjtm4oRkesGfPifnTJo+gnPNvsrNZPuMJi/ZAk8RkqnRJng/51RJts9OIxqBMc5Z b9Gn+KypNP0rZ0q8ah5F42Su0IC3Hyx3bJ3I2fZilrosmS0SOAusAd8fYg+ZCGEL3ileQHE+R2p qb/g1hVbHaHOqIKwmCM283g/8Hr8vmei50Y3VOGlVHM/F6YkvSVq+okl1rYD50j8OKRnVQ8rUPU nGU6bCkkf/AOt6WNfxHGOMFuhxfaA2Ch8/vX/+mcF2Bhwpz5RCwJzaIVMjGtHqeNNK3aTguifff xSQsrlqQoOP6AqExB9dwmSVfeH+XXFDY6Be2LlfvADvTnCf5vhnI9sGH+HFZGr8G3v23M37ilk7 AKSW77ZzcnB2nN0NuHEFUbCl7xIz13WcdbGR6Q4Tzr6T25NkeyiNuZzgQ4vBjQD3m2MCf7wOXDW qJx+jg5+bQAkYlYAOhC5do1YPtQIIyzttajTOMcsSroYI5AVpKLNrbpy/A0FLXUWU5hGiGWGVyZ YRNOunxpW8kt8TmQV6AWp05+e42F3cIrxdLj3n9NanCUA4VeUCwb19dUaUm7ZXbg8KuZfu7huDp veq08w8XU8bLzT9KWxVvKuT7nDODBvYycsJwV84dsinZ5e1h4nU6KtjDMA9UQ4CdfNsvTzCaNCW gYjTy050BTdNeJgsaWOX3F06XhXDyeTDpp3CaeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47gc4WL5J jd88I2j49Ftap9EkGUtrowrXLg= Archived-At: Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 11:30:25 -0000 I don't think that there is a policy that dictates rejecting this draft, although common sense might! First RFC 4929: This document is directed to multi-vendor fora and Standards Development Organizations (SDOs) and This document does not modify IETF processes. Furthermore, RFC 4929 says "a problem statement and/or requirements statement must be produced and must be submitted to IETF as an Internet-Draft" but does not say "and will be published as an RFC". So let's leave RFC 4929 out of it? Second, the IESG has not made an IESG statement on this topic. As Rolf says, this was a blog post from Jari reporting on the IESG retreat (https://www.ietf.org/blog/2016/05/). Anyway, the main message is clearly that work on solutions should not be held up by work on use cases and requirements. The subsidiary message is that use case and requirements documents "need not necessarily always be RFCs". So there is clearly no policy here: no rules to be applied, and only advice that could be relevant. So maybe we can let go of that part of the discussion and focus on what is more interesting for the WG, viz. "What is the lasting value of publishing this document as an RFC? How will it shape the Internet in five years time?" If there are people who intend developing solutions (or an applicability statement) then why wouldn't it work to roll this material into that document? If there is no one planning a solution, then what is the intention of writing down requirements? Who is subject to this requirement? What is the document actually saying? Personally, I should think that the document is intended to encourage implementers to develop solutions, but that the authors themselves do not intend making such solutions. Will an RFC simply be published and forgotten? What will be its value? I'd suggest keeping the I-D alive as a WG document for 12 month to see if anyone starts work on the solution. If they do, we roll it in with their work. If not we let it expire and consider it archived." But I'd also say that the cost of publishing small RFC is small. It doesn't do significant harm to publish it. So if the WG is determined on that approach, let's just get on with it. (More cycles have been burned talking about whether to publish than were ever spent discussing the content!) Adrian > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 26 October 2016 04:11 > To: BRUNGARD, DEBORAH A; Stewart Bryant; Rolf Winter; mpls@ietf.org; ads@ietf.org> > Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and- > requirements - Working Group Last Call closed > > Deborah, > > with all due respect and without getting into "he said, she said, he > said. ... " debate, but I find what you say here not fully accurate. > > I find myself quoted in such a way that inply that I without > reservations support the change in document procedures that I seen > developing over a little more than a year. In fact I have very strong > reservations. > > First, mail mail say that we can not proceed at this time, and then > point to the change in procedure that stops us. > > The earlier procedure were captured in RFC 4929 > > "Whenever any extension or change to the (G)MPLS protocols is > desired, a problem statement and/or requirements statement must > be produced and must be submitted to IETF as an Internet-Draft." > > The draft under discussion is a perfect example of this. > > The RFC goes on and says that the IETF will evaluate the requirments, > praxis has been that the requirements has been published. > > The earlier procedure hasa served us well. > > Only that in this case we fail because the IESG has changed the the > procedure to "work in parallel". > > I think that two years ago (to be on the safe side) there would have > been no problem publishing the ID as an RFC, at lest not for the reasons > that stop it now. > > It surprises me that we don't accept what Jari said in his report from > the IESG retreat - "one size does not fit all". > > That said I don't exclude that we will tweak the model to be more > iterative, but: > > - first, we should not change in mid-process > - second, agreement on requirements, will always precede agreement on > architecture, frameworks, solutions and operational models. The time > span needed for "predede" is a matter of case by case. > > I think that the ue of the word "parallel" is misleading, I guess what > we are looking for is "iterative", i.e. an early step does not have to > be fully completed before the next step is started, the latter step > should be allowed to have an impact on the earlier. > > It should also be noted that we have players within the industry that > communicate with us through requirements, but has no immediate intention > to be involved in the solutions work. > > /Loa > > On 2016-10-26 06:17, BRUNGARD, DEBORAH A wrote: > > Hi Stewart, > > > > You may have missed the earlier mails and discussion on this thread. Rolf has > summarized accurately that Loa's mail is referring to this draft and not to a policy > change. > > > > Thanks, > > Deborah > > > >> -----Original Message----- > >> From: Stewart Bryant [mailto:stewart.bryant@gmail.com] > >> Sent: Tuesday, October 25, 2016 9:28 AM > >> To: Rolf Winter ; mpls@ietf.org; > >> > >> Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and- > >> requirements - Working Group Last Call closed > >> > >> Hi Rolf > >> > >> It needs further discussion if chairs have drafts rejected out of policy > >> rather than on a case by case basis. > >> > >> My understanding of Loa's comment is that policy is the high order bit. > >> > >> Maybe the RTG ADs can provide some guidelines? > >> > >> Stewart > >> > >> > >> On 25/10/2016 13:37, Rolf Winter wrote: > >>> Hi Stewart, > >>> > >>> I don't think the IESG has made a strict policy in this regard. Below is the > >> blog post extract that talks about this. I read it as a recommendation to focus > >> on protocol work and not let requirements work stall important protocol > >> specifications and as a clarification that there is no actual need to go through > >> a problem definition/use cases/requirements stage before protocol work can > >> start. But, as the text states, there is no one-size-fits-all approach. Not sure > >> this is actually controversial and needs further discussion. > >>> > >>> > >>> "We also discussed the role of requirement, use case, and problem > >> definition documents in IETF work. There is no one-size-fits-all approach to > >> different working groups. But the IESG wanted to be clear that the essence of > >> IETF work and the energy often comes from working on protocol solutions. > >> We were concerned about cases where it takes a long time to get to that > >> work. Working groups should NOT feel they need to sequence their work in > >> waterfall style. In fact, working in parallel with solutions and other supporting > >> documents (and code!) is often the best approach. And some of the > >> supporting documents need not necessarily always be RFCs; wikis, for > >> instance, are a fine approach as well." > >>> > >>> From: https://www.ietf.org/blog/2016/05/ > >>> > >>> Best, > >>> > >>> Rolf > >>> > >>> -----Original Message----- > >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant > >>> Sent: Dienstag, 25. Oktober 2016 09:36 > >>> To: mpls@ietf.org; > >>> Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and- > >> requirements - Working Group Last Call closed > >>> > >>> > >>> > >>> On 25/10/2016 03:40, Loa Andersson wrote: > >>>> Working Group, > >>>> > >>>> > >>>> Our AD and the IESG recommend working in parallel with requirements > >>>> and solutions. The fact is that have been no drafts on solutions. > >>>> Once there is reasonable progress on a solutions document we can > >>>> proceed. > >>> This change of policy by the IESG is something that I think needs wider > >> discussion. > >>> > >>> Sometimes this is right, but other times it is useful to establish the > >> requirements in the absence of a decision on the solution to harden the > >> foundations of the project. > >>> > >>> It is not uncommon for people to game the requirements to give the edge to > >> their preferred solution. In these circumstances, taking an objective look at > >> the requirements and freezing them through publication can help. > >>> Also in some cases there may be a matter of IESG policy that needs to be > >> frozen before important decisions in the solution can be made. > >>> > >>> Now I am not sure that this applies to this specific case, but I am worried > >> about this new IESG policy preventing WGs approaching their problems in the > >> manner that best suits each problem. > >>> > >>> Perhaps a discussion for the open meeting? > >>> > >>> Stewart > >>> > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Oct 28 20:22:12 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1601127076; Fri, 28 Oct 2016 20:22:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147771133072.24855.473657451055721823.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2016 20:22:10 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rfc4379bis-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 03:22:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Authors : Kireeti Kompella George Swallow Carlos Pignataro Nagendra Kumar Sam Aldrin Mach(Guoyi) Chen Filename : draft-ietf-mpls-rfc4379bis-09.txt Pages : 73 Date : 2016-10-28 Abstract: This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. This document obsoletes RFCs 4379, 6424, 6829, and 7537. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-rfc4379bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rfc4379bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 30 15:14:51 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1730B1293FE; Sun, 30 Oct 2016 15:14:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147786569008.20752.11139201439795408176.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2016 15:14:50 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rmr-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2016 22:14:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Resilient MPLS Rings Authors : Kireeti Kompella Luis M. Contreras Filename : draft-ietf-mpls-rmr-03.txt Pages : 14 Date : 2016-10-30 Abstract: This document describes the use of the MPLS control and data planes on ring topologies. It describes the special nature of rings, and proceeds to show how MPLS can be effectively used in such topologies. It describes how MPLS rings are configured, auto-discovered and signaled, as well as how the data plane works. Companion documents describe the details of discovery and signaling for specific protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rmr/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-rmr-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rmr-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 09:16:06 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D9112987C; Mon, 31 Oct 2016 09:16:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147793056419.32381.1264376516165845109.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 09:16:04 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-spring-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 16:16:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane Authors : Nagendra Kumar George Swallow Carlos Pignataro Nobo Akiya Sriganesh Kini Hannes Gredler Mach(Guoyi) Chen Filename : draft-ietf-mpls-spring-lsp-ping-01.txt Pages : 17 Date : 2016-10-31 Abstract: Segment Routing architecture leverages the source routing and tunneling paradigms and can be directly applied to MPLS data plane. A node steers a packet through a controlled set of instructions called segments, by prepending the packet with a Segment Routing header. The segment assignment and forwarding semantic nature of Segment Routing raises additional consideration for connectivity verification and fault isolation in LSP with Segment Routing architecture. This document illustrates the problem and describe a mechanism to perform LSP Ping and Traceroute on Segment Routing network over MPLS data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-lsp-ping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-spring-lsp-ping-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-spring-lsp-ping-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 15:51:23 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64356129B3B; Mon, 31 Oct 2016 15:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKdY2S_xm1EP; Mon, 31 Oct 2016 15:51:19 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 DC789129B7E; Mon, 31 Oct 2016 15:51:17 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id 79so33879845wmy.0; Mon, 31 Oct 2016 15:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:reply-to:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=DN1NVPDSx/HFgpCay9bakk6VnQvoErGUZmOUQ5syYtk=; b=VI4891vdZTnIiXdcD1oIwMQehesrqnFfWtxreWRlMwK1ZXnKF0VjhJUgwjmdDr3Nu9 JickTl6FwRlGmS9QzoOy03SHEQ4CzMZw5XSaI2nJ3H3eeKe1x/U1qY/aZIEPp65cmHhH xSdEGK2++9eY0QPSzQdRry18uLPHCALiF7gejN0lec5kD4g7FQFEAcu10qB53FUBb2d4 bvvtA2luhJun1qsOI/MndJxr89RirfR9ZoQR1ZDiJv4YwfJtCRzkRAa2wqpsPr/YnPpl doyk50Ir4uYhokCWN7xmT2gnQ/grfHgYNcuVpJDrcB4f6THFyri1+5qNEUq1Elb/LZ8j wXog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:reply-to:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=DN1NVPDSx/HFgpCay9bakk6VnQvoErGUZmOUQ5syYtk=; b=RZuSKdWrboqKHb83COJu1dz88RTl6nk+lOebMJ/njL47YF2EtaP2EHo28I1LLlIyx4 bSrHLLbxC5rVrq36jxBILBei1jXCttDLq6LqA/64NVXbGRSwCx6wun6Oia0xUttYVOFr +0Ew/+PvoLq9f5tE5/Z9qXvDgAaTfQqEx4c24qqZr0fmoyMFsnjSBf/Rjqi1ZC1gIlCE 6PqAKIvcqrtN/TRTd8UBvg+K+5I+G/3mgCbciqf9WSlfyv3AVRIH2Sl90pLhReSAHNPk owT66sP3nDYbZao8eo7OaY9SCnza4+fBcI2Zmhj6UVGYAnPtBuZ4fvf6Qh7PRY9/K4E4 xTMw== X-Gm-Message-State: ABUngvcPxWoO+fakGGyu9RZfuYhD/OnQcc6qv343N++X7azksej5a44IRoy6zHkcAQ7Z7Q== X-Received: by 10.194.175.5 with SMTP id bw5mr28189213wjc.158.1477954275446; Mon, 31 Oct 2016 15:51:15 -0700 (PDT) Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id m5sm27153336wmd.17.2016.10.31.15.51.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 15:51:14 -0700 (PDT) References: <76CD132C3ADEF848BD84D028D243C92793503179@NKGEML515-MBX.china.huawei.com> To: Eric Gray From: Huub van Helvoort X-Forwarded-Message-Id: <76CD132C3ADEF848BD84D028D243C92793503179@NKGEML515-MBX.china.huawei.com> Message-ID: Date: Mon, 31 Oct 2016 23:51:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <76CD132C3ADEF848BD84D028D243C92793503179@NKGEML515-MBX.china.huawei.com> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-shared-ring-protection@ietf.org" , "mpls-chairs@ietf.org" Subject: [mpls] Response: Working Group Last Call for draft-ietf-mpls-tp-shared-ring-protection-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:51:22 -0000 Hello Eric,

You write:
 

                The document is much improved, but not quite there yet.

[Huub]  Thank you Eric for the thorough review.

                I have noticed a few NITs in the revised wording that can be dealt with via instructions to the RFC Editor (no action required by the Authors or Contributors unless addressing other issues anyway).

[Huub]  OK. no revision needed.

                I have a pair of minor questions: you now define a “Ring Node” as a node that actively participates in ring protection; this suggests that there might be nodes that either passively participate in ring protection, or do not participate in ring protection – so

-          is it possible for any such node to exist in a ring topology and still have ring protection work correctly?

-          are their well understood requirements of such nodes (my concern is to understand if there is anything that such a node might do that would conceal the link status between Ring Nodes)?

I strongly suspect that there is no hole here, but just want to make sure.

[Huub] All nodes in the ring are Ring nodes and MUST actively participate in
the ring protection. Additional text should make this clear.

[Huub] this will require a revision.


I have had some difficulty in determining if the comments I made earlier are entirely addressed by the changes you’ve made.  I interleave the comments I made and the way they seem to have been addressed below (hopefully nobody in this discussion suffers from red-green color blindness).

[Huub] unfortunately I do have a slight red-green defect, but the difference in
contrast allowed me to see the difference.


Section 5.1 seems to indicate that the protection switching mode is a ring characteristic -

which strongly supports the need for consistency in protection switching mode in a ring.

But I did not see an explicit statement to this effect elsewhere in the document. 

 

I would expect any such statement to occur at the point where the modes are introduced

(i.e. - in section 4.3).

 

-3- the concern regarding the presence of different protection modes is
       removed by including a statement that all nodes in the ring MUST be
       provisioned in the same protection mode.
       To detect possible misconfiguration two bits are used in the RPS PDU
       that identify the protection switching mode which allows detection of
       any mis-configuration during provisioning.

 

This change fully addresses this ambiguity.  I would note that what you actually said in the draft is not quite the same as what you say in the mail below (repeated directly above), because – in the draft – it says that rings on a node “MUST use” (as opposed to “MUST be provisioned in”).  This is a minor point, however, and the draft wording is most likely more correct.

[Huub] OK, no revision needed.

In the Introduction for this draft, you summarize optimization features from RFC 5654 as

follows:

   a.  Minimize the number of OAM entities for protection

   b.  Minimize the number of elements of recovery

   c.  Minimize the required label number

   d.  Minimize the amount of control and management-plane transactions

       during maintenance operation

   e.  Minimize the impact on information exchange during protection if

       a control plane is supported

 

>From RFC 5654, the actual "optimization criteria" are:

 

   a.  Minimize the number of OAM entities that are needed to trigger

       the recovery operation, such that it is less than is required by

       other recovery mechanisms.

   b.  Minimize the number of elements of recovery in the ring, such

       that it is less than is required by other recovery mechanisms.

   c.  Minimize the number of labels required for the protection paths

       across the ring, such that it is less than is required by other

       recovery mechanisms.

   d.  Minimize the amount of control and management-plane transactions

       during a maintenance operation (e.g., ring upgrade), such that it

       is less than the amount required by other recovery mechanisms.

   e.  When a control plane is supported, minimize the impact on

       signaling and routing information exchange during protection,

       such that it is less than the impact caused by other recovery

       mechanisms.

 

The draft does not identify the list provided as a summary of the correlated "optimization

criteria" from RFC 5654, and the summarized versions leave a lot of information out. 

 

This could be misleading and it would be useful to suggest to a reader that they might look a

at the actual criteria in RFC 5654 for more information.

 

As an example of "missing information," the summarized versions do not indicate to what

we would compare the minimizations in this draft to determine that they achieve their

(ambiguous) goals (i.e. "such that [the characteristic being minimized] is less than [that

same or similar characteristic] for other recovery mechanisms").

 

Additional "missing" information includes:

  a. "needed to trigger recovery" as opposed to "for protection."

  b. "in the ring" (possibly not important).

  c. "number of labels required for the protection paths across the ring" as opposed to

      "required label number" (remember that - to some people - labels are numbers).

  d. an example is given of a maintenance operation (possibly not important).

  e. "signaling and routing information exchange" as opposed to "information exchange."

 

Minimally, some wording improvements are required to align the text in this draft with the

corresponding text in RFC 5654.

=====

In the second paragraph after bullet "e" on page 4, you state that "the solution for

point-to-multipoint transport paths is under study and will be presented in a separate

document."  It is generally not a good idea for an Internet Draft to attempt to predict

what may or may not happen in documents that are as yet unwritten.  It is sufficient

to say that "a solution for anything other than point-to-point transport paths is out of

scope in this document"  (specifically - replace "under study and will be presented in

a separate" with "out of scope in this").

 

Note that this means this document does not satisfy Requirement 95 from RFC 5654.

=====

When I see a statement along the lines of "This document elaborates on the requirements

in detail" - my immediate concern is that what might actually happen is that requirements

are going to be "restated" in some way that supports a new (or different) interpretation or

agenda.

 

Please make it clearer what the intentions are for this document with respect to RFC 5654.

 

The Introduction claims that this document addresses ring protection requirements in

RFC 5654, yet - once we get into section 2, we jumps right over requirements 92-104A

to address the requirement that the protection mechanisms SHOULD protect against

multiple failures.  Why is that? 

 

Perhaps the authors are already aware of an obvious set of mechanisms that satisfy

these earlier requirements (many of which are ones that MUST be met) and it is then

only necessary to delve more deeply into mechanisms that further satisfy this

"SHOULD" be met requirement? 

 

If so, say so. 

If not, then provide some justification for why you want to address this somewhat soft

requirement first.

=====

Where - in RFC 5654 - does it state "recovery mechanisms which are optimized for ring

topologies could be further developed if it can provide the following features" (I couldn't

discover that the word "developed" was used at all in RFC 5654, for instance)?  What it

seems to say is that the recovery mechanisms applicable to generic recovery may be

optimized for specific topologies provided the optimizations meet the stated criteria,

and satisfy somewhat vague "cost-benefit" considerations.  Perhaps you meant to say:

"recovery mechanisms could be further optimized for ring topologies if those further

optimizations meet the following criteria" (or something along these lines)?

=====

The first paragraph after bullet "e" on page 4 is awkward; I suggest replacing "those" with

"the.” Also note that the wording could use some minor improvement to avoid giving the

impression that the preceding list of "criteria" is not what you are referring to here as

"requirements on ring protection listed in RFC 5654."  Perhaps stating the actual number

range (i.e. - 92-94 and 96-109) of requirements this document addresses; or is the list of

requirements this draft aims to address shorter than this?

=====

Which requirements from RFC 5654 are addressed in section 2.2 (can you identify them

as part of this section).

====

Which requirements from RFC 5654 are addressed in section 2.3 (can you identify them

as part of this section).

 

-2- the referencing to RFC5654 has been improved

 

What it looks like in comparing the two documents is that – for your first step – you have removed the summary versions of the optimization requirements.  This is one (and most likely the simplest) way to get rid of inconsistencies.

 

You then go on to be a lot more explicit about which requirements this document is specifically addressing.  This fully addresses my comments with respect to RFC 5654.  It also – incidentally – eliminates a few grammatical NITs.

 

Note that this took some looking into, because (for instance) of the way that you have re-ordered sections 2 and 3, thus requiring a detailed review of both the old and the new text to determine the real changes.

[Huub] OK, resolved, no revision needed.

Figure 1 (or at least part of the text describing it) appears to apply only to the ingress port

for Ring Tunnels; at an egress port, it is not a question of the port "can carry" multiple ring

tunnels, because it _does_ carry exactly 4 (per description in section 4.1.1).

 

As near as I can tell, you did not identify how the above comment was addressed.  The wording appears to have been changed in minor ways.  From this set of minor changes, it looks as if we are not necessarily talking about the same thing as “a port.”  I think I understand what you mean in your wording, now, so I feel this comment is adequately addressed by the minor changes made.

[Huub] OK, no revision needed.

 

Having defined a notation for "label stack" in section 3, section 4 then falls back to a more

traditional notation.  Is there a reason why you do not use the same notation consistently?

Should you maybe include the possibility that the more traditional notation might also be

used when defining a different notation in section 3?

 

The way I understand the notation defined in section 3, the label stack in figure 2 would be

shown as -

 

                [ Ring Tunnel Label | LSP Label | PW Label ] Payload

 

- which seems simpler than the way it is currently depicted.

 

Again, as near as I can tell, you did not identify how this comments was addressed.  However, I see that you now use both notations, making it at least obvious how one maps to the other, therefore I feel that this comment is fully addressed by your changes.

[Huub] OK, no revision needed.

Perhaps you should look again at the notation text in section 3.  One notation that you appear

to be actually using is for an egress "<X>" to define 4 tunnels as:

                RcW_<X>

                RaP_<X>

                RaW_<X>

                RcP_<X>

 

For the first "reverse hop" in each tunnel, there is a label assigned by the egress corresponding

to that tunnel.

 

If you then construct a label-stack along the lines of the one above, the "Ring Tunnel Label"

would be whatever label corresponds to one of the above 4 tunnels (for that "hop" it might

be unnecessary to use parentheses to add the "Node Name" of the assigning node to the

label stack).

 

For each subsequent "reverse hop", the label could presumably be assigned by the downstream

end of the "hop" and the assigning node would be the same for RcW_<X> and RcP_<X> (the node

that is one "hop" clockwise from <X>), and a (probably different) assigning node would be the

same for RaW_<X> and RaP_<X> (the node that is one "hop" counter-clockwise from <X>).

 

In any case, the notation used to name Ring tunnels is not described in section 3.

 

I assume that how LSP labels and PW labels are assigned is out of scope for this draft.

 

I see no indication that this comment has been addressed.  Most of it was intended as a suggestion, hence addressing those portions was not absolutely necessary.

 

I do, however, feel that section 2 (the re-ordered section that now addresses Notation) should include the way that tunnel naming in section 4.1.1 is derived (see the accentuated part of the comment repeated above).

[Huub] the Ring Tunnel naming convention should be added to section 2.
this requires a revision


The wording in section 4.1.3 is unclear; because you have not described the mapping for Ring

Tunnel Labels at each hop, it is not clear what it means when the "ingress node on the ring

pushes the working ring tunnel label according to the egress node" (chances are pretty good the

actual label pushed on by the Ring Tunnel ingress may not be the same label that was assigned

for the Ring Tunnel by the tunnel egress node (unless the particular tunnel is one "hop" from the

ingress to the egress node, or the labels are configured that way for all tunnels at all ring nodes

- which may not be possible).

 

Section 4.1.2 should probably say a little bit more about assignment of Ring Tunnel Labels at

each transit node in the ring.

 

Again, as near as I can tell, you did not identify how this comments was addressed.  However, I see that the wording in question has been clarified.  This comment is fully addressed by your changes.

[Huub] OK, no revision needed.

What is meant in section 4.2 by "Two end ports of a link"?  I assume this means the ports that are

used to connect two adjacent nodes on a ring, but "end ports" makes this unclear.

 

Again, as near as I can tell, you did not identify how this comments was addressed.  However, I see that you removed the word “end” and this should reduce the possibility for misinterpretation. This comment is adequately addressed by the minor change made.

[Huub] OK, no revision needed.

There are issues with use of (or non-use of) normative language in section 4.3.  Is it the case that

every node MUST obtain the ring topology (currently it says "can")? 

 

This seems important because it is not at all clear that ring-topology awareness is required to

support either wrapping protection mode (this assumes that protection mode is required to be

consistent in a ring), since it seems that wrapping occurs at points where the ring is broken,

irrespective of the ring topology otherwise.

 

Where is there a statement to the effect that the protection switching mode in a single ring MUST

be consistent?

=====

For Steering (section 4.3.3), there are a few places where the description might be easier to follow

if there was a term (or expression) for "the ring node on which an LSP enters the ring" - since this is

(as I understand it) the ONLY ring node where the location of the failure determines which ring the

LSP traffic will be forwarded on.

 

There may be an unwritten assumption associated with the use of Steering protection switching

mode - that is particularly obvious in the 2nd paragraph.  As I understand it, Steering mode is the

only mode where ring topology information is needed by every ring node. 

 

This seems to be the case because steering mode is the only mode where the decision as to which

ring to use in forwarding LSP traffic is made at each node depending on where that node is in the

ring and where in the ring the failure has occurred.  For the wrapping modes, the traffic is placed

on the working ring by each node and only moved to a protection ring by the ring node directly

adjacent to the link or node failure.

 

However, with respect to knowledge of ring-topology information, the draft says only that this

information is either configured or learned "via some topology discovery mechanism" (in the 2nd

paragraph, section 4.3).

 

If it is the case that ring-topology awareness is only explicitly required for steering mode, then the

assumption that this information is known should be explicitly stated here (if - as does not seem

very likely, or possibly not necessary - this information is explicitly required for all modes, then that

should be made explicit in the use of normative language in section 4.3).

 

This was (in part) addressed by the addition of a requirement for consistent protection modes in a ring.  With that, and the change from “can” to “MUST” and other clarifying text throughout section 4, this comment is fully addressed by your changes.

[Huub] OK, no revision needed.

There were a number of relatively minor comments/questions which I don’t believe have been answered or addressed:

What does it mean to have no protection switching active on a ring (perhaps you mean no protection

switching in effect)?  Or is this something that is a common understanding among operators (i.e. - if

protection switching is "active" this means that the protection switching mechanisms enabled are in

use as a result of a failure)?

What exactly is a "failed span?"

Here it would be good to know if there is a difference between a “span” and a “link.”  If there is no difference, then why not use the same term?  If there is a difference, perhaps it should be defined in the terminology section.  Based on usage in the draft, I suspect there is a difference between a “span” and a “link.” 

[Huub] because there is no difference between "span" and "link" I suggest to
replace all occurrences of "span" by "link". A revision is needed.

What does it mean to say that "Ring switches MUST be preempted by higher priority RPS requests?"

I assume this means that it must be possible to change the protection switching state as a result of a

higher priority RPS request - but this is not necessarily obvious.

 

In the last paragraph of section 5.1 (immediately before section 5.1.1), you say that "nodes do not

preempt existing RPS requests unless they have a higher-priority RPS request."  Further, you imply

that "knowledge of the state of the ring" is required to make this determination. 

 

Exactly how does a ring node make this determination?  A ring node can make direct comparisons

between an incoming RPS message type/priority and the RPS message type/priority it would make

based on local knowledge of the ring - but this does not require "knowledge of the state of the ring"

only knowledge of local ring-state.

 

Moreover, "knowledge of the state of the ring" is often less than perfect, if meant to apply to remote

portions of the ring (an incoming RPS message is likely to reflect better knowledge of the ring-state

than the ring node would otherwise likely have).

 

The set of questions above is both complicated and inter-related.  The main thrust of the issue is that Ring Nodes only know what they know about the state of the ring based on the most recently received set of RPS messages.  This information may be temporarily incorrect and there is no way for a Ring Node to know if this is (or is not) the case.  I am not certain that the text in section 5 properly addresses how a deterministic state is necessarily arrived at independent of the order in which RPS messages are received. 

 

By having a strict prioritization between state indications, it should be the case that the “final” state arrived at would be deterministic based on an assumption that the RPS messages will provide a consistent “state of the ring” within some period of time (because all ring nodes should agree as to which indication has the highest priority).

[Huub] we understand your point, we propose to remove the sentence:

"nodes do not preempt existing RPS requests unless they have a higher-priority RPS request."

because it is actually the same as:

"Ring switches MUST be preempted by higher priority RPS requests?"

also we suggest to replace the sentence:

"knowledge of the state of the ring"

by "use their ring map to determine the state of the ring"

A revision is needed.

=====

For section 5.1.1 - exactly how is the recommended interval between RPS message reflecting new

information determined?  I can see that having an interval of 3.3 milliseconds would result in having

sent 3 of them in slightly less than 10 milliseconds, but this may not be particularly relevant in the

goal of a 50 millisecond protection switch completion if the mechanism is relying on RPS propagation

around the ring the long way in order to detect a unidirectional link failure.

===

On page 28, what does this paragraph mean?

 

"When multiple MS RPS requests over different spans exist at the same time, no switch SHOULD be

executed and existing switches MUST be dropped.  The nodes MUST signal, anyway, the MS RPS

request code."

 

After looking a bit, "MS" probably means "Manual Switch" and this would imply that the effect of

having multiple manual switch commands should be that they nullify each other.  But what is the

expected behavior if there are multiple manual switch commands in a ring and a ring node sends

a "Signal Fail"  RPS message?

As near as I can tell, none of these comments and/or questions have resulted in any changes.

Possibly the questions were answered in separate E-Mail which I have not yet uncovered.  While I believe I know what (at least some of) these terms mean, it is important to have this knowledge exist somewhere other than in the minds of experienced operators and people (vendors, operators and standards developers) with SONET/SDH experience/awareness.

If the authors all feel that there is no ambiguity, need for further clarification or related issues with the way these issues are  currently addressed/specified, I am happy to withdraw these questions and comments at least until such time as I have a better understanding of the issues.

[Huub] if the MS (manual switch) comes from the same node, clockwise and
anticlockwise it should become active, if there is no higher priority  request
active. If they come from different ring nodes they should be ignored.

[Huub] this clarification requires a revision

Section 6 - in effect, this section determines  the value assignments that will be used in the rest of

the document.  Therefore, the statement that "new values" are "defined in this document and

summarized in this section" is not quite correct (because it implies that they are defined elsewhere

in this document and then summarized here).  I suggest replacing " and summarized in this section"

with "listed in the sections below" so that it would now read:


"IANA is requested to administer the assignments of new values defined in this document and listed

in the sections below."

 

I will grant you that this seems a minor point; the code points are defined here and their meaning

and use is defined elsewhere in the document.  But this section is about the code points and the

need for IANA to create registries as needed and record these assignments.  Everything that IANA

needs MUST be _included_ (not summarized) here.

This comment was fully addressed in this version.

[Huub] OK, no revision needed.

Many NITs were not addressed:

"()" Are called "parentheses" - now in section 2 (previously in section 3).

"At the egress node, the traffic leave the ring ..." - "leave" should be "leaves" (even though "traffic"

may be (and often is) plural, it is a group name (like "herd") so if it is in the singular form, that is what

the verb ("leave" in this case) has to match.

Similar for the case with "... following sections describes ..." (should be "... following sections describe

...").

So far, these are minor issues, and may be corrected by the RFC Editor.

[Huub] OK, we can leave it to RFC editors, but since a revision is needed we can fix these

As a question on how the following NIT was addressed:

Section 4.3.1 - "... tunnel can protect both the link failure and the node failure" should probably be "...

tunnel can protect against either a link failure or a node failure."

The text now reads: “protect both link failures and node failures.”

Intuitively, this seems incorrect, because (intuitively) we don’t “protect” failures (we protect services against failures).  I assume the authors chose this phrasing because (in this context) the meaning for “protect” differs slightly from the intuitive English meaning.  Is this correct?  If so, we might want to add “Protect” to the terminology section as well.

[Huub] the proper text is: "protect against both link failures and node failures"

a revision is needed

Section 4.3.2.1 - in the 4th sentence, "Rap_D" should be "RaP_D."

While this one may be corrected via instructions to the RFC Editor, this is not so much a spelling error as a Notation error and may not otherwise be picked up by the RFC Editor.

[Huub] can be changed in a revision

Section 4.3.3 - 1st sentence, "perform" should be "performs."

Top of page 26, 2nd paragraph - "resulting the ring being ..." should probably be "resulting in the

ring being ..." (now the 4th paragraph, from the top of page 25).

[Huub] indeed, we agree, it can be fixed in a revision

In section 5.1.3.2, "... to adjacent node ..." should probably be "... to adjacent nodes ..."

To be more specific, the 1st sentence in the section “A node in the switching state MUST source RPS request to adjacent node with its highest RPS request code in both directions when it detects a failure or receives an external command.”  When sourcing RPS messages in both directions I believe more than one node will be the target for the RPS request (except in the trivial case of a “ring” consisting of two nodes).

[Huub] I suggest to remove "to adjacent node" from the sentence, because the RPS request
has to be forwarded to all ring nodes.

This requires a revision

On the last line on page 28, "Node" should probably be "The node." (Now the last line before section 5.1.3.3 – though still on page 28)

A few NITs I missed previously:

In section 4.3, paragraph at the top of page 10, “impaced” should be “impacted” and “perform switching” should be “performs switching” (“the ingress node … performs switching …”).

[Huub] these can be fixed in a revision (or by the RFC editors).

--

Eric

We hope that we addresses all your comments this time.

Because text has to be added/changed we think a revision is required.

Best regards, Huub