From nobody Tue Apr 3 00:14:12 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 067C91201FA; Tue, 3 Apr 2018 00:14:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-i2rs-rib-info-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152273965001.13971.7531466101349529801.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 00:14:10 -0700 Archived-At: Subject: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 07:14:10 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Even if just Informative, it would be nice to have a reference to draft-ietf-i2rs-rib-data-model. (2) I think that the use of some Normative Language is not as expected. (2.1) For example, in S2.1 (RIB definition): "There MAY be many routing instances and each routing instance MAY contain RIBs." In both cases "MAY" seems to be a statement of fact, and not a normative statement to indicate that a routing instance can optionally include RIBs. Note that S2.2 (Routing instance) identifies a rib-list as a mandatory component of a routing instance, and there's no clear indication that the list may be empty. (2.2) S2.1: "A routing instance MAY even have two or more RIBs of the same rib family (e.g., IPv6)." This use of "MAY" also seems to be stating a fact. (2.3) "MAY be optionally", "MAY contain the following optional fields" are redundant phrases as MAY already means optional. From nobody Tue Apr 3 00:15:08 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E03C712E741; Tue, 3 Apr 2018 00:15:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-i2rs-rib-data-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152273970691.14068.10044402717032917231.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 00:15:06 -0700 Archived-At: Subject: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 07:15:07 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) "This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model." That and the multiple references to the information model (in the text and on the e-mail archive) make it a required document to understand for the implementation of the data model. draft-ietf-i2rs-rib-info-model should then be a Normative reference. I am not making this point a DISCUSS because I think it is easy to solve: just move the reference. (2) In Figure 1: s/route-reason-definition/route-change-reason-definition (3) For completeness: in S2.3, the Reason attribute is missing (from S4 in draft-ietf-i2rs-rib-info-model). From nobody Tue Apr 3 04:40:31 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D1F12E89E; Tue, 3 Apr 2018 04:40:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ignas Bagdonas To: "The IESG" Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 04:40:29 -0700 Archived-At: Subject: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 11:40:30 -0000 Ignas Bagdonas has entered the following ballot position for draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-topology/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have concerns about the practical usability of this proposed model as it is specified now. The intended decoupling of fabric implementation properties (what is termed as "underlay network infrastructure" in the document) and its topology seems to be contradicting to general operational practices of fabric based networks. It is generally true for the context of the overlay but that is not what the document seems to be focusing on. Fabric defines and implements the underlay, not the other way around. The document does not contain a sufficient description of the logic of the model itself, the reasons for choices made for representation of types and attributes, and at the same time descriptions in modules are single lines that do not add clarification beyond being copies of leaf names. Either there needs to be a section that describes the logic of the model and how it relates to other models, also including examples, or module description fields need to have enough content to be able to have equivalent understanding of model intent and operation. Both are strongly encouraged, as descriptions have value of itself for being a reference for use, and model description is needed for understanding how this particular model fits into the larger hierarchy. Network management does not end at the boundary of the single domain-specific model, it is important to build it into a whole system. Why TE topology model is not sufficient for modelling the representation of DC fabric? Why is DC fabric network topology special compared to any generic fabric based topology? How this model could be used for representing more than two stage fabrics that are in wide deployment? Limiting port bandwidth to a fixed rate is too restrictive. The model as specified already does not cover a set of port speeds that are in deployment. How would a device that has more than a single role in the fabric be represented? Service capabilities as they are described belong to the overlay context while they are called device capabilities. Are those the only possible service capabilities? What is the effect of configuring those capabilities? What is compose-fabric RPC? The document does not define any RPCs. What is policy driven traffic behavior? Is there the only one policy that fits all possible deployment scenarios? Looking at the history of the document from the individual submission time and the comments received, it seems that the point fixes to the text went in to cover the specific comments but not to address the broader scope of comments. The document would definitely benefit from a major rewrite clarifying the logic behind the decisions made, aligning more with the operational practice of fabric based network design and deployment, and bringing the content in YANG modules to be self-describing. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Fabric and POD are not equivalent terms. I2RS use case requirements document has expired 11 months ago. Use cases documents are good for tracking the work progress of specification documents, it is questionable whether standalone use cases documents provide value beyond historic record. Is the reference to I2RS use cases document really needed? What is atomic network? VLAN is not a fabric building technology as such, while Ethernet is. What is the need for VNI capacity leaves? What is their effect if configured? The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces. Serial port-type is present while Infiniband is not - Infiniband based fabrics are widely deployed. What is the extensibility mechanism for adding in new port types? Is there any deployment experience with this model? The ODL faas project hasn't got much activity over last two years. Are you aware of any other implementations or deployments? From nobody Tue Apr 3 06:59:27 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E2F12E8F1; Tue, 3 Apr 2018 06:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 JkwIJUADIe55; Tue, 3 Apr 2018 06:59:24 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 9E90F1201F8; Tue, 3 Apr 2018 06:59:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Ignas Bagdonas'" , "'The IESG'" Cc: , , References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> In-Reply-To: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> Date: Tue, 3 Apr 2018 09:59:10 -0400 Message-ID: <006401d3cb53$f17c36d0$d474a470$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrfpTnkeJxdov8ELnNq0f+qOuaSqO/m8Vg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 13:59:26 -0000 Ignas: Yan will answer for the authors but I would like to share some = information related to the I2RS working group reviews. In your = response, please specify why each question is a "DISCUSS" quality = question rather than a "Comment" question. The authors and I (as the = shepherd) will work to resolve both DISCUSS and comment issues. =20 Let me review only 5 of your many points because they are pointing in a = direction which is different from earlier QA reviews of this document = (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 timeframe. =20 1st - Why TE topology model is not sufficient for modelling the = representation of DC fabric? Why is DC fabric network topology special = compared to any generic fabric based topology? This document was reviewed by authors with the TE topology models to = make sure there was no conflict or duplication. =20 Your question implies that only one yang model is appropriate for each = type of fabric. This theory of one yang mode per fabric does not apply = to dynamic (ephemeral) datastore versus configuration datastore models. = It is also not true of all models even within the configuration = datastore. Since there is a yang catalog and selection of yang models is = specific to a implemented, there has been no early winnowing of the yang = models per type. If you are insisting on this theory of "one yang = model" per fabric type, please provide an RFC reference so that I can = help review this DISCUSS criteria with the authors.=20 This yang model has been implemented by 1 vendor, and there was interest = by other vendors. A deployment target has been identified for this = model, and feedback is expected from the users.=20 If you are asking this model to cover three-four layer datacenters, this = approach is opposite some of the initial feedback to the group to keep = the initial model - that is to keep it simple and restricted to 2 layers = in order to test the concepts. If you are asking to provide text (in = introduction or appendix) that indicates the initial focus, this can be = added.=20 2nd - Multiple layers and multiple roles. =20 The authors provide slides in several meetings I2RS meeting repository = regarding this point.=20 The initial feedback suggested reducing the "why" text within the draft. = Again, the initial feedback was to reduce the initial model's text to = 2 layers and simple "whys". See proceedings from IETF 95 forward on = I2RS on fabric data model for discussions.=20 3rd - The authors will comment on the port restrictions. Early feedback = during the I2RS meetings from vendors may have taken the authors down = this path. In my review, I expect major issues in this area - but I = will let the authors comment.=20 4 - policy is simple.=20 Again, the initial feedback was to keep initial policies simple and gain = feedback from the deployments.=20 5 - You indicate that the document requires a "major" rewrite clarifying = the logic.=20 Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested = taking out the lengthy descriptions regarding logic and history. If we = are switching the rules for the YANG models, would you please update the = requirements for the YANG models so that shepherds, rtg-dir, ops-dir, = and yang-doctors can have rules for review clearly spelled out.=20 Summary on Shepherd's comment: =20 The authors will respond to others specifics, but in order to guide = these diligent authors - I need to know what rules you are setting for = the 2018 IESG approval of YANG models. If you are placing a DISCUSS on = a YANG model based on a set criteria, the criteria needs to be published = on a web page or in an RFC. If I've missed this criteria that the OPS = Area has specified,=20 Thank you for your review,=20 Susan Hares=20 -----Original Message----- From: Ignas Bagdonas [mailto:ibagdona@gmail.com]=20 Sent: Tuesday, April 3, 2018 7:40 AM To: The IESG Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan = Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Ignas Bagdonas' Discuss on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = COMMENT) Ignas Bagdonas has entered the following ballot position for draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-t= opology/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have concerns about the practical usability of this proposed model as = it is specified now. The intended decoupling of fabric implementation properties (what is = termed as "underlay network infrastructure" in the document) and its = topology seems to be contradicting to general operational practices of = fabric based networks. It is generally true for the context of the = overlay but that is not what the document seems to be focusing on. = Fabric defines and implements the underlay, not the other way around. The document does not contain a sufficient description of the logic of = the model itself, the reasons for choices made for representation of = types and attributes, and at the same time descriptions in modules are = single lines that do not add clarification beyond being copies of leaf = names. Either there needs to be a section that describes the logic of = the model and how it relates to other models, also including examples, = or module description fields need to have enough content to be able to = have equivalent understanding of model intent and operation. Both are = strongly encouraged, as descriptions have value of itself for being a = reference for use, and model description is needed for understanding how = this particular model fits into the larger hierarchy. Network management = does not end at the boundary of the single domain-specific model, it is = important to build it into a whole system. Why TE topology model is not sufficient for modelling the representation = of DC fabric? Why is DC fabric network topology special compared to any = generic fabric based topology? How this model could be used for representing more than two stage = fabrics that are in wide deployment? Limiting port bandwidth to a fixed rate is too restrictive. The model as = specified already does not cover a set of port speeds that are in = deployment. How would a device that has more than a single role in the fabric be = represented? Service capabilities as they are described belong to the overlay context = while they are called device capabilities. Are those the only possible = service capabilities? What is the effect of configuring those = capabilities? What is compose-fabric RPC? The document does not define any RPCs. What is policy driven traffic behavior? Is there the only one policy = that fits all possible deployment scenarios? Looking at the history of the document from the individual submission = time and the comments received, it seems that the point fixes to the = text went in to cover the specific comments but not to address the = broader scope of comments. The document would definitely benefit from a major rewrite clarifying = the logic behind the decisions made, aligning more with the operational = practice of fabric based network design and deployment, and bringing the = content in YANG modules to be self-describing. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Fabric and POD are not equivalent terms. I2RS use case requirements document has expired 11 months ago. Use cases = documents are good for tracking the work progress of specification = documents, it is questionable whether standalone use cases documents = provide value beyond historic record. Is the reference to I2RS use cases = document really needed? What is atomic network? VLAN is not a fabric building technology as such, while Ethernet is. What is the need for VNI capacity leaves? What is their effect if = configured? The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces. Serial port-type is present while Infiniband is not - Infiniband based = fabrics are widely deployed. What is the extensibility mechanism for = adding in new port types? Is there any deployment experience with this model? The ODL faas project = hasn't got much activity over last two years. Are you aware of any other = implementations or deployments? From nobody Tue Apr 3 08:09:58 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2245F120724; Tue, 3 Apr 2018 08:09:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-i2rs-rib-data-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 08:09:56 -0700 Archived-At: Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 15:09:56 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sec 1.2: "YANG tree diagrams provide a concise representation of a YANG module, and SHOULD be included to help readers understand YANG module structure." This document does not seem like an appropriate place to have normative guidance about this. And if this sentence is removed, I don't see the point of including Section 1.2 otherwise. This would also imply deleting the reference to I-D.ietf-netmod-yang-tree-diagrams. Sec 2.1: Again here I'm confused about the use of normative language. Why do you need to specify normative requirements for what this very document is specifying? Or are these supposed to be requirements on implementations? Sec 2.5: s/causes/caused/ From nobody Tue Apr 3 08:10:47 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014F8120724; Tue, 3 Apr 2018 08:10:46 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=QeUUBcZH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=g9XcarMK 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 A2cuKjG_iPF3; Tue, 3 Apr 2018 08:10:44 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C661127876; Tue, 3 Apr 2018 08:10:44 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5CDBE21A94; Tue, 3 Apr 2018 11:10:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 03 Apr 2018 11:10:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=1L8fd6gsHmQd5ILepvZPUPQZf48gQ 7vOniwulsVS1cE=; b=QeUUBcZHxOlVufFn2Si5vsyO0dJMrH1tSF+I1iSaEH3Fp 6q9fQV6nOsdGzJJzM3VfGEsBDWiFZ9lDq7TkbRdNdg1SqZB3S+ivS4DO0qXC67tT lxKbJk1ShZDyt5OQhx+WBwx2f2vauJstRMU4KWhh7CjgqowAA+lL0XVMZ499hZtj 9ug1Sg0IUXCvvXC9uJ7YZp2Cxb4EzoEpbAHiTAYpl5qrf61fJGlhnb++be0ffBjQ pggFOfo1m1UgfhR3td2c1ATt6nX2rljcAZJSLGeFrFyNl8IEHxWQ9C53Mo2MNCL7 JukOKYzYFj1K9cjj/KNHg1N96MBEgGpuHQblk2kAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1L8fd6 gsHmQd5ILepvZPUPQZf48gQ7vOniwulsVS1cE=; b=g9XcarMKpNqhhyzTgxDhj5 SQZ1FE6EcC94Hqf8g+s3A8INaR5hLWUomSpp2PQrgEu7vGnIalGP+/0GPToP4C1X oFZmE6DGh8NIKrCdp8hx2JSPVH8VMkoJvwpUwE9rZCXtXzAqCIl+vzth3Ra6yR/e 2XtV1tGGNDii2/XOn+dC2kpoTm4dbsqqfv6CzIxDFNbB3W7yWGAsKjPHdDpOgmVX Y7YnkxJDLyasxhCVlglj1s++Ro+ETxVs3YPk60XxpK0lwmgvTqbr7X9Ilf/vX3pE MUq16tWPsnpLfij0L7vAFBi8Z4rnk2v9bfF0r7zHZnNVR3DaZb7IX1xCCY98KF4A == X-ME-Sender: Received: from rtp-alcoop-nitro3.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id C8E37E444F; Tue, 3 Apr 2018 11:10:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <152001549820.15735.17467223319832721576@ietfa.amsl.com> Date: Tue, 3 Apr 2018 11:10:41 -0400 Cc: gen-art@ietf.org, i2rs@ietf.org, draft-ietf-i2rs-rib-data-model.all@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <067FAB93-D811-41F1-96EC-44715E6F6365@cooperw.in> References: <152001549820.15735.17467223319832721576@ietfa.amsl.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [i2rs] [Gen-art] Genart telechat review of draft-ietf-i2rs-rib-data-model-10 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 15:10:46 -0000 Stewart, thanks for your review. I have entered a No Objection ballot. Alissa > On Mar 2, 2018, at 1:31 PM, Stewart Bryant = wrote: >=20 > Reviewer: Stewart Bryant > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-i2rs-rib-data-model-10 > Reviewer: Stewart Bryant > Review Date: 2018-03-02 > IETF LC End Date: 2018-03-30 > IESG Telechat date: 2018-04-05 >=20 > Summary: Read this from the perspective of a generalist rather that as = a > routing specialist in the expectation that other routing specialist = would read > the YANG model in detail and compare it to the text and there = experience of > operational routers. =46rom that perspective this seems ready to be = published. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: None >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Apr 3 08:23:30 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B14A12E8EE; Tue, 3 Apr 2018 08:23:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152276900356.22779.183636309853823201.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 08:23:23 -0700 Archived-At: Subject: [i2rs] Alexey Melnikov's No Objection on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 15:23:24 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-topology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nit: 1. Introduction These fabrics may be heterogeneous due to implementation of different technologies when a DC network is upgraded or new techniques and features are enrolled. enrolled --> rolled out? From nobody Tue Apr 3 13:29:37 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA3F12D870; Tue, 3 Apr 2018 13:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JD1HeD42H9X; Tue, 3 Apr 2018 13:29:35 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE42128C0A; Tue, 3 Apr 2018 13:29:35 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id B5F341AE0312; Tue, 3 Apr 2018 22:29:33 +0200 (CEST) Date: Tue, 03 Apr 2018 22:29:33 +0200 (CEST) Message-Id: <20180403.222933.530851196105443807.mbj@tail-f.com> To: shares@ndzh.com Cc: ibagdona@gmail.com, iesg@ietf.org, i2rs@ietf.org, draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, i2rs-chairs@ietf.org From: Martin Bjorklund In-Reply-To: <006401d3cb53$f17c36d0$d474a470$@ndzh.com> References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:29:37 -0000 Hi, Just a quick comment on the YANG doctor's review. "Susan Hares" wrote: > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested > taking out the lengthy descriptions regarding logic and history. It is very common that the YANG doctor review ask for *more* details in the descriptions. In general, we want the module to have as much explanatory text as possible. So was the case for the YD review for this document as well; the YD wrote "The descriptions in all YANG Modules are very short/terse." That was for the -02 version, and even the -00 version did not contain lengthy descriptions AFAICT. /martin From nobody Tue Apr 3 13:53:24 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDCD12D873; Tue, 3 Apr 2018 13:53:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-i2rs-rib-data-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152278880325.22755.1173290118932460025.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 13:53:23 -0700 Archived-At: Subject: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:53:23 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alissa's comment. A couple nits: In Section 2.6: Nexthops can be fully resolved or an unresolved. I don't think the "an" is needed. In the module itself: typedef nexthop-lb-weight-definition { type uint8 { range "1..99"; } description "Nexthop-lb-weight is used for load-balancing. Each list member MUST be assigned a weight between 1 and 99. The weight determines the proportion of traffic to be sent over a nexthop used for forwarding as a ratio of the weight of this nexthop divided by the weights of all the "sum of the weights", presumably. nexthops of this route that are used for forwarding. To perform equal load-balancing, one MAY specify a weight of 0 for all the member nexthops. The value 0 is reserved for equal load-balancing and if applied, MUST be applied to all member nexthops."; } Also, there's a mismatch between the MUST (1-99) and MAY (0). From nobody Tue Apr 3 13:54:41 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069A812D873; Tue, 3 Apr 2018 13:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 nEsPkUkxL7aQ; Tue, 3 Apr 2018 13:54:32 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3D65712706D; Tue, 3 Apr 2018 13:54:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Martin Bjorklund'" Cc: , , , , References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <20180403.222933.530851196105443807.mbj@tail-f.com> In-Reply-To: <20180403.222933.530851196105443807.mbj@tail-f.com> Date: Tue, 3 Apr 2018 16:54:15 -0400 Message-ID: <018101d3cb8d$edef8140$c9ce83c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrfpTnkeJxdov8ELnNq0f+qOuaSgCz2sVuAZ2IZAWjrZNJ0A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:54:34 -0000 Martin: Thank you for the comments on the Yang doctors. The discussion reference was in the introductory material and not in the descriptions in the YANG text. Do you also want additional comments in the introductory section? Sue Hares -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Tuesday, April 3, 2018 4:30 PM To: shares@ndzh.com Cc: ibagdona@gmail.com; iesg@ietf.org; i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) Hi, Just a quick comment on the YANG doctor's review. "Susan Hares" wrote: > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested > taking out the lengthy descriptions regarding logic and history. It is very common that the YANG doctor review ask for *more* details in the descriptions. In general, we want the module to have as much explanatory text as possible. So was the case for the YD review for this document as well; the YD wrote "The descriptions in all YANG Modules are very short/terse." That was for the -02 version, and even the -00 version did not contain lengthy descriptions AFAICT. /martin From nobody Tue Apr 3 14:57:22 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2046112D880; Tue, 3 Apr 2018 14:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqqOp7bor7Mj; Tue, 3 Apr 2018 14:57:05 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 45E6B12D87F; Tue, 3 Apr 2018 14:57:02 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 5EA641AE0312; Tue, 3 Apr 2018 23:57:00 +0200 (CEST) Date: Tue, 03 Apr 2018 23:57:00 +0200 (CEST) Message-Id: <20180403.235700.1271525554065963758.mbj@tail-f.com> To: shares@ndzh.com Cc: ibagdona@gmail.com, iesg@ietf.org, i2rs@ietf.org, draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, i2rs-chairs@ietf.org From: Martin Bjorklund In-Reply-To: <018101d3cb8d$edef8140$c9ce83c0$@ndzh.com> References: <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <20180403.222933.530851196105443807.mbj@tail-f.com> <018101d3cb8d$edef8140$c9ce83c0$@ndzh.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 21:57:07 -0000 "Susan Hares" wrote: > Martin: > > Thank you for the comments on the Yang doctors. The discussion reference > was in the introductory material and not in the descriptions in the YANG > text. Do you also want additional comments in the introductory section? No. The comment was just about the YANG module. You wrote: > > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG > > suggested taking out the lengthy descriptions regarding logic and > > history. If we are switching the rules for the YANG models, would > > you please update the requirements for the YANG models so that > > shepherds, rtg-dir, ops-dir, and yang-doctors can have rules for > > review clearly spelled out. My point is that I don't think we are changing the rules for the YANG modules, which this reply seemed to indicate. /martin > > Sue Hares > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, April 3, 2018 4:30 PM > To: shares@ndzh.com > Cc: ibagdona@gmail.com; iesg@ietf.org; i2rs@ietf.org; > draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ignas Bagdonas' Discuss on > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and > COMMENT) > > Hi, > > Just a quick comment on the YANG doctor's review. > > "Susan Hares" wrote: > > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested > > taking out the lengthy descriptions regarding logic and history. > > It is very common that the YANG doctor review ask for *more* details in the > descriptions. In general, we want the module to have as much explanatory > text as possible. So was the case for the YD review for this document as > well; the YD wrote "The descriptions in all YANG Modules are very > short/terse." That was for the -02 version, and even the -00 version did > not contain lengthy descriptions AFAICT. > > > /martin > From nobody Tue Apr 3 15:22:34 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C1212EAA5; Tue, 3 Apr 2018 15:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 7F-NHGrXSmEO; Tue, 3 Apr 2018 15:22:10 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 8E90E12D892; Tue, 3 Apr 2018 15:22:09 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Martin Bjorklund'" Cc: , , , , References: <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <20180403.222933.530851196105443807.mbj@tail-f.com> <018101d3cb8d$edef8140$c9ce83c0$@ndzh.com> <20180403.235700.1271525554065963758.mbj@tail-f.com> In-Reply-To: <20180403.235700.1271525554065963758.mbj@tail-f.com> Date: Tue, 3 Apr 2018 18:21:53 -0400 Message-ID: <01b301d3cb9a$2c1349a0$8439dce0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCz2sVuEQEwZ/0DDOZA6vVSxK38QgGdiGQFAl/mzwAB0I/dC6YBDMZQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 22:22:13 -0000 Martin: I apologize if my response seem to indicate the descriptions in the YANG modules or the YANG module overall description. My response was intended to query if there were now rules on what needed to be in the introductory material (non-YANG) in the RFC prior to the YANG module. AFAIK, the only formal definition for this portion of the YANG RFCs is regarding the Yang diagram RFC. Therefore, I was asking Ignas to provide clarity on his DISCUSS to determine references for his expectations for the introductory material. A DISCUSS should have some reference to a YANG web page, or an RFC or some written context to help the shepherd. As a shepherd unless I have a reference it is hard to handle conflicting reviews (shorten the introduction vs. add the introduction). If you know of such a web page or RFC, I would appreciate a reference. Thank you, Susan Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Tuesday, April 3, 2018 5:57 PM To: shares@ndzh.com Cc: ibagdona@gmail.com; i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; iesg@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) "Susan Hares" wrote: > Martin: > > Thank you for the comments on the Yang doctors. The discussion > reference was in the introductory material and not in the descriptions > in the YANG text. Do you also want additional comments in the introductory section? No. The comment was just about the YANG module. You wrote: > > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested > > taking out the lengthy descriptions regarding logic and history. If > > we are switching the rules for the YANG models, would you please > > update the requirements for the YANG models so that shepherds, > > rtg-dir, ops-dir, and yang-doctors can have rules for review clearly > > spelled out. My point is that I don't think we are changing the rules for the YANG modules, which this reply seemed to indicate. /martin > > Sue Hares > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, April 3, 2018 4:30 PM > To: shares@ndzh.com > Cc: ibagdona@gmail.com; iesg@ietf.org; i2rs@ietf.org; > draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ignas Bagdonas' Discuss on > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and > COMMENT) > > Hi, > > Just a quick comment on the YANG doctor's review. > > "Susan Hares" wrote: > > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested > > taking out the lengthy descriptions regarding logic and history. > > It is very common that the YANG doctor review ask for *more* details > in the descriptions. In general, we want the module to have as much > explanatory text as possible. So was the case for the YD review for > this document as well; the YD wrote "The descriptions in all YANG > Modules are very short/terse." That was for the -02 version, and even > the -00 version did not contain lengthy descriptions AFAICT. > > > /martin > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Apr 3 19:11:59 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6B6124319; Tue, 3 Apr 2018 19:11:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-i2rs-rib-data-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152280791712.24073.6516353843156615690.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 19:11:57 -0700 Archived-At: Subject: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 02:11:57 -0000 Ben Campbell has entered the following ballot position for draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alissa's comments. Requirements Language: There are at least a few instances of lower case versions of 2119 keywords. Please consider using the boilerplate from RFC 8174. Abstract: Missing article before "Routing Information Base" §1, first paragraph: Missing article before "Routing Information Base" From nobody Tue Apr 3 19:26:30 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D151243FE; Tue, 3 Apr 2018 19:26:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152280878408.24068.18282293731508698195.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 19:26:24 -0700 Archived-At: Subject: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 02:26:24 -0000 Ben Campbell has entered the following ballot position for draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-topology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Ignas's concern about the definition of "fabric". Otherwise, I have a couple of nits: Abstract: Missing article before "Data Center Network". §2: Please use the boilerplate from RFC 8174 rather than rolling your own text to constrain the keywords to their all-caps forms. From nobody Tue Apr 3 19:32:06 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CE8126CBF; Tue, 3 Apr 2018 19:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 EvVICJm-EhNu; Tue, 3 Apr 2018 19:31:58 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 367A5120725; Tue, 3 Apr 2018 19:31:58 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Ben Campbell'" , "'The IESG'" Cc: , , References: <152280878408.24068.18282293731508698195.idtracker@ietfa.amsl.com> In-Reply-To: <152280878408.24068.18282293731508698195.idtracker@ietfa.amsl.com> Date: Tue, 3 Apr 2018 22:31:49 -0400 Message-ID: <005701d3cbbd$186f6f50$494e4df0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMYVVDP590Qk93ZoU6803frp46xo6Fmz2QQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 02:32:00 -0000 Ben: Could you unpack the "share concern" on definition of fabric comment a = bit?=20 Sue=20 -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, April 3, 2018 10:26 PM To: The IESG Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan = Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Ben Campbell's No Objection on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT) Ben Campbell has entered the following ballot position for draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-t= opology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Ignas's concern about the definition of "fabric". Otherwise, I = have a couple of nits: Abstract: Missing article before "Data Center Network". =C2=A72: Please use the boilerplate from RFC 8174 rather than rolling = your own text to constrain the keywords to their all-caps forms. From nobody Tue Apr 3 21:39:06 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2B2126D05; Tue, 3 Apr 2018 21:39:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-i2rs-rib-data-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152281674476.24011.1275548255371559292.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 21:39:04 -0700 Archived-At: Subject: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 04:39:05 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This model tries to squeeze the 20 bit IPv6 flow label into a 16 bit field. This will result in a loss of data and needs to be fixed before the document is published. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 3 => Under identity ipv6-decapsulation { it looks like the description is wrong ("IPv4 tunnel decapsulation.") => What use case is the ttl-action decrease-and-copy-to-inner used for? => Under case egress-interface-mac-nexthop { It is not clear to me how you fit a MAC address into a 32 bit space ,or am I misreading this somehow and this is some form of index? " leaf ieee-mac-address { type uint32;" From nobody Wed Apr 4 07:29:11 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D5A126CBF; Wed, 4 Apr 2018 07:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 iOOKMXLV-3Di; Wed, 4 Apr 2018 07:29:09 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 88E6C12025C; Wed, 4 Apr 2018 07:29:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Martin Bjorklund'" Cc: , , , , References: <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <20180403.222933.530851196105443807.mbj@tail-f.com> <018101d3cb8d$edef8140$c9ce83c0$@ndzh.com> <20180403.235700.1271525554065963758.mbj@tail-f.com> In-Reply-To: <20180403.235700.1271525554065963758.mbj@tail-f.com> Date: Wed, 4 Apr 2018 10:28:51 -0400 Message-ID: <019401d3cc21$415c4730$c414d590$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCz2sVuEQEwZ/0DDOZA6vVSxK38QgGdiGQFAl/mzwAB0I/dC6YCDbSg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:29:10 -0000 Martin: You are correct, this is not a concern about the rules for the Yang module itself. Hence, my questions to Ignas about why he placed a DISCUSS based on "introduction material" that was not specified in any document. Thank you for your comments, Susan Hares -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Tuesday, April 3, 2018 5:57 PM To: shares@ndzh.com Cc: ibagdona@gmail.com; iesg@ietf.org; i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) "Susan Hares" wrote: > Martin: > > Thank you for the comments on the Yang doctors. The discussion > reference was in the introductory material and not in the descriptions > in the YANG text. Do you also want additional comments in the introductory section? No. The comment was just about the YANG module. You wrote: > > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested > > taking out the lengthy descriptions regarding logic and history. If > > we are switching the rules for the YANG models, would you please > > update the requirements for the YANG models so that shepherds, > > rtg-dir, ops-dir, and yang-doctors can have rules for review clearly > > spelled out. My point is that I don't think we are changing the rules for the YANG modules, which this reply seemed to indicate. /martin > > Sue Hares > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, April 3, 2018 4:30 PM > To: shares@ndzh.com > Cc: ibagdona@gmail.com; iesg@ietf.org; i2rs@ietf.org; > draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ignas Bagdonas' Discuss on > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and > COMMENT) > > Hi, > > Just a quick comment on the YANG doctor's review. > > "Susan Hares" wrote: > > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested > > taking out the lengthy descriptions regarding logic and history. > > It is very common that the YANG doctor review ask for *more* details > in the descriptions. In general, we want the module to have as much > explanatory text as possible. So was the case for the YD review for > this document as well; the YD wrote "The descriptions in all YANG > Modules are very short/terse." That was for the -02 version, and even > the -00 version did not contain lengthy descriptions AFAICT. > > > /martin > From nobody Wed Apr 4 07:31:13 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D07126CBF; Wed, 4 Apr 2018 07:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 dXvwbQMMSIRM; Wed, 4 Apr 2018 07:31:02 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 9346912025C; Wed, 4 Apr 2018 07:31:01 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id u46so23050831wrc.11; Wed, 04 Apr 2018 07:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=H28Zbvi1uSnaGx+TfqWEUCcazTpCSQ/m1sjHsNaIxqk=; b=kXV2UA7N7nga21dTYIbe8RiVbqwHIqVar58Ej4VQ8DKejmy+o2KkNGBvrjah5nbl53 xwIW+4gY1aY5CIGBNlb6U4cHqAWicuFFfNX99VGOceQ/NfDPhOhoBGu5XzRTOgIyY7gN ToAE4euAe5ybfUasF2xggQddnRwyEwtm9YPOqOAl5qMi4HK3Ci/KpnMJ0Kpnuc674Bn/ 92uuHojx7jl6i8GO6hUjLVMYoTMglRcuaWx+/Gj/K0j3lQtmYvptXXXkcqrssLC+Mhi1 CO9S1bdt0KzJd8NKtFHoNZjoXBZOUTm0IFNRswuZBJAQA5KBRlo2fh0IH9owdkT0SFQu kjtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=H28Zbvi1uSnaGx+TfqWEUCcazTpCSQ/m1sjHsNaIxqk=; b=d4cgeK1KITqmBimxPM2+qikWKlfuxzaeA4TTiWcvbtuvtFpmp/anpyuwW4s8hR+iQx E4ZNMooKRI2C0D01cVZTMxHSmpo7nrLvCeXRZk71uxHAxGlorhxaQ0Sl1/5hfaLRqZHC mQYG355enETf1XqhqZFBEhoMobrmAOdPyK3ZiyNCdvDPTbbR5cAAmmwFmVAl6y7cJQ6Q oYQnb9oRdC637re2RjkB6AQg8rg6Sacnif0E7HKlzHHB1HsIghmYEoWLl3LqImbcXBje gPSiFNiWwCGsxLWUUXv2NJrYdzqj8zQWMXXZTQSOZKtKdcYeSA+gTsmXtoLmer17P3XB jxPQ== X-Gm-Message-State: AElRT7FwA92fTOfRejnuRuj3v9ona7lGAV3+HZw6gJAJ6GZ5z0PwGhIY hcANB+MXBUgJLm3kxlepJ5O1q9KI8aQ= X-Google-Smtp-Source: AIpwx488fdLiPJu+qiUfezQ4TXwvkMVR/l4TAK0Ai6bFRjXVQqonYPXeCuz5UTi9bU0+me70Tbw99A== X-Received: by 10.223.193.73 with SMTP id w9mr14278437wre.101.1522852259660; Wed, 04 Apr 2018 07:30:59 -0700 (PDT) Received: from [192.168.96.203] ([80.69.10.100]) by smtp.gmail.com with ESMTPSA id n20sm3521716wmc.24.2018.04.04.07.30.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 07:30:58 -0700 (PDT) To: Susan Hares , 'The IESG' Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, i2rs-chairs@ietf.org, i2rs@ietf.org References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> From: Ignas Bagdonas Message-ID: Date: Wed, 4 Apr 2018 15:30:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <006401d3cb53$f17c36d0$d474a470$@ndzh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:31:06 -0000 Hi Sue, On 03/04/2018 14:59, Susan Hares wrote: > Ignas: > > Yan will answer for the authors but I would like to share some information related to the I2RS working group reviews. In your response, please specify why each question is a "DISCUSS" quality question rather than a "Comment" question. The authors and I (as the shepherd) will work to resolve both DISCUSS and comment issues. > > Let me review only 5 of your many points because they are pointing in a direction which is different from earlier QA reviews of this document (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 timeframe. > 1st - Why TE topology model is not sufficient for modelling the representation of DC fabric? Why is DC fabric network topology special compared to any generic fabric based topology? Why DISCUSS? DC fabric is a type of network topology, yes, it has some specifics, but nothing radically different than any purpose built network topology. Developing a separate model for a specific use case at the same time when there is generic and extensible TE model is questionable. > This document was reviewed by authors with the TE topology models to make sure there was no conflict or duplication. > > Your question implies that only one yang model is appropriate for each type of fabric. That is exactly opposite. What is special about DC fabric that it has to have a separate model? What is special about fabric type of topology that it has to have a separate model? Why is TE model not suitable? > This theory of one yang mode per fabric does not apply to dynamic (ephemeral) datastore versus configuration datastore models. It is also not true of all models even within the configuration datastore. > Since there is a yang catalog and selection of yang models is specific to a implemented, there has been no early winnowing of the yang models per type. If you are insisting on this theory of "one yang model" per fabric type, please provide an RFC reference so that I can help review this DISCUSS criteria with the authors. > > This yang model has been implemented by 1 vendor, and there was interest by other vendors. A deployment target has been identified for this model, and feedback is expected from the users. Excellent. Please get feedback from user community - even if it is not yet implemented and operations groups will not be able to provide feedback, architecture and engineering groups look into upcoming things and will have what to say. Speaking of implementations, the ODL faas project (from where the majority of this model seems to be coming from) deals with an instance of overlay that is subsequently treated as an underlay, and that is different that the underlay on top of which that instance is being run. If the model focus is on the "fabric as a service" type of topologies then it explicitly needs to state that, and then justify why physical node properties exist together with logical instance properties in that case. > If you are asking this model to cover three-four layer datacenters, this approach is opposite some of the initial feedback to the group to keep the initial model - that is to keep it simple and restricted to 2 layers in order to test the concepts. If you are asking to provide text (in introduction or appendix) that indicates the initial focus, this can be added. The document as it is written now tries to cover every possible fabric. If the scope is intended to be narrower - it needs to be stated. Starting from bounded scope is certainly a right thing to do but that is not how the document reads now. > 2nd - Multiple layers and multiple roles. Why DISCUSS? Two stage fabrics and fabrics with a perfectly clean node role separation do indeed exist, but that is not necessary a common deployment model. The document assumes that those are the only possible options. > The authors provide slides in several meetings I2RS meeting repository regarding this point. > The initial feedback suggested reducing the "why" text within the draft. Again, the initial feedback was to reduce the initial model's text to 2 layers and simple "whys". See proceedings from IETF 95 forward on I2RS on fabric data model for discussions. Would users of this model also be required to lookup proceedings of past IETF meetings in order to understand whether it may fit their use cases? > 3rd - The authors will comment on the port restrictions. Early feedback during the I2RS meetings from vendors may have taken the authors down this path. In my review, I expect major issues in this area - but I will let the authors comment. Why DISCUSS? The way how the model specifies port speeds is conflicting with common deployment practices. > 4 - policy is simple. > > Again, the initial feedback was to keep initial policies simple and gain feedback from the deployments. Why DISCUSS? What kind of policy is being discussed here? The assumption of one single universal policy fitting all deployments and use cases contradicts to operational reality. "Policy is simple" does not clarify what kind of policy it is. > 5 - You indicate that the document requires a "major" rewrite clarifying the logic. Why DISCUSS? Model tries to prescribe a way how all DC networks should be built. It intermixes concepts of underlay and overlay. There are nodes in the model with unclear purpose and no documented details on what and how they are doing. > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested taking out the lengthy descriptions regarding logic and history. If we are switching the rules for the YANG models, would you please update the requirements for the YANG models so that shepherds, rtg-dir, ops-dir, and yang-doctors can have rules for review clearly spelled out. YANG models, and any other deliverables of the IETF, are targetted to the users of those deliverables and not necessary to the IETF itself. The situation with YANG models is that the main consumer of IETF YANG model for a noticeable period was  IETF itself - it was required to build the sufficient coverage of models for them to be practically useful. We as an industry start to see more practical use of YANG modules, and so far the main obstacle for YANG acceptance is the difficulty in trying to use it. It is incorrect to assume that outside of the IETF WGs that deal with developing the models there is enough of understanding of the reasoning behind modelling decisions made. It is incorrect to assume that potential users of such models would try to lookup proceedings of past IETF meeting trying to get answers - they will chose other manageability technologies instead. YANG models need to be self-contained from the practical usability perspective - the models themselves should contain enough and meaningful descriptions of the nodes that it would not raise questions for users trying to deploy those models. Descriptions equivalent to those found in command line interfaces - if YANG is expected to become a new command line interface, it should be no worse than the command line interface. The reasoning behind modelling decisions made also need to be documented - at least for allowing model users to see whether the model is suitable for deployment in the particular environment. As YANG is maturing and starting to be deployed, naturally the focus of reviews will change to reflect what is required for successful deployment of the technology. > Summary on Shepherd's comment: > > The authors will respond to others specifics, but in order to guide these diligent authors - I need to know what rules you are setting for the 2018 IESG approval of YANG models. If you are placing a DISCUSS on a YANG model based on a set criteria, the criteria needs to be published on a web page or in an RFC. If I've missed this criteria that the OPS Area has specified, RFC6087 and draft-ietf-netmod-rfc6087bis. There are two parts that are important for reviews - the model itself, and how the model applies to the managed entities. And there is nothing new in the review criteria. The former is rather not that complex, and typically can be done within IETF itself. The latter is more complex and generally would require feedback from the target users of the model. There is a balance between a model being too generic to be practically usable and model being too prescriptive to be practically usable. If the model puts requirements and restrictions on the managed entities in a way that requires to build those managed entities in a specific way, predefined by the model authors, the value of such model is questionable. Speaking specifically about DC fabric model, it puts network design prescriptions that are significantly misaligned with how fabric based networks have been and are built. Yes, it is possible to find environments where the model would apply directly and with no impact, but one would need to look for such deployments quite hard, and with a high probability that would be proof of concept or technology demonstration type of environments. IETF is good at developing technology components and fragments, IETF typically is not good at dealing with network design and how those fragments need to be bound together - that is the reality, and that is not necessarily wrong. IETF should be focusing on what it can do best - the fragments, and align with users of the fragments on how to improve the fragments but not try to direct how users should be building their networks. It is important for the reputation of IETF as a credible SDO - if IETF manageability mechanisms propose and enforce not necessarily right - or just plain broken - network designs, that is a reputation problem. This document tends to be proposed standard, and that sets a strong message. Ignas > Thank you for your review, > Susan Hares > > -----Original Message----- > From: Ignas Bagdonas [mailto:ibagdona@gmail.com] > Sent: Tuesday, April 3, 2018 7:40 AM > To: The IESG > Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) > > Ignas Bagdonas has entered the following ballot position for > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-topology/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have concerns about the practical usability of this proposed model as it is specified now. > > The intended decoupling of fabric implementation properties (what is termed as "underlay network infrastructure" in the document) and its topology seems to be contradicting to general operational practices of fabric based networks. It is generally true for the context of the overlay but that is not what the document seems to be focusing on. Fabric defines and implements the underlay, not the other way around. > > The document does not contain a sufficient description of the logic of the model itself, the reasons for choices made for representation of types and attributes, and at the same time descriptions in modules are single lines that do not add clarification beyond being copies of leaf names. Either there needs to be a section that describes the logic of the model and how it relates to other models, also including examples, or module description fields need to have enough content to be able to have equivalent understanding of model intent and operation. Both are strongly encouraged, as descriptions have value of itself for being a reference for use, and model description is needed for understanding how this particular model fits into the larger hierarchy. Network management does not end at the boundary of the single domain-specific model, it is important to build it into a whole system. > > Why TE topology model is not sufficient for modelling the representation of DC fabric? Why is DC fabric network topology special compared to any generic fabric based topology? > > How this model could be used for representing more than two stage fabrics that are in wide deployment? > > Limiting port bandwidth to a fixed rate is too restrictive. The model as specified already does not cover a set of port speeds that are in deployment. > > How would a device that has more than a single role in the fabric be represented? > > Service capabilities as they are described belong to the overlay context while they are called device capabilities. Are those the only possible service capabilities? What is the effect of configuring those capabilities? > > What is compose-fabric RPC? The document does not define any RPCs. > > What is policy driven traffic behavior? Is there the only one policy that fits all possible deployment scenarios? > > Looking at the history of the document from the individual submission time and the comments received, it seems that the point fixes to the text went in to cover the specific comments but not to address the broader scope of comments. > The document would definitely benefit from a major rewrite clarifying the logic behind the decisions made, aligning more with the operational practice of fabric based network design and deployment, and bringing the content in YANG modules to be self-describing. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Fabric and POD are not equivalent terms. > > I2RS use case requirements document has expired 11 months ago. Use cases documents are good for tracking the work progress of specification documents, it is questionable whether standalone use cases documents provide value beyond historic record. Is the reference to I2RS use cases document really needed? > > What is atomic network? > > VLAN is not a fabric building technology as such, while Ethernet is. > > What is the need for VNI capacity leaves? What is their effect if configured? > > The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces. > > Serial port-type is present while Infiniband is not - Infiniband based fabrics are widely deployed. What is the extensibility mechanism for adding in new port types? > > Is there any deployment experience with this model? The ODL faas project hasn't got much activity over last two years. Are you aware of any other implementations or deployments? > > > From nobody Wed Apr 4 07:33:58 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B70412778D; Wed, 4 Apr 2018 07:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 fMZvqgfWtbO5; Wed, 4 Apr 2018 07:33:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4F6B2126CBF; Wed, 4 Apr 2018 07:33:53 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w34EXodH097329 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Apr 2018 09:33:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B68E856A-A8E2-4427-907A-4941D6E94CF8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 4 Apr 2018 09:33:49 -0500 In-Reply-To: <005701d3cbbd$186f6f50$494e4df0$@ndzh.com> Cc: The IESG , draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, i2rs-chairs@ietf.org, i2rs@ietf.org To: Susan Hares References: <152280878408.24068.18282293731508698195.idtracker@ietfa.amsl.com> <005701d3cbbd$186f6f50$494e4df0$@ndzh.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 14:33:55 -0000 --Apple-Mail=_B68E856A-A8E2-4427-907A-4941D6E94CF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Specifically, Ignas said: "It is generally true for the context of the overlay but that is not = what the document seems to be focusing on. Fabric defines and implements = the underlay, not the other way around.=E2=80=9D Note that I specifically did not say I =E2=80=9Csupport the discuss=E2=80=9D= , only that that I was confused by the terminology issue he mentioned in = his discuss. Thanks, Ben. > On Apr 3, 2018, at 9:31 PM, Susan Hares wrote: >=20 > Ben: >=20 > Could you unpack the "share concern" on definition of fabric comment a = bit? >=20 > Sue >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, April 3, 2018 10:26 PM > To: The IESG > Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan = Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Ben Campbell's No Objection on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT) >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: No Objection >=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-i2rs-yang-dc-fabric-network-to= pology/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I share Ignas's concern about the definition of "fabric". Otherwise, I = have a couple of nits: >=20 > Abstract: Missing article before "Data Center Network". >=20 > =C2=A72: Please use the boilerplate from RFC 8174 rather than rolling = your own text to constrain the keywords to their all-caps forms. >=20 >=20 >=20 --Apple-Mail=_B68E856A-A8E2-4427-907A-4941D6E94CF8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrE4k0ACgkQgFZKbJXz 1A0ZUxAAuVOGvFSmOZdQooB/1ADSCcqL5NtKH9vxifGz2mrV1icpI2yf5Zw7v+8r VoVf7xQ44nczo4MFOkZWuq2tYg4zMnBGZNjDKmnWNA5G2zTXWY1EJ3eEbCRNuQ2M rRDv+E5JqiOW9fshHHFV1NYKq7DoyfjhrHrb0zf3TlQz2tRisSBuwjJwu9YVtJU3 hLWVSi9T7dHcZsdHlS61mkNJpqks22I/UgBkGzKwVxKqPYuvpff6rmMDbSR/whAy wfry8Axnb9fMVPiORrLtzCWz+dOAFOEP4OlE4OrOZs8mxp1XVnFIrAdn6oyl4lcX gd4+iV/n0/yTRbIJLr4q+Kdn+gkj7Yknwhw5bR+QRm84ZCc8HROoNTmadlAXsKcQ oWCotI2ztyLsr12TmcFSokI6SoF1o8xAnjKuPW8YQp4cAy1F+oFftHYTr5DyYdjH nHFnuqCPSmc+zTsWdWXpVUxRFXheapv8c7h476T6n8LYemzgBW0F3z7tr+lsTEmB BZFFjF+g7qc0iMBOWfVeiGHzAuxQAaHhApt3JKDzyhkNdBYPWhKu9IAYXSjYfg/1 p++H80a15qs3UQGMk7E2diVPEoXmvwWSILN9GtlHSWv9wNi+cpVY7acf3Aej27Wh MVLrUT88DLXOLepEeeCrkRSEpbaHKz7gipap4jkdCx7aFUao5OM= =G8jA -----END PGP SIGNATURE----- --Apple-Mail=_B68E856A-A8E2-4427-907A-4941D6E94CF8-- From nobody Wed Apr 4 08:03:22 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2402212D72F; Wed, 4 Apr 2018 08:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 4nDn13E94J0I; Wed, 4 Apr 2018 08:03:09 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 D7220126FB3; Wed, 4 Apr 2018 08:03:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Ignas Bagdonas'" , "'The IESG'" Cc: , , References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> In-Reply-To: Date: Wed, 4 Apr 2018 11:03:05 -0400 Message-ID: <01c701d3cc26$09865b20$1c931160$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrfpTnkeJxdov8ELnNq0f+qOuaSgCz2sVuAohvGoqjp2ZTkA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:03:13 -0000 Ignas:=20 I am not trying to clarify the specifics. This response (as I = mentioned), will come from the authors. As a shepherd/WG chair, I am = asking for information regarding the basis of your DISCUSS models for = specific points. =20 The 2014 document on the IESG discuss criteria is at:=20 https://www.ietf.org/blog/discuss-criteria-iesg-review/ What on this list does the following comment refer to:=20 "Why DISCUSS? DC fabric is a type of network topology, yes, it has some = specifics, but nothing radically different than any purpose built = network topology. Developing a separate model for a specific use case at = the same time when there is generic and extensible TE model is = questionable."=20 Perhaps you are not considering the fact this is an I2RS model. Let me = provide 3 comments regaring that point:=20 =20 1st - I2RS is focusing on models that are capable for the dynamic state = and configuration state. These models have qualitative differences. = The mechanisms of a model which does both dynamic state and = configuration state is qualitative different that the basic TE models. = This model extends the TE models toward this approach (see module = ietf-dc-fabric-topology reference import of ietf-network-topology). =20 =20 2nd - During the I2RS process we talked to the TE topology authors and = the TE WG. We agreed that this model has differences. As a WG = Co-chair, I spent time reviewing this interaction.=20 3rd - How many of the user community have implemented I2RS dynamic = models or the RFC version of the TE models? =20 See the comments from Chris Hopps and others on slow pace of the netconf = work. If you are going to restrict to two deployed implementations, you = will be joining the IDR camp of requirements and slowing the work = further. The only reason we require 2 implementations for IDR is for = the fragile BGP environment and that operators request it due to the = global consequences. Network Management of these early yang models have = a much more restricted case.=20 Sue Hares=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ignas Bagdonas Sent: Wednesday, April 4, 2018 10:31 AM To: Susan Hares; 'The IESG' Cc: i2rs@ietf.org; = draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; = i2rs-chairs@ietf.org Subject: Re: [i2rs] Ignas Bagdonas' Discuss on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = COMMENT) Hi Sue, On 03/04/2018 14:59, Susan Hares wrote: > Ignas: > > Yan will answer for the authors but I would like to share some = information related to the I2RS working group reviews. In your = response, please specify why each question is a "DISCUSS" quality = question rather than a "Comment" question. The authors and I (as the = shepherd) will work to resolve both DISCUSS and comment issues. > > Let me review only 5 of your many points because they are pointing in = a direction which is different from earlier QA reviews of this document = (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 timeframe. > 1st - Why TE topology model is not sufficient for modelling the = representation of DC fabric? Why is DC fabric network topology special = compared to any generic fabric based topology? Why DISCUSS? DC fabric is a type of network topology, yes, it has some = specifics, but nothing radically different than any purpose built = network topology. Developing a separate model for a specific use case at = the same time when there is generic and extensible TE model is = questionable. > This document was reviewed by authors with the TE topology models to = make sure there was no conflict or duplication. > > Your question implies that only one yang model is appropriate for each = type of fabric. That is exactly opposite. What is special about DC fabric that it has to = have a separate model? What is special about fabric type of topology = that it has to have a separate model? Why is TE model not suitable? > This theory of one yang mode per fabric does not apply to dynamic = (ephemeral) datastore versus configuration datastore models. It is also = not true of all models even within the configuration datastore. > Since there is a yang catalog and selection of yang models is specific = to a implemented, there has been no early winnowing of the yang models = per type. If you are insisting on this theory of "one yang model" per = fabric type, please provide an RFC reference so that I can help review = this DISCUSS criteria with the authors. > > This yang model has been implemented by 1 vendor, and there was = interest by other vendors. A deployment target has been identified for = this model, and feedback is expected from the users. Excellent. Please get feedback from user community - even if it is not = yet implemented and operations groups will not be able to provide = feedback, architecture and engineering groups look into upcoming things = and will have what to say. Speaking of implementations, the ODL faas project (from where the = majority of this model seems to be coming from) deals with an instance = of overlay that is subsequently treated as an underlay, and that is = different that the underlay on top of which that instance is being run.=20 If the model focus is on the "fabric as a service" type of topologies = then it explicitly needs to state that, and then justify why physical = node properties exist together with logical instance properties in that = case. > If you are asking this model to cover three-four layer datacenters, = this approach is opposite some of the initial feedback to the group to = keep the initial model - that is to keep it simple and restricted to 2 = layers in order to test the concepts. If you are asking to provide text = (in introduction or appendix) that indicates the initial focus, this can = be added. The document as it is written now tries to cover every possible fabric.=20 If the scope is intended to be narrower - it needs to be stated.=20 Starting from bounded scope is certainly a right thing to do but that is = not how the document reads now. > 2nd - Multiple layers and multiple roles. Why DISCUSS? Two stage fabrics and fabrics with a perfectly clean node=20 role separation do indeed exist, but that is not necessary a common=20 deployment model. The document assumes that those are the only possible=20 options. > The authors provide slides in several meetings I2RS meeting = repository regarding this point. > The initial feedback suggested reducing the "why" text within the = draft. Again, the initial feedback was to reduce the initial model's = text to 2 layers and simple "whys". See proceedings from IETF 95 = forward on I2RS on fabric data model for discussions. Would users of this model also be required to lookup proceedings of past = IETF meetings in order to understand whether it may fit their use cases? > 3rd - The authors will comment on the port restrictions. Early = feedback during the I2RS meetings from vendors may have taken the = authors down this path. In my review, I expect major issues in this = area - but I will let the authors comment. Why DISCUSS? The way how the model specifies port speeds is conflicting=20 with common deployment practices. > 4 - policy is simple. > > Again, the initial feedback was to keep initial policies simple and = gain feedback from the deployments. Why DISCUSS? What kind of policy is being discussed here? The assumption = of one single universal policy fitting all deployments and use cases=20 contradicts to operational reality. "Policy is simple" does not clarify what kind of policy it is. > 5 - You indicate that the document requires a "major" rewrite = clarifying the logic. Why DISCUSS? Model tries to prescribe a way how all DC networks should=20 be built. It intermixes concepts of underlay and overlay. There are=20 nodes in the model with unclear purpose and no documented details on=20 what and how they are doing. > Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested = taking out the lengthy descriptions regarding logic and history. If we = are switching the rules for the YANG models, would you please update the = requirements for the YANG models so that shepherds, rtg-dir, ops-dir, = and yang-doctors can have rules for review clearly spelled out. YANG models, and any other deliverables of the IETF, are targetted to=20 the users of those deliverables and not necessary to the IETF itself.=20 The situation with YANG models is that the main consumer of IETF YANG=20 model for a noticeable period was IETF itself - it was required to=20 build the sufficient coverage of models for them to be practically=20 useful. We as an industry start to see more practical use of YANG=20 modules, and so far the main obstacle for YANG acceptance is the=20 difficulty in trying to use it. It is incorrect to assume that outside=20 of the IETF WGs that deal with developing the models there is enough of=20 understanding of the reasoning behind modelling decisions made. It is=20 incorrect to assume that potential users of such models would try to=20 lookup proceedings of past IETF meeting trying to get answers - they=20 will chose other manageability technologies instead. YANG models need to = be self-contained from the practical usability perspective - the models=20 themselves should contain enough and meaningful descriptions of the=20 nodes that it would not raise questions for users trying to deploy those = models. Descriptions equivalent to those found in command line=20 interfaces - if YANG is expected to become a new command line interface, = it should be no worse than the command line interface. The reasoning=20 behind modelling decisions made also need to be documented - at least=20 for allowing model users to see whether the model is suitable for=20 deployment in the particular environment. As YANG is maturing and=20 starting to be deployed, naturally the focus of reviews will change to=20 reflect what is required for successful deployment of the technology. > Summary on Shepherd's comment: > > The authors will respond to others specifics, but in order to guide = these diligent authors - I need to know what rules you are setting for = the 2018 IESG approval of YANG models. If you are placing a DISCUSS on = a YANG model based on a set criteria, the criteria needs to be published = on a web page or in an RFC. If I've missed this criteria that the OPS = Area has specified, RFC6087 and draft-ietf-netmod-rfc6087bis. There are two parts that are important for reviews - the model itself,=20 and how the model applies to the managed entities. And there is nothing=20 new in the review criteria. The former is rather not that complex, and=20 typically can be done within IETF itself. The latter is more complex and = generally would require feedback from the target users of the model.=20 There is a balance between a model being too generic to be practically=20 usable and model being too prescriptive to be practically usable. If the = model puts requirements and restrictions on the managed entities in a=20 way that requires to build those managed entities in a specific way,=20 predefined by the model authors, the value of such model is=20 questionable. Speaking specifically about DC fabric model, it puts=20 network design prescriptions that are significantly misaligned with how=20 fabric based networks have been and are built. Yes, it is possible to=20 find environments where the model would apply directly and with no=20 impact, but one would need to look for such deployments quite hard, and=20 with a high probability that would be proof of concept or technology=20 demonstration type of environments. IETF is good at developing technology components and fragments, IETF=20 typically is not good at dealing with network design and how those=20 fragments need to be bound together - that is the reality, and that is=20 not necessarily wrong. IETF should be focusing on what it can do best -=20 the fragments, and align with users of the fragments on how to improve=20 the fragments but not try to direct how users should be building their=20 networks. It is important for the reputation of IETF as a credible SDO - = if IETF manageability mechanisms propose and enforce not necessarily=20 right - or just plain broken - network designs, that is a reputation=20 problem. This document tends to be proposed standard, and that sets a=20 strong message. Ignas > Thank you for your review, > Susan Hares > > -----Original Message----- > From: Ignas Bagdonas [mailto:ibagdona@gmail.com] > Sent: Tuesday, April 3, 2018 7:40 AM > To: The IESG > Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan = Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Ignas Bagdonas' Discuss on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = COMMENT) > > Ignas Bagdonas has entered the following ballot position for > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-t= opology/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have concerns about the practical usability of this proposed model = as it is specified now. > > The intended decoupling of fabric implementation properties (what is = termed as "underlay network infrastructure" in the document) and its = topology seems to be contradicting to general operational practices of = fabric based networks. It is generally true for the context of the = overlay but that is not what the document seems to be focusing on. = Fabric defines and implements the underlay, not the other way around. > > The document does not contain a sufficient description of the logic of = the model itself, the reasons for choices made for representation of = types and attributes, and at the same time descriptions in modules are = single lines that do not add clarification beyond being copies of leaf = names. Either there needs to be a section that describes the logic of = the model and how it relates to other models, also including examples, = or module description fields need to have enough content to be able to = have equivalent understanding of model intent and operation. Both are = strongly encouraged, as descriptions have value of itself for being a = reference for use, and model description is needed for understanding how = this particular model fits into the larger hierarchy. Network management = does not end at the boundary of the single domain-specific model, it is = important to build it into a whole system. > > Why TE topology model is not sufficient for modelling the = representation of DC fabric? Why is DC fabric network topology special = compared to any generic fabric based topology? > > How this model could be used for representing more than two stage = fabrics that are in wide deployment? > > Limiting port bandwidth to a fixed rate is too restrictive. The model = as specified already does not cover a set of port speeds that are in = deployment. > > How would a device that has more than a single role in the fabric be = represented? > > Service capabilities as they are described belong to the overlay = context while they are called device capabilities. Are those the only = possible service capabilities? What is the effect of configuring those = capabilities? > > What is compose-fabric RPC? The document does not define any RPCs. > > What is policy driven traffic behavior? Is there the only one policy = that fits all possible deployment scenarios? > > Looking at the history of the document from the individual submission = time and the comments received, it seems that the point fixes to the = text went in to cover the specific comments but not to address the = broader scope of comments. > The document would definitely benefit from a major rewrite clarifying = the logic behind the decisions made, aligning more with the operational = practice of fabric based network design and deployment, and bringing the = content in YANG modules to be self-describing. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Fabric and POD are not equivalent terms. > > I2RS use case requirements document has expired 11 months ago. Use = cases documents are good for tracking the work progress of specification = documents, it is questionable whether standalone use cases documents = provide value beyond historic record. Is the reference to I2RS use cases = document really needed? > > What is atomic network? > > VLAN is not a fabric building technology as such, while Ethernet is. > > What is the need for VNI capacity leaves? What is their effect if = configured? > > The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces. > > Serial port-type is present while Infiniband is not - Infiniband based = fabrics are widely deployed. What is the extensibility mechanism for = adding in new port types? > > Is there any deployment experience with this model? The ODL faas = project hasn't got much activity over last two years. Are you aware of = any other implementations or deployments? > > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Apr 4 08:22:27 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B55A12DA02; Wed, 4 Apr 2018 08:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 UdNy5pcSRDox; Wed, 4 Apr 2018 08:22:17 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 2F23412DA23; Wed, 4 Apr 2018 08:22:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Ignas Bagdonas'" , "'The IESG'" Cc: , , References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <9B4BC45FDEDDD84F813E9E4A5BAF8785A96B7310@nkgeml513-mbs.china.huawei.com> In-Reply-To: <9B4BC45FDEDDD84F813E9E4A5BAF8785A96B7310@nkgeml513-mbs.china.huawei.com> Date: Wed, 4 Apr 2018 11:22:13 -0400 Message-ID: <01d801d3cc28$b5e18410$21a48c30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01D3CC07.2ED2F150" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrfpTnkeJxdov8ELnNq0f+qOuaSgJUZuM9o66tSBA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] FW: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:22:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D9_01D3CC07.2ED2F150 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ignas: =20 I=E2=80=99m forwarding Yan=E2=80=99s specific answers to each of your = questions. I had held this response back until I tried to learn more = about what specific questions were tag with specific DISCUSS quality = comments=20 per the IESG 2014 DISCUSS criteria comments:=20 https://www.ietf.org/blog/discuss-criteria-iesg-review/ =20 I=E2=80=99m sure Yan will be glad to make adjustments in the draft (see = below). You will note that you are asking us to put back in RPCs that = others had us take out. =20 =20 This leads me to back to my questions as a Shepherd. My concern is that = many of your requested changes are counter to agreements in discussions = with WG, TE WG, NETCONF/NETMOD, and previous ADS (OPS, RTG) regarding = I2RS drafts. Since these drafts were delayed due to the reading load = of the IESG, it seems we are working under different rules. So, please = specify how your comments match the DISCUSS criteria. If you are = setting new rules for I2RS documents, please detail the new rules of = review. =20 =20 It is too bad that we could not have reviewed these documents during = their originally scheduled telechat with previous ADs. =20 =20 Susan Hares=20 =20 -----Original Message----- From: Ignas Bagdonas [mailto:ibagdona@gmail.com]=20 Sent: Tuesday, April 03, 2018 7:40 PM To: The IESG Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan = Hares ; i2rs-chairs@ietf.org; shares@ndzh.com; = i2rs@ietf.org Subject: Ignas Bagdonas' Discuss on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = COMMENT) =20 Ignas Bagdonas has entered the following ballot position for draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-t= opology/ =20 =20 =20 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =20 I have concerns about the practical usability of this proposed model as = it is specified now. =20 The intended decoupling of fabric implementation properties (what is = termed as "underlay network infrastructure" in the document) and its = topology seems to be contradicting to general operational practices of = fabric based networks. It is generally true for the context of the = overlay but that is not what the document seems to be focusing on. = Fabric defines and implements the underlay, not the other way around. [Y] The intention of this model is to represent the entire topology of a = data center fabric network. The whole network can be considered as a = single fabric network which is composed by several PODs defined as = =E2=80=9Cnode=E2=80=9D in this module. Under these = =E2=80=9Cnodes=E2=80=9D, there are supporting-nodes (reference to = device-nodes belonged to the POD) and connections.=20 =20 The term of POD/fabric is a bit confusing in the draft. How about we = updating the Terminology section as below? POD: a module of network, compute, storage, and application components = that work together to deliver networking services. It represents a = repeatable design pattern. Its components maximize the modularity, = scalability, and manageability of data centers. Fabric: composed of several PODs to form a data center network. =20 Does it make sense? =20 The document does not contain a sufficient description of the logic of = the model itself, the reasons for choices made for representation of = types and attributes, and at the same time descriptions in modules are = single lines that do not add clarification beyond being copies of leaf = names. Either there needs to be a section that describes the logic of = the model and how it relates to other models, also including examples, = or module description fields need to have enough content to be able to = have equivalent understanding of model intent and operation. Both are = strongly encouraged, as descriptions have value of itself for being a = reference for use, and model description is needed for understanding how = this particular model fits into the larger hierarchy. Network management = does not end at the boundary of the single domain-specific model, it is = important to build it into a whole system. =20 Why TE topology model is not sufficient for modelling the representation = of DC fabric? Why is DC fabric network topology special compared to any = generic fabric based topology? [Y] We discussed with TE topology model authors about this question. For = TE, it is more focused on connections for TE and statics for their = performance, while this model is to present how a data center network = look like with its specific nodes(leaf/spine).=20 =20 How this model could be used for representing more than two stage = fabrics that are in wide deployment? [Y] In that case, more roles for interlayer devices can be added. The = =E2=80=9Crole=E2=80=9D for device is defined as identity-ref. New roles = can be added by defining new identities. =20 Limiting port bandwidth to a fixed rate is too restrictive. The model as = specified already does not cover a set of port speeds that are in = deployment. [Y] bandwidth is defined as identity-ref. Other speeds can be added by = defining new identities. =20 How would a device that has more than a single role in the fabric be = represented? [Y] The role for a device-node is defined as leaf-list to support a = device with more than one roles.=20 =20 Service capabilities as they are described belong to the overlay context = while they are called device capabilities. Are those the only possible = service capabilities? What is the effect of configuring those = capabilities? [Y] Service capabilities is for a fabric not a device. The description = for the service capabilities will be corrected. For better extension for = other services, we will change current enumeration type to identity-ref. = More service identities can be defined in the future by vendors. =20 What is compose-fabric RPC? The document does not define any RPCs. [Y] rpcs were removed in previous version since people say it would = leave for vendor-specific implementation. The rpcs to compose a fabric is as: rpc compose-fabric { input { uses fabric-attributes; } output { leaf fabric-id { type fabric-id; } } } To add a node to fabric: =20 rpc add-node-to-fabric { input { leaf fabric-id { type fabric-id; } uses device-attributes; } } Do you suggest we bring it back to the draft? =20 What is policy driven traffic behavior? Is there the only one policy = that fits all possible deployment scenarios? [Y] Policy is needed for the traffic otherwise the traffic will be = discard. There can also be normal, which means no policy is needed for = all traffic.=20 =20 Looking at the history of the document from the individual submission = time and the comments received, it seems that the point fixes to the = text went in to cover the specific comments but not to address the = broader scope of comments. The document would definitely benefit from a major rewrite clarifying = the logic behind the decisions made, aligning more with the operational = practice of fabric based network design and deployment, and bringing the = content in YANG modules to be self-describing. =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 Fabric and POD are not equivalent terms. =20 I2RS use case requirements document has expired 11 months ago. Use cases = documents are good for tracking the work progress of specification = documents, it is questionable whether standalone use cases documents = provide value beyond historic record. Is the reference to I2RS use cases = document really needed? [Y] The reference will be removed in v09. =20 What is atomic network? [Y] The original sentence might be confusing. How about we changing it = to =E2=80=9Ca POD can be considered as a basic structure for management = purposes.=E2=80=9D? =20 VLAN is not a fabric building technology as such, while Ethernet is. =20 What is the need for VNI capacity leaves? What is their effect if = configured? [Y] It is used to say the range of the VNIs for a POD. We will update = the description to clarify it. =20 The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces. [Y] Apologize for the inconsistent. It will be changed to = ietf-dc-fabric-* in v09. =20 Serial port-type is present while Infiniband is not - Infiniband based = fabrics are widely deployed. What is the extensibility mechanism for = adding in new port types? [Y] Since the port-type is identityref, new port types can be added by = defining new identities. =20 Is there any deployment experience with this model? The ODL faas project = hasn't got much activity over last two years. Are you aware of any other = implementations or deployments? [Y] Yes, the implementation is in ODL FAAS. Current module is a part of = fass project. It has been done over two years and only maintenance is = needed. And we think it is stable.=20 ------=_NextPart_000_01D9_01D3CC07.2ED2F150 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Ignas:

 

I=E2=80=99m = forwarding Yan=E2=80=99s specific answers to each of your questions. I = had held this response back until I tried to learn more about what = specific questions were tag with specific DISCUSS quality comments =

per the IESG 2014 DISCUSS criteria comments: =

https://= www.ietf.org/blog/discuss-criteria-iesg-review/

=

 

I=E2=80=99m sure Yan = will be glad to make adjustments in the draft (see below).=C2=A0 You = will note that you are asking us to put back in RPCs that others had us = take out. =C2=A0

 

This leads me to back = to my questions as a Shepherd. My concern is that many of your requested = changes are counter to agreements in discussions with WG, TE WG, = NETCONF/NETMOD, and previous ADS (OPS, RTG) regarding I2RS drafts.=C2=A0 = =C2=A0Since these drafts were delayed due to the reading load of the = IESG, it seems we are working under different rules. =C2=A0So, please = specify how your comments match the DISCUSS criteria.=C2=A0 If you are = setting new rules for I2RS documents, please detail the new rules of = review. =C2=A0=C2=A0

 

It is too bad that we = could not have reviewed these documents during their originally = scheduled telechat with previous =C2=A0ADs.=C2=A0 =

 

Susan Hares =

 

-----Original Message-----
From: Ignas Bagdonas = [mailto:ibagdona@gmail.com] =
Sent: Tuesday, April 03, 2018 7:40 PM
To: The IESG <iesg@ietf.org>
Cc: = draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan = Hares <shares@ndzh.com>; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org
Subject: Ignas = Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: = (with DISCUSS and COMMENT)

 

Ignas = Bagdonas has entered the following ballot position for

draft-ietf-i2rs-yang-dc-fabric-network-topology-08: = 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-i2rs-yang-dc-fabric-network-topology/<= /o:p>

 

 

 

----------------------------------------------------= ------------------

DISCUSS:

----------------------------------------------------= ------------------

 

I have = concerns about the practical usability of this proposed model as it is = specified now.

 

The = intended decoupling of fabric implementation properties (what is termed = as "underlay network infrastructure" in the document) and its = topology seems to be contradicting to general operational practices of = fabric based networks. It is generally true for the context of the = overlay but that is not what the document seems to be focusing on. = Fabric defines and implements the underlay, not the other way = around.

[Y] The intention of this model is to represent the = entire topology of a data center fabric network. The whole network can = be considered as a single fabric network which is composed by several = PODs defined as =E2=80=9Cnode=E2=80=9D in this module. Under these = =E2=80=9Cnodes=E2=80=9D, there are supporting-nodes (reference to = device-nodes belonged to the POD) and connections. =

 

The term of POD/fabric is = a bit confusing in the draft. How about we updating the Terminology = section as below?

POD: a module of network, compute, storage, and = application components that work together to deliver networking = services. It represents a repeatable design pattern. Its components = maximize the modularity, scalability, and manageability of data = centers.

Fabric: composed of several PODs to form a data = center network.

 

Does it make = sense?

 

The = document does not contain a sufficient description of the logic of the = model itself, the reasons for choices made for representation of types = and attributes, and at the same time descriptions in modules are single = lines that do not add clarification beyond being copies of leaf names. = Either there needs to be a section that describes the logic of the model = and how it relates to other models, also including examples, or module = description fields need to have enough content to be able to have = equivalent understanding of model intent and operation. Both are = strongly encouraged, as descriptions have value of itself for being a = reference for use, and model description is needed for understanding how = this particular model fits into the larger hierarchy. Network management = does not end at the boundary of the single domain-specific model, it is = important to build it into a whole system.

 

Why TE = topology model is not sufficient for modelling the representation of DC = fabric? Why is DC fabric network topology special compared to any = generic fabric based topology?

[Y] We discussed with TE = topology model authors about this question. For TE, it is more focused = on connections for TE and statics for their performance, while this = model is to present how a data center network look like with its = specific nodes(leaf/spine).

 

How = this model could be used for representing more than two stage fabrics = that are in wide deployment?

[Y] In that case, more roles for interlayer devices = can be added. The =E2=80=9Crole=E2=80=9D for device is defined as = identity-ref. New roles can be added by defining new = identities.

 

Limiting port bandwidth to a fixed rate is too = restrictive. The model as specified already does not cover a set of port = speeds that are in deployment.

[Y] bandwidth is defined = as identity-ref. Other speeds can be added by defining new = identities.

 

How = would a device that has more than a single role in the fabric be = represented?

[Y] The role for a device-node is defined as = leaf-list to support a device with more than one roles. =

 

Service capabilities as they are described belong = to the overlay context while they are called device capabilities. Are = those the only possible service capabilities? What is the effect of = configuring those capabilities?

[Y] Service capabilities = is for a fabric not a device. The description for the service = capabilities will be corrected. For better extension for other services, = we will change current enumeration type to identity-ref. More service = identities can be defined in the future by = vendors.

 

What = is compose-fabric RPC? The document does not define any = RPCs.

[Y] rpcs were removed in previous version since = people say it would leave for vendor-specific = implementation.

The rpcs to compose a fabric is = as:

    rpc compose-fabric = {

        input = {

         = ;   uses fabric-attributes;

        = }

        output = {

         = ;   leaf fabric-id {

         = ;       type = fabric-id;

         = ;   }

        = }

}

To add a node to = fabric:

 

    = rpc add-node-to-fabric {

        input = {

         = ;   leaf fabric-id {

         = ;       type = fabric-id;

         = ;   }

         = ;   uses device-attributes;

        = }

    = }

Do you suggest we bring it back to the = draft?

 

What is policy driven traffic behavior? Is there = the only one policy that fits all possible deployment = scenarios?

[Y] Policy is needed for the traffic otherwise the = traffic will be discard. There can also be normal, which means no policy = is needed for all traffic.

 

Looking at the history of the document from the = individual submission time and the comments received, it seems that the = point fixes to the text went in to cover the specific comments but not = to address the broader scope of comments.

The document would definitely benefit from a major = rewrite clarifying the logic behind the decisions made, aligning more = with the operational practice of fabric based network design and = deployment, and bringing the content in YANG modules to be = self-describing.

 

 

----------------------------------------------------= ------------------

COMMENT:

----------------------------------------------------= ------------------

 

Fabric = and POD are not equivalent terms.

 

I2RS = use case requirements document has expired 11 months ago. Use cases = documents are good for tracking the work progress of specification = documents, it is questionable whether standalone use cases documents = provide value beyond historic record. Is the reference to I2RS use cases = document really needed?

[Y] The reference will be removed in = v09.

 

What is atomic network?

[Y] The original sentence = might be confusing. How about we changing it to =E2=80=9Ca POD can be = considered as a basic structure for management = purposes.=E2=80=9D?

 

VLAN is not a fabric building technology as such, = while Ethernet is.

 

What = is the need for VNI capacity leaves? What is their effect if = configured?

[Y] It is used to say the range of the VNIs for a = POD. We will update the description to clarify = it.

 

The document intermixes ietf-fabric-* and = ietf-dc-fabric-* namespaces.

[Y] Apologize for the inconsistent. It will be = changed to ietf-dc-fabric-* in v09.

 

Serial = port-type is present while Infiniband is not - Infiniband based fabrics = are widely deployed. What is the extensibility mechanism for adding in = new port types?

[Y] Since the port-type is identityref, new port = types can be added by defining new identities.

 

Is = there any deployment experience with this model? The ODL faas project = hasn't got much activity over last two years. Are you aware of any other = implementations or deployments?

[Y] Yes, the = implementation is in ODL FAAS. Current module is a part of fass project. = It has been done over two years and only maintenance is needed. And we = think it is stable.

------=_NextPart_000_01D9_01D3CC07.2ED2F150-- From nobody Wed Apr 4 08:43:02 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E9112DA3E; Wed, 4 Apr 2018 08:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 7ChW3Ou9HLpb; Wed, 4 Apr 2018 08:42:59 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 5E08512DA0A; Wed, 4 Apr 2018 08:42:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Ben Campbell'" Cc: "'The IESG'" , , , References: <152280878408.24068.18282293731508698195.idtracker@ietfa.amsl.com> <005701d3cbbd$186f6f50$494e4df0$@ndzh.com> In-Reply-To: Date: Wed, 4 Apr 2018 11:42:55 -0400 Message-ID: <020201d3cc2b$9a49bc60$cedd3520$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMYVVDP590Qk93ZoU6803frp46xowIZkFikAXfcMZChSyADsA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:43:01 -0000 Ben:=20 Thank you for the comment. Yan will attempt to address this confusion. = As shepherd, I'm trying to sort out what specific meets the DISCUSS = criteria - so I'm looking for clues in all the email from the IESG. = Some of Ignas' suggest changes go against previous ADs/WGs comments. This often happens after time we change a major OPS role. I just wish = these drafts had not been delayed from their original IESG review.=20 Sue Hares=20 -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Wednesday, April 4, 2018 10:34 AM To: Susan Hares Cc: The IESG; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; = i2rs-chairs@ietf.org; i2rs@ietf.org Subject: Re: Ben Campbell's No Objection on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT) Specifically, Ignas said: "It is generally true for the context of the overlay but that is not = what the document seems to be focusing on. Fabric defines and implements = the underlay, not the other way around.=E2=80=9D Note that I specifically did not say I =E2=80=9Csupport the = discuss=E2=80=9D, only that that I was confused by the terminology issue = he mentioned in his discuss. Thanks, Ben. > On Apr 3, 2018, at 9:31 PM, Susan Hares wrote: >=20 > Ben: >=20 > Could you unpack the "share concern" on definition of fabric comment a = bit? >=20 > Sue >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, April 3, 2018 10:26 PM > To: The IESG > Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan = Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org > Subject: Ben Campbell's No Objection on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT) >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: No Objection >=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-i2rs-yang-dc-fabric-network-t= opology/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I share Ignas's concern about the definition of "fabric". Otherwise, I = have a couple of nits: >=20 > Abstract: Missing article before "Data Center Network". >=20 > =C2=A72: Please use the boilerplate from RFC 8174 rather than rolling = your own text to constrain the keywords to their all-caps forms. >=20 >=20 >=20 From nobody Wed Apr 4 10:59:40 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3988D129C6E; Wed, 4 Apr 2018 10:59:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152286477322.23998.1237380071004726529.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2018 10:59:33 -0700 Archived-At: Subject: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-yang-dc-fabric-network-topology-08=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:59:33 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-topology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please use RFC 8174 boilerplate! From nobody Wed Apr 4 11:11:19 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C385126BFD; Wed, 4 Apr 2018 11:11:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-i2rs-rib-data-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152286547363.24015.12929083031389820321.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2018 11:11:13 -0700 Archived-At: Subject: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-rib-data-model-10=3A_=28with_COMMENT=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:11:14 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alissa's comments on use of normative language. From nobody Wed Apr 4 11:38:01 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D0412D7E5; Wed, 4 Apr 2018 11:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 S72tNl0w58Hw; Wed, 4 Apr 2018 11:37:55 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 2E76E12D7E2; Wed, 4 Apr 2018 11:37:55 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id f125so45068025wme.4; Wed, 04 Apr 2018 11:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=fti61wp0E2uLBfDZdsggPjDw4GCdmh8k/EPfdM7deSg=; b=q3YG1GwjCMQtxt9kuxiwCUkTTprbkZ1OPIxgQm77Ydk23h+vfSmIqDccHzTX7pQPMv 1za5KP0tK6tE+npX0VZ9hXq6TtcQH+nuzclkMx/TfSDISW6Keo7Vpo/wsaPjZiBOT5yn JoWqB7rzbIbF4wPby4exRLbzX60xdmbpLbSxXVTp4TIVvmzbhkSKsMqyHO1Y8wVVttFm K1AFVTogARbH8glCb5rwM0ogL1D4zE8ORco74FspvDlar4TphM3AVmWixNLXoy8Wn+Mo QN5z175edAyuIzdV4qHjuhEtcpSUz6MlLqX7aWG8wrqXS8cPyCUiU9E7zEvkhFE4ODoR QGyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=fti61wp0E2uLBfDZdsggPjDw4GCdmh8k/EPfdM7deSg=; b=k+f74A5LyI5Oqi2hMO4tyRX1hjyRuWe3sMmYWvM9mmWRKKub5P20BZ+IF62LKJtx/v kZJxBn0ny2NbfNSZ0qZUcK1Vv+8zj49Ko/NBX2g7w69CgLFhyigirflBFc7oz36tdEaG hYHH9kON281MOKRVP2s1Y4TdztoetVM4Kp/VJZVA450Nzdcnkw4znPhQtIt4Bx7OPYDb /utH1CEUBFkcsYVWkNeUKBzjp1ErLiMYe8mjk6EKT/8tSalro4wu3rg9qyZihesQsHdV 4JyZCA87EGtBH7bRbMbqEFI+bruvXZUwvnJfUn5/VEQ1Bb+Wi730+S1HglmiLtDC4jA9 xmDg== X-Gm-Message-State: ALQs6tCni6yLtjgj0Ok28Hq25CAIUzLkiYZuwUDk4eIiTkbTLZKfDHCC snJyx6rY9lUbynQYNzOkn7KhQxwMFok= X-Google-Smtp-Source: AIpwx4/9+fRg7fmMf+ThgZTpkrKzKO0EkcdmIg/XLGiJg6YjoOKLEycjhx0yMLcUbpeKQrfnmEid0Q== X-Received: by 10.28.202.6 with SMTP id a6mr6258779wmg.112.1522867073338; Wed, 04 Apr 2018 11:37:53 -0700 (PDT) Received: from [10.176.38.41] (asa1.am1.corp.eu.equinix.com. [94.103.16.181]) by smtp.gmail.com with ESMTPSA id p14sm12323489wrc.30.2018.04.04.11.37.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 11:37:52 -0700 (PDT) To: Susan Hares , 'The IESG' Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, i2rs-chairs@ietf.org References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <9B4BC45FDEDDD84F813E9E4A5BAF8785A96B7310@nkgeml513-mbs.china.huawei.com> <01d801d3cc28$b5e18410$21a48c30$@ndzh.com> From: Ignas Bagdonas Message-ID: <9d743d24-e4b5-0bcc-eb7e-cdce3f464888@gmail.com> Date: Wed, 4 Apr 2018 19:37:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <01d801d3cc28$b5e18410$21a48c30$@ndzh.com> Content-Type: multipart/alternative; boundary="------------CAEE2E32B2B20F280F94BAB1" Content-Language: en-GB Archived-At: Subject: Re: [i2rs] FW: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:37:59 -0000 This is a multi-part message in MIME format. --------------CAEE2E32B2B20F280F94BAB1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 04/04/2018 16:22, Susan Hares wrote: > > Ignas: > > I’m forwarding Yan’s specific answers to each of your questions. I had > held this response back until I tried to learn more about what > specific questions were tag with specific DISCUSS quality comments > > per the IESG 2014 DISCUSS criteria comments: > > https://www.ietf.org/blog/discuss-criteria-iesg-review/ > > I’m sure Yan will be glad to make adjustments in the draft (see below). > Thank you Yan, this seems to be a practical way forward in bringing clarity to the scope of the document. > You will note that you are asking us to put back in RPCs that others > had us take out. > I will note that I am not asking for anything like that. Please re-read my DISCUSS notes. > This leads me to back to my questions as a Shepherd. My concern is > that many of your requested changes > I recall raising questions, not requesting changes. > are counter to agreements in discussions with WG, TE WG, > NETCONF/NETMOD, and previous ADS (OPS, RTG) regarding I2RS drafts.  >  Since these drafts were delayed due to the reading load of the IESG, > it seems we are working under different rules.  So, please specify how > your comments match the DISCUSS criteria.  If you are setting new > rules for I2RS documents, please detail the new rules of review. > > It is too bad that we could not have reviewed these documents during > their originally scheduled telechat with previous  ADs. > > Susan Hares > > -----Original Message----- > From: Ignas Bagdonas [mailto:ibagdona@gmail.com] > Sent: Tuesday, April 03, 2018 7:40 PM > To: The IESG > > Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org > ; > Susan Hares >; > i2rs-chairs@ietf.org ; shares@ndzh.com > ; i2rs@ietf.org > Subject: Ignas Bagdonas' Discuss on > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and > COMMENT) > > Ignas Bagdonas has entered the following ballot position for > > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-topology/ > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > I have concerns about the practical usability of this proposed model > as it is specified now. > > The intended decoupling of fabric implementation properties (what is > termed as "underlay network infrastructure" in the document) and its > topology seems to be contradicting to general operational practices of > fabric based networks. It is generally true for the context of the > overlay but that is not what the document seems to be focusing on. > Fabric defines and implements the underlay, not the other way around. > > [Y] The intention of this model is to represent the entire topology of > a data center fabric network. > Yan, can you be specific here - the topology of what? Are we talking about the underlay topology, or an overlay instance topology? That is a major difference and many other comments will depend on this answer. The terminology does not help here too much - data center fabric network may mean many different things if viewed from different contexts. > The whole network can be considered as a single fabric network which > is composed by several PODs defined as “node” in this module. Under > these “nodes”, there are supporting-nodes (reference to device-nodes > belonged to the POD) and connections. > > The term of POD/fabric is a bit confusing in the draft. How about we > updating the Terminology section as below? > > POD: a module of network, compute, storage, and application components > that work together to deliver networking services. It represents a > repeatable design pattern. Its components maximize the modularity, > scalability, and manageability of data centers. > > Fabric: composed of several PODs to form a data center network. > > Does it make sense? > It is closer to both the terminology and design used in actual deployments. > The document does not contain a sufficient description of the logic of > the model itself, the reasons for choices made for representation of > types and attributes, and at the same time descriptions in modules are > single lines that do not add clarification beyond being copies of leaf > names. Either there needs to be a section that describes the logic of > the model and how it relates to other models, also including examples, > or module description fields need to have enough content to be able to > have equivalent understanding of model intent and operation. Both are > strongly encouraged, as descriptions have value of itself for being a > reference for use, and model description is needed for understanding > how this particular model fits into the larger hierarchy. Network > management does not end at the boundary of the single domain-specific > model, it is important to build it into a whole system. > > Why TE topology model is not sufficient for modelling the > representation of DC fabric? Why is DC fabric network topology special > compared to any generic fabric based topology? > > [Y] We discussed with TE topology model authors about this question. > For TE, it is more focused on connections for TE and statics for their > performance, while this model is to present how a data center network > look like with its specific nodes(leaf/spine). > Leaf/spine is a node, nodes are interconnected by links. Depends on the context of the earlier question about the underlay and overlay. Links and nodes can definitely be represented by TE model. What is a leaf/spine node in the overlay context? > How this model could be used for representing more than two stage > fabrics that are in wide deployment? > > [Y] In that case, more roles for interlayer devices can be added. The > “role” for device is defined as identity-ref. New roles can be added > by defining new identities. > This needs to be documented. Or, if you intend to limit the scope to two stages (as it is implied at the moment) - this also needs to be explicitly stated in the document. What is an interlayer device? > Limiting port bandwidth to a fixed rate is too restrictive. The model > as specified already does not cover a set of port speeds that are in > deployment. > > [Y] bandwidth is defined as identity-ref. Other speeds can be added by > defining new identities. > Needs to be documented. > How would a device that has more than a single role in the fabric be > represented? > > [Y] The role for a device-node is defined as leaf-list to support a > device with more than one roles. > > Service capabilities as they are described belong to the overlay > context while they are called device capabilities. Are those the only > possible service capabilities? What is the effect of configuring those > capabilities? > > [Y] Service capabilities is for a fabric not a device. The description > for the service capabilities will be corrected. For better extension > for other services, we will change current enumeration type to > identity-ref. More service identities can be defined in the future by > vendors. > The extensibility mechanism needs to be documented. > What is compose-fabric RPC? The document does not define any RPCs. > > [Y] rpcs were removed in previous version since people say it would > leave for vendor-specific implementation. > > The rpcs to compose a fabric is as: > >     rpc compose-fabric { > >         input { > >             uses fabric-attributes; > >         } > >         output { > >             leaf fabric-id { > > type fabric-id; > >             } > >         } > > } > > To add a node to fabric: > >     rpc add-node-to-fabric { > >         input { > >             leaf fabric-id { > >                 type fabric-id; > >             } > >             uses device-attributes; > >         } > >     } > > Do you suggest we bring it back to the draft? > I am not suggesting anything, I was asking about the compose-fabric RPC that was mentioned in the document. > What is policy driven traffic behavior? Is there the only one policy > that fits all possible deployment scenarios? > > [Y] Policy is needed for the traffic otherwise the traffic will be > discard. There can also be normal, which means no policy is needed for > all traffic. > It needs to be documented on what is meant by policy - what is the purpose of that policy, where and how it should be instantiated. > Looking at the history of the document from the individual submission > time and the comments received, it seems that the point fixes to the > text went in to cover the specific comments but not to address the > broader scope of comments. > > The document would definitely benefit from a major rewrite clarifying > the logic behind the decisions made, aligning more with the > operational practice of fabric based network design and deployment, > and bringing the content in YANG modules to be self-describing. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > Fabric and POD are not equivalent terms. > > I2RS use case requirements document has expired 11 months ago. Use > cases documents are good for tracking the work progress of > specification documents, it is questionable whether standalone use > cases documents provide value beyond historic record. Is the reference > to I2RS use cases document really needed? > > [Y] The reference will be removed in v09. > > What is atomic network? > > [Y] The original sentence might be confusing. How about we changing it > to “a POD can be considered as a basic structure for management > purposes.”? > What is a basic structure then? If this is in overlay context then it is not obvious what POD means there. If this is in underlay context then conceptually it is clear but quite far away from operational reality. > VLAN is not a fabric building technology as such, while Ethernet is. > > What is the need for VNI capacity leaves? What is their effect if > configured? > > [Y] It is used to say the range of the VNIs for a POD. We will update > the description to clarify it. > > The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces. > > [Y] Apologize for the inconsistent. It will be changed to > ietf-dc-fabric-* in v09. > > Serial port-type is present while Infiniband is not - Infiniband based > fabrics are widely deployed. What is the extensibility mechanism for > adding in new port types? > > [Y] Since the port-type is identityref, new port types can be added by > defining new identities. > Please document the extensibility. > Is there any deployment experience with this model? The ODL faas > project hasn't got much activity over last two years. Are you aware of > any other implementations or deployments? > > [Y] Yes, the implementation is in ODL FAAS. Current module is a part > of fass project. It has been done over two years and only maintenance > is needed. And we think it is stable. > Good. So this in fact is closer to FAAS and therefore the context of the document is the overlay. The document needs to state that clearly. Overall it seems that what is missing in the document is the context clarification. Once the context of this model is clearly defined the rest of comments will be easier to address. Thank you. Ignas --------------CAEE2E32B2B20F280F94BAB1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 04/04/2018 16:22, Susan Hares wrote:

Ignas:

 

I’m forwarding Yan’s specific answers to each of your questions. I had held this response back until I tried to learn more about what specific questions were tag with specific DISCUSS quality comments

per the IESG 2014 DISCUSS criteria comments:

https://www.ietf.org/blog/discuss-criteria-iesg-review/

 

I’m sure Yan will be glad to make adjustments in the draft (see below). 


Thank you Yan, this seems to be a practical way forward in bringing clarity to the scope of the document.



You will note that you are asking us to put back in RPCs that others had us take out.  


I will note that I am not asking for anything like that. Please re-read my DISCUSS notes.

 

This leads me to back to my questions as a Shepherd. My concern is that many of your requested changes


I recall raising questions, not requesting changes.

are counter to agreements in discussions with WG, TE WG, NETCONF/NETMOD, and previous ADS (OPS, RTG) regarding I2RS drafts.   Since these drafts were delayed due to the reading load of the IESG, it seems we are working under different rules.  So, please specify how your comments match the DISCUSS criteria.  If you are setting new rules for I2RS documents, please detail the new rules of review.   

 

It is too bad that we could not have reviewed these documents during their originally scheduled telechat with previous  ADs. 

 

Susan Hares

 

-----Original Message-----
From: Ignas Bagdonas [mailto:ibagdona@gmail.com]
Sent: Tuesday, April 03, 2018 7:40 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan Hares <shares@ndzh.com>; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org
Subject: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

 

Ignas Bagdonas has entered the following ballot position for

draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-topology/

 

 

 

----------------------------------------------------------------------

DISCUSS:

----------------------------------------------------------------------

 

I have concerns about the practical usability of this proposed model as it is specified now.

 

The intended decoupling of fabric implementation properties (what is termed as "underlay network infrastructure" in the document) and its topology seems to be contradicting to general operational practices of fabric based networks. It is generally true for the context of the overlay but that is not what the document seems to be focusing on. Fabric defines and implements the underlay, not the other way around.

[Y] The intention of this model is to represent the entire topology of a data center fabric network.


Yan, can you be specific here - the topology of what? Are we talking about the underlay topology, or an overlay instance topology? That is a major difference and many other comments will depend on this answer. The terminology does not help here too much - data center fabric network may mean many different things if viewed from different contexts.

The whole network can be considered as a single fabric network which is composed by several PODs defined as “node” in this module. Under these “nodes”, there are supporting-nodes (reference to device-nodes belonged to the POD) and connections.

 

The term of POD/fabric is a bit confusing in the draft. How about we updating the Terminology section as below?

POD: a module of network, compute, storage, and application components that work together to deliver networking services. It represents a repeatable design pattern. Its components maximize the modularity, scalability, and manageability of data centers.

Fabric: composed of several PODs to form a data center network.

 

Does it make sense?

 

It is closer to both the terminology and design used in actual deployments.


The document does not contain a sufficient description of the logic of the model itself, the reasons for choices made for representation of types and attributes, and at the same time descriptions in modules are single lines that do not add clarification beyond being copies of leaf names. Either there needs to be a section that describes the logic of the model and how it relates to other models, also including examples, or module description fields need to have enough content to be able to have equivalent understanding of model intent and operation. Both are strongly encouraged, as descriptions have value of itself for being a reference for use, and model description is needed for understanding how this particular model fits into the larger hierarchy. Network management does not end at the boundary of the single domain-specific model, it is important to build it into a whole system.

 

Why TE topology model is not sufficient for modelling the representation of DC fabric? Why is DC fabric network topology special compared to any generic fabric based topology?

[Y] We discussed with TE topology model authors about this question. For TE, it is more focused on connections for TE and statics for their performance, while this model is to present how a data center network look like with its specific nodes(leaf/spine).


Leaf/spine is a node, nodes are interconnected by links. Depends on the context of the earlier question about the underlay and overlay. Links and nodes can definitely be represented by TE model. What is a leaf/spine node in the overlay context?

 

How this model could be used for representing more than two stage fabrics that are in wide deployment?

[Y] In that case, more roles for interlayer devices can be added. The “role” for device is defined as identity-ref. New roles can be added by defining new identities.

This needs to be documented. Or, if you intend to limit the scope to two stages (as it is implied at the moment) - this also needs to be explicitly stated in the document. What is an interlayer device?

 

Limiting port bandwidth to a fixed rate is too restrictive. The model as specified already does not cover a set of port speeds that are in deployment.

[Y] bandwidth is defined as identity-ref. Other speeds can be added by defining new identities.

 

Needs to be documented.


How would a device that has more than a single role in the fabric be represented?

[Y] The role for a device-node is defined as leaf-list to support a device with more than one roles.

 

Service capabilities as they are described belong to the overlay context while they are called device capabilities. Are those the only possible service capabilities? What is the effect of configuring those capabilities?

[Y] Service capabilities is for a fabric not a device. The description for the service capabilities will be corrected. For better extension for other services, we will change current enumeration type to identity-ref. More service identities can be defined in the future by vendors.

The extensibility mechanism needs to be documented.

 

What is compose-fabric RPC? The document does not define any RPCs.

[Y] rpcs were removed in previous version since people say it would leave for vendor-specific implementation.

The rpcs to compose a fabric is as:

    rpc compose-fabric {

        input {

            uses fabric-attributes;

        }

        output {

            leaf fabric-id {

                type fabric-id;

            }

        }

}

To add a node to fabric:

 

    rpc add-node-to-fabric {

        input {

            leaf fabric-id {

                type fabric-id;

            }

            uses device-attributes;

        }

    }

Do you suggest we bring it back to the draft?

I am not suggesting anything, I was asking about the compose-fabric RPC that was mentioned in the document.

 

What is policy driven traffic behavior? Is there the only one policy that fits all possible deployment scenarios?

[Y] Policy is needed for the traffic otherwise the traffic will be discard. There can also be normal, which means no policy is needed for all traffic.

 

It needs to be documented on what is meant by policy - what is the purpose of that policy, where and how it should be instantiated.

Looking at the history of the document from the individual submission time and the comments received, it seems that the point fixes to the text went in to cover the specific comments but not to address the broader scope of comments.

The document would definitely benefit from a major rewrite clarifying the logic behind the decisions made, aligning more with the operational practice of fabric based network design and deployment, and bringing the content in YANG modules to be self-describing.

 

 

----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------

 

Fabric and POD are not equivalent terms.

 

I2RS use case requirements document has expired 11 months ago. Use cases documents are good for tracking the work progress of specification documents, it is questionable whether standalone use cases documents provide value beyond historic record. Is the reference to I2RS use cases document really needed?

[Y] The reference will be removed in v09.

 

What is atomic network?

[Y] The original sentence might be confusing. How about we changing it to “a POD can be considered as a basic structure for management purposes.”?

 

What is a basic structure then? If this is in overlay context then it is not obvious what POD means there. If this is in underlay context then conceptually it is clear but quite far away from operational reality.

VLAN is not a fabric building technology as such, while Ethernet is.

 

What is the need for VNI capacity leaves? What is their effect if configured?

[Y] It is used to say the range of the VNIs for a POD. We will update the description to clarify it.

 

The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces.

[Y] Apologize for the inconsistent. It will be changed to ietf-dc-fabric-* in v09.

 

Serial port-type is present while Infiniband is not - Infiniband based fabrics are widely deployed. What is the extensibility mechanism for adding in new port types?

[Y] Since the port-type is identityref, new port types can be added by defining new identities.

Please document the extensibility.

 

Is there any deployment experience with this model? The ODL faas project hasn't got much activity over last two years. Are you aware of any other implementations or deployments?

[Y] Yes, the implementation is in ODL FAAS. Current module is a part of fass project. It has been done over two years and only maintenance is needed. And we think it is stable.


Good. So this in fact is closer to FAAS and therefore the context of the document is the overlay. The document needs to state that clearly.

Overall it seems that what is missing in the document is the context clarification. Once the context of this model is clearly defined the rest of comments will be easier to address.

Thank you.

Ignas
 

--------------CAEE2E32B2B20F280F94BAB1-- From nobody Wed Apr 4 11:40:36 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39C31243F6; Wed, 4 Apr 2018 11:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 jA1ELkn690zq; Wed, 4 Apr 2018 11:40:25 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 D8575127023; Wed, 4 Apr 2018 11:40:24 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id d17so8931869wre.1; Wed, 04 Apr 2018 11:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=lE9gW2F21kHZpTmoh33LemnKlVMx85QEQ3RjQu3a3no=; b=JwzeNM70SnqXEapqrkNnUiUwb5sih4MU6EhruvJY2Br0bvajjPvOTrhoowyJBCSY7C bscwtwApkeTgQgTMcSMeftrPjLvloI9V6WZvr1dYT4R7I5ZR76AS2x2dGsPa7zaEeHgt FklzpDwov8DwruHq/L2GIL9nlnddojtTqrsKQk42JNS8NKZznk9R6CKPtFJ45tHO/2r3 ZN/+h782V29bG+WkipPkQdc7epX1DrVntivUeOldk9kMdQWSbMwqKbX5CDqXpoRBiWQ+ zPSB9DdTKQXSqrABhdyKflXhx0eYdMf6Jaa88UaUy2EPkK8ujs5KTpUvhZwVtmyIqKpT L1jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=lE9gW2F21kHZpTmoh33LemnKlVMx85QEQ3RjQu3a3no=; b=VwEX37wCR5JmRp5lmYwG+gEqpAdZVZt2qOffdjhPOdSGOwHD1jA9gA5V4r6ZIEwIVb 3cO7HHcKxETMSYHepCEG2slKW0kVGubFPGWS9Xvw6hNNdEG4/Tiz1OhLAtjGDZ5lh8WK 0afk5gLSu6ZmI1L/fIGokJ7wELoM8j6eEv84A2YHrcv10oxxQDGSkc1uYT0MeCQlujXR 8RXUbx5ine3RyhUGlLqsHK8uVdm0c+OrXGzGo2ICFE+8OImKYbFsyskciaBTP/MQXg97 qb2IeOZvxMt1CHcBTgvUhQA/KPGof882ZwKG/oBYETlRFq/lay2+SzdiQMuyO7V3snjr 2szg== X-Gm-Message-State: AElRT7HgBia+Ez06UnPsV80E6Us0MjtUyQ1oaUASegsOKFMJ6IGyQvAc IA5OvT/ghIuIFJ1MoQ1PKjVLRFuKxhg= X-Google-Smtp-Source: AIpwx4+3snGH4hyU+XgSTqK4jfQ0ms2PSPCUv+YWQeHdLxjrCoIHF5cR4TYRXhxkjXLHXZx6g3UjfA== X-Received: by 10.223.171.26 with SMTP id q26mr14371754wrc.183.1522867223032; Wed, 04 Apr 2018 11:40:23 -0700 (PDT) Received: from [10.176.38.41] (asa1.am1.corp.eu.equinix.com. [94.103.16.181]) by smtp.gmail.com with ESMTPSA id g4sm6842468wrd.1.2018.04.04.11.40.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 11:40:22 -0700 (PDT) To: Susan Hares , 'The IESG' Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, i2rs-chairs@ietf.org References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <01c701d3cc26$09865b20$1c931160$@ndzh.com> From: Ignas Bagdonas Message-ID: Date: Wed, 4 Apr 2018 19:40:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <01c701d3cc26$09865b20$1c931160$@ndzh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:40:28 -0000 On 04/04/2018 16:03, Susan Hares wrote: > Ignas: > > I am not trying to clarify the specifics. This response (as I mentioned), will come from the authors. As a shepherd/WG chair, I am asking for information regarding the basis of your DISCUSS models for specific points. > > The 2014 document on the IESG discuss criteria is at: > https://www.ietf.org/blog/discuss-criteria-iesg-review/ > > What on this list does the following comment refer to: > "Why DISCUSS? DC fabric is a type of network topology, yes, it has some specifics, but nothing radically different than any purpose built network topology. Developing a separate model for a specific use case at the same time when there is generic and extensible TE model is questionable." The fact that for managing similar functionality there appears to be a need for different models that would as a result require different model lifecycle management clearly falls into the category of operational issues. > Perhaps you are not considering the fact this is an I2RS model. Let me provide 3 comments regaring that point: I am considering the fact that this model defines configuration of something that is widely deployed in a way that is not compatible with how it is deployed. The fact that this may be I2RS model is not of the primary importance. > > 1st - I2RS is focusing on models that are capable for the dynamic state and configuration state. These models have qualitative differences. The mechanisms of a model which does both dynamic state and configuration state is qualitative different that the basic TE models. This model extends the TE models toward this approach (see module ietf-dc-fabric-topology reference import of ietf-network-topology). > > 2nd - During the I2RS process we talked to the TE topology authors and the TE WG. We agreed that this model has differences. As a WG Co-chair, I spent time reviewing this interaction. > > 3rd - How many of the user community have implemented I2RS dynamic models or the RFC version of the TE models? I am aware of 1 I2RS model family implementation. I am aware of 4 TE model implementations that I happen to use daily, and aware of several more that I do not deal with. And I am not certain what value such counting of implementations brings to this discussion. > See the comments from Chris Hopps and others on slow pace of the netconf work. If you are going to restrict to two deployed implementations, you will be joining the IDR camp of requirements and slowing the work further. The only reason we require 2 implementations for IDR is for the fragile BGP environment and that operators request it due to the global consequences. Network Management of these early yang models have a much more restricted case. May I ask you to point to where I have said anything about two deployed implementations? Ignas > Sue Hares > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ignas Bagdonas > Sent: Wednesday, April 4, 2018 10:31 AM > To: Susan Hares; 'The IESG' > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) > > Hi Sue, > > > On 03/04/2018 14:59, Susan Hares wrote: >> Ignas: >> >> Yan will answer for the authors but I would like to share some information related to the I2RS working group reviews. In your response, please specify why each question is a "DISCUSS" quality question rather than a "Comment" question. The authors and I (as the shepherd) will work to resolve both DISCUSS and comment issues. >> >> Let me review only 5 of your many points because they are pointing in a direction which is different from earlier QA reviews of this document (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 timeframe. >> 1st - Why TE topology model is not sufficient for modelling the representation of DC fabric? Why is DC fabric network topology special compared to any generic fabric based topology? > Why DISCUSS? DC fabric is a type of network topology, yes, it has some specifics, but nothing radically different than any purpose built network topology. Developing a separate model for a specific use case at the same time when there is generic and extensible TE model is questionable. > >> This document was reviewed by authors with the TE topology models to make sure there was no conflict or duplication. >> >> Your question implies that only one yang model is appropriate for each type of fabric. > That is exactly opposite. What is special about DC fabric that it has to have a separate model? What is special about fabric type of topology that it has to have a separate model? Why is TE model not suitable? > >> This theory of one yang mode per fabric does not apply to dynamic (ephemeral) datastore versus configuration datastore models. It is also not true of all models even within the configuration datastore. >> Since there is a yang catalog and selection of yang models is specific to a implemented, there has been no early winnowing of the yang models per type. If you are insisting on this theory of "one yang model" per fabric type, please provide an RFC reference so that I can help review this DISCUSS criteria with the authors. >> >> This yang model has been implemented by 1 vendor, and there was interest by other vendors. A deployment target has been identified for this model, and feedback is expected from the users. > Excellent. Please get feedback from user community - even if it is not yet implemented and operations groups will not be able to provide feedback, architecture and engineering groups look into upcoming things and will have what to say. > > Speaking of implementations, the ODL faas project (from where the majority of this model seems to be coming from) deals with an instance of overlay that is subsequently treated as an underlay, and that is different that the underlay on top of which that instance is being run. > If the model focus is on the "fabric as a service" type of topologies then it explicitly needs to state that, and then justify why physical node properties exist together with logical instance properties in that case. > > >> If you are asking this model to cover three-four layer datacenters, this approach is opposite some of the initial feedback to the group to keep the initial model - that is to keep it simple and restricted to 2 layers in order to test the concepts. If you are asking to provide text (in introduction or appendix) that indicates the initial focus, this can be added. > The document as it is written now tries to cover every possible fabric. > If the scope is intended to be narrower - it needs to be stated. > Starting from bounded scope is certainly a right thing to do but that is not how the document reads now. > > >> 2nd - Multiple layers and multiple roles. > Why DISCUSS? Two stage fabrics and fabrics with a perfectly clean node > role separation do indeed exist, but that is not necessary a common > deployment model. The document assumes that those are the only possible > options. > >> The authors provide slides in several meetings I2RS meeting repository regarding this point. >> The initial feedback suggested reducing the "why" text within the draft. Again, the initial feedback was to reduce the initial model's text to 2 layers and simple "whys". See proceedings from IETF 95 forward on I2RS on fabric data model for discussions. > Would users of this model also be required to lookup proceedings of past > IETF meetings in order to understand whether it may fit their use cases? > > >> 3rd - The authors will comment on the port restrictions. Early feedback during the I2RS meetings from vendors may have taken the authors down this path. In my review, I expect major issues in this area - but I will let the authors comment. > Why DISCUSS? The way how the model specifies port speeds is conflicting > with common deployment practices. > >> 4 - policy is simple. >> >> Again, the initial feedback was to keep initial policies simple and gain feedback from the deployments. > Why DISCUSS? What kind of policy is being discussed here? The assumption > of one single universal policy fitting all deployments and use cases > contradicts to operational reality. > > "Policy is simple" does not clarify what kind of policy it is. > >> 5 - You indicate that the document requires a "major" rewrite clarifying the logic. > Why DISCUSS? Model tries to prescribe a way how all DC networks should > be built. It intermixes concepts of underlay and overlay. There are > nodes in the model with unclear purpose and no documented details on > what and how they are doing. > >> Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested taking out the lengthy descriptions regarding logic and history. If we are switching the rules for the YANG models, would you please update the requirements for the YANG models so that shepherds, rtg-dir, ops-dir, and yang-doctors can have rules for review clearly spelled out. > YANG models, and any other deliverables of the IETF, are targetted to > the users of those deliverables and not necessary to the IETF itself. > The situation with YANG models is that the main consumer of IETF YANG > model for a noticeable period was IETF itself - it was required to > build the sufficient coverage of models for them to be practically > useful. We as an industry start to see more practical use of YANG > modules, and so far the main obstacle for YANG acceptance is the > difficulty in trying to use it. It is incorrect to assume that outside > of the IETF WGs that deal with developing the models there is enough of > understanding of the reasoning behind modelling decisions made. It is > incorrect to assume that potential users of such models would try to > lookup proceedings of past IETF meeting trying to get answers - they > will chose other manageability technologies instead. YANG models need to > be self-contained from the practical usability perspective - the models > themselves should contain enough and meaningful descriptions of the > nodes that it would not raise questions for users trying to deploy those > models. Descriptions equivalent to those found in command line > interfaces - if YANG is expected to become a new command line interface, > it should be no worse than the command line interface. The reasoning > behind modelling decisions made also need to be documented - at least > for allowing model users to see whether the model is suitable for > deployment in the particular environment. As YANG is maturing and > starting to be deployed, naturally the focus of reviews will change to > reflect what is required for successful deployment of the technology. > >> Summary on Shepherd's comment: >> >> The authors will respond to others specifics, but in order to guide these diligent authors - I need to know what rules you are setting for the 2018 IESG approval of YANG models. If you are placing a DISCUSS on a YANG model based on a set criteria, the criteria needs to be published on a web page or in an RFC. If I've missed this criteria that the OPS Area has specified, > RFC6087 and draft-ietf-netmod-rfc6087bis. > > There are two parts that are important for reviews - the model itself, > and how the model applies to the managed entities. And there is nothing > new in the review criteria. The former is rather not that complex, and > typically can be done within IETF itself. The latter is more complex and > generally would require feedback from the target users of the model. > There is a balance between a model being too generic to be practically > usable and model being too prescriptive to be practically usable. If the > model puts requirements and restrictions on the managed entities in a > way that requires to build those managed entities in a specific way, > predefined by the model authors, the value of such model is > questionable. Speaking specifically about DC fabric model, it puts > network design prescriptions that are significantly misaligned with how > fabric based networks have been and are built. Yes, it is possible to > find environments where the model would apply directly and with no > impact, but one would need to look for such deployments quite hard, and > with a high probability that would be proof of concept or technology > demonstration type of environments. > > IETF is good at developing technology components and fragments, IETF > typically is not good at dealing with network design and how those > fragments need to be bound together - that is the reality, and that is > not necessarily wrong. IETF should be focusing on what it can do best - > the fragments, and align with users of the fragments on how to improve > the fragments but not try to direct how users should be building their > networks. It is important for the reputation of IETF as a credible SDO - > if IETF manageability mechanisms propose and enforce not necessarily > right - or just plain broken - network designs, that is a reputation > problem. This document tends to be proposed standard, and that sets a > strong message. > > Ignas > > >> Thank you for your review, >> Susan Hares >> >> -----Original Message----- >> From: Ignas Bagdonas [mailto:ibagdona@gmail.com] >> Sent: Tuesday, April 3, 2018 7:40 AM >> To: The IESG >> Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >> Subject: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) >> >> Ignas Bagdonas has entered the following ballot position for >> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-topology/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I have concerns about the practical usability of this proposed model as it is specified now. >> >> The intended decoupling of fabric implementation properties (what is termed as "underlay network infrastructure" in the document) and its topology seems to be contradicting to general operational practices of fabric based networks. It is generally true for the context of the overlay but that is not what the document seems to be focusing on. Fabric defines and implements the underlay, not the other way around. >> >> The document does not contain a sufficient description of the logic of the model itself, the reasons for choices made for representation of types and attributes, and at the same time descriptions in modules are single lines that do not add clarification beyond being copies of leaf names. Either there needs to be a section that describes the logic of the model and how it relates to other models, also including examples, or module description fields need to have enough content to be able to have equivalent understanding of model intent and operation. Both are strongly encouraged, as descriptions have value of itself for being a reference for use, and model description is needed for understanding how this particular model fits into the larger hierarchy. Network management does not end at the boundary of the single domain-specific model, it is important to build it into a whole system. >> >> Why TE topology model is not sufficient for modelling the representation of DC fabric? Why is DC fabric network topology special compared to any generic fabric based topology? >> >> How this model could be used for representing more than two stage fabrics that are in wide deployment? >> >> Limiting port bandwidth to a fixed rate is too restrictive. The model as specified already does not cover a set of port speeds that are in deployment. >> >> How would a device that has more than a single role in the fabric be represented? >> >> Service capabilities as they are described belong to the overlay context while they are called device capabilities. Are those the only possible service capabilities? What is the effect of configuring those capabilities? >> >> What is compose-fabric RPC? The document does not define any RPCs. >> >> What is policy driven traffic behavior? Is there the only one policy that fits all possible deployment scenarios? >> >> Looking at the history of the document from the individual submission time and the comments received, it seems that the point fixes to the text went in to cover the specific comments but not to address the broader scope of comments. >> The document would definitely benefit from a major rewrite clarifying the logic behind the decisions made, aligning more with the operational practice of fabric based network design and deployment, and bringing the content in YANG modules to be self-describing. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Fabric and POD are not equivalent terms. >> >> I2RS use case requirements document has expired 11 months ago. Use cases documents are good for tracking the work progress of specification documents, it is questionable whether standalone use cases documents provide value beyond historic record. Is the reference to I2RS use cases document really needed? >> >> What is atomic network? >> >> VLAN is not a fabric building technology as such, while Ethernet is. >> >> What is the need for VNI capacity leaves? What is their effect if configured? >> >> The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces. >> >> Serial port-type is present while Infiniband is not - Infiniband based fabrics are widely deployed. What is the extensibility mechanism for adding in new port types? >> >> Is there any deployment experience with this model? The ODL faas project hasn't got much activity over last two years. Are you aware of any other implementations or deployments? >> >> >> > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Apr 4 13:50:34 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C5912DA68; Wed, 4 Apr 2018 13:50:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sarah Banks To: Cc: i2rs@ietf.org, draft-ietf-i2rs-rib-data-model.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152287502690.23944.16141591280916420608@ietfa.amsl.com> Date: Wed, 04 Apr 2018 13:50:26 -0700 Archived-At: Subject: [i2rs] Opsdir early review of draft-ietf-i2rs-rib-data-model-10 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 20:50:27 -0000 Reviewer: Sarah Banks Review result: Has Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Upon review, I think the document is in decent shape, but needs work in the WG first. There are 3 things I'd like to point out: 1. There are areas in the document where we assume the reader knows , but the document text could be helped if the authors were more concise in their wording. For example: "At the same time, nexthop chains can be used to specify multiple headers over a packet, before that particular packet is forwarded. Not every network device will be able to support all kinds of nexthop chains along with the arbitrary number of headers which are chained together." I would think that while this might often be true, it doesn't have to always be true, and depending on how wide the domain is, it might not be true. I realize this isn't written with normative language, and it's a minor point, but it lacks precision. 2. Nits has issues. Yup, a lot of authors think we'll just toss it in the queue and let the RFC Editors fix this, but I think it's our job to be sending clean docs into the queue. We pay for the RFC Editors service, why have them spending time on things we have a tool that allows the authors to do this for themselves? Fix your nits. :) 3. The document violates the number of named authors at the top - another expense of RFC Editors time and effort I don't think we should be doing. I'd prefer to see the authors/WG/WG Chairs address these items before they go into the queue. Thanks Sarah From nobody Wed Apr 4 14:11:00 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC18D126BF0; Wed, 4 Apr 2018 14:10:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-i2rs-rib-info-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152287625876.23944.6613388936260553654.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2018 14:10:58 -0700 Archived-At: Subject: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 21:10:59 -0000 Ben Campbell has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [I do not expect a change this late in the process due to the following comment; I make more in hopes it will be helpful in the future] I don't think the use of 2119/8174 in this draft adds value, and may even be counterproductive. Many of the instances use keywords to make definitions rather than normative requirements. For example, a statement of the form "Foo MUST contain these mandatory fields" is equivalent to "Foo contains these mandatory fields". In most cases, a draft of this nature is better off just using descriptive language. From nobody Wed Apr 4 15:08:37 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D51512D875; Wed, 4 Apr 2018 15:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 hrup2ai2qafO; Wed, 4 Apr 2018 15:08:32 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3A65212D86C; Wed, 4 Apr 2018 15:08:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Ignas Bagdonas'" , "'The IESG'" Cc: , , References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <01c701d3cc26$09865b20$1c931160$@ndzh.com> In-Reply-To: Date: Wed, 4 Apr 2018 18:08:27 -0400 Message-ID: <02cf01d3cc61$75e803f0$61b80bd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrfpTnkeJxdov8ELnNq0f+qOuaSgCz2sVuAohvGooB77/MfwGGdu5Jo4wrSTA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 22:08:35 -0000 Ignas: I'm not saying yes/no to change this model. I've forwarded Yan's = comments regarding changes to your specific issues. Yan is very = proactive. It is likely that she will change most of the details if you = respond to her.=20 I am acting as a shepherd/WG chair. I'm trying to determine Discuss = Criteria are you using from the following document are you using to = restrict I2RS models (dynamic + configuration capable) because there are = TE specific models in the same area: =20 https://www.ietf.org/blog/discuss-criteria-iesg-review/ This goes against the design criteria I2RS has used.=20 You asked for text sequences that lead me to this conclusion:=20 (1st thread):=20 [Ignas] > Excellent. Please get feedback from user community - even if = it is not yet implemented and operations groups will not be able to = provide feedback, architecture and engineering groups look into upcoming = things and will have what to say. [Sue]: (Repeating earlier comments from email and shepherd's ) We = obtain a vendor (Huawei) and a target deployment situation (Data = Centers) with two potential data centers in China who wanted to work = with this type of logical deployment. To this shepherd's eyes, this is = the operational information. =20 [Sue] (new clarifying comments): If you are still objecting, what else = do you want as proof that the WG did due diligence on obtaining the = operational feedback for deployment of a model which has I2RS = capabilities (dynamic and configuration) must be judged against any TE = (configuration only ) data models.=20 (2) Further indication that you are comparing I2RS data models against = the 4 TE models without a consideration to dynamic datastore design = issues:=20 [Sue's comment]: 3rd - How many of the user community have implemented = I2RS dynamic models or the RFC version of the TE models? [Ignas] I am aware of 1 I2RS model family implementation. I am aware of = 4 TE model implementations that I happen to use daily, and aware of = several more that I do not deal with. And I am not certain what value = such counting of implementations brings to this discussion. Summary of my question:=20 I2RS models (configuration and dynamic) are different than regular TE = models and you are lumping the I2RS models in with the configuration = datastore TE models. Please provide me with the DISCUSS criteria or = RFCs you are using to make categorization. =20 After we settle on these issues, we can go on to the other comments.=20 Sue Hares=20 -----Original Message----- From: Ignas Bagdonas [mailto:ibagdona@gmail.com]=20 Sent: Wednesday, April 4, 2018 2:40 PM To: Susan Hares; 'The IESG' Cc: i2rs@ietf.org; = draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; = i2rs-chairs@ietf.org Subject: Re: [i2rs] Ignas Bagdonas' Discuss on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = COMMENT) On 04/04/2018 16:03, Susan Hares wrote: > Ignas: > > I am not trying to clarify the specifics. This response (as I = mentioned), will come from the authors. As a shepherd/WG chair, I am = asking for information regarding the basis of your DISCUSS models for = specific points. > > The 2014 document on the IESG discuss criteria is at: > https://www.ietf.org/blog/discuss-criteria-iesg-review/ > > What on this list does the following comment refer to: > "Why DISCUSS? DC fabric is a type of network topology, yes, it has = some specifics, but nothing radically different than any purpose built = network topology. Developing a separate model for a specific use case at = the same time when there is generic and extensible TE model is = questionable." The fact that for managing similar functionality there appears to be a = need for different models that would as a result require different model = lifecycle management clearly falls into the category of operational = issues. > Perhaps you are not considering the fact this is an I2RS model. Let = me provide 3 comments regaring that point: I am considering the fact that this model defines configuration of = something that is widely deployed in a way that is not compatible with = how it is deployed. The fact that this may be I2RS model is not of the = primary importance. > =20 > 1st - I2RS is focusing on models that are capable for the dynamic = state and configuration state. These models have qualitative = differences. The mechanisms of a model which does both dynamic state = and configuration state is qualitative different that the basic TE = models. This model extends the TE models toward this approach (see = module ietf-dc-fabric-topology reference import of = ietf-network-topology). > =20 > 2nd - During the I2RS process we talked to the TE topology authors and = the TE WG. We agreed that this model has differences. As a WG = Co-chair, I spent time reviewing this interaction. > > 3rd - How many of the user community have implemented I2RS dynamic = models or the RFC version of the TE models? I am aware of 1 I2RS model family implementation. I am aware of 4 TE = model implementations that I happen to use daily, and aware of several = more that I do not deal with. And I am not certain what value such = counting of implementations brings to this discussion. > See the comments from Chris Hopps and others on slow pace of the = netconf work. If you are going to restrict to two deployed = implementations, you will be joining the IDR camp of requirements and = slowing the work further. The only reason we require 2 implementations = for IDR is for the fragile BGP environment and that operators request it = due to the global consequences. Network Management of these early yang = models have a much more restricted case. May I ask you to point to where I have said anything about two deployed = implementations? Ignas > Sue Hares > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ignas Bagdonas > Sent: Wednesday, April 4, 2018 10:31 AM > To: Susan Hares; 'The IESG' > Cc: i2rs@ietf.org; = draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; = i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ignas Bagdonas' Discuss on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = COMMENT) > > Hi Sue, > > > On 03/04/2018 14:59, Susan Hares wrote: >> Ignas: >> >> Yan will answer for the authors but I would like to share some = information related to the I2RS working group reviews. In your = response, please specify why each question is a "DISCUSS" quality = question rather than a "Comment" question. The authors and I (as the = shepherd) will work to resolve both DISCUSS and comment issues. >> >> Let me review only 5 of your many points because they are pointing in = a direction which is different from earlier QA reviews of this document = (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 timeframe. >> 1st - Why TE topology model is not sufficient for modelling the = representation of DC fabric? Why is DC fabric network topology special = compared to any generic fabric based topology? > Why DISCUSS? DC fabric is a type of network topology, yes, it has some = specifics, but nothing radically different than any purpose built = network topology. Developing a separate model for a specific use case at = the same time when there is generic and extensible TE model is = questionable. > >> This document was reviewed by authors with the TE topology models to = make sure there was no conflict or duplication. >> >> Your question implies that only one yang model is appropriate for = each type of fabric. > That is exactly opposite. What is special about DC fabric that it has = to have a separate model? What is special about fabric type of topology = that it has to have a separate model? Why is TE model not suitable? > >> This theory of one yang mode per fabric does not apply to = dynamic (ephemeral) datastore versus configuration datastore models. It = is also not true of all models even within the configuration datastore. >> Since there is a yang catalog and selection of yang models is = specific to a implemented, there has been no early winnowing of the yang = models per type. If you are insisting on this theory of "one yang = model" per fabric type, please provide an RFC reference so that I can = help review this DISCUSS criteria with the authors. >> >> This yang model has been implemented by 1 vendor, and there was = interest by other vendors. A deployment target has been identified for = this model, and feedback is expected from the users. > Excellent. Please get feedback from user community - even if it is not = yet implemented and operations groups will not be able to provide = feedback, architecture and engineering groups look into upcoming things = and will have what to say. > > Speaking of implementations, the ODL faas project (from where the = majority of this model seems to be coming from) deals with an instance = of overlay that is subsequently treated as an underlay, and that is = different that the underlay on top of which that instance is being run. > If the model focus is on the "fabric as a service" type of topologies = then it explicitly needs to state that, and then justify why physical = node properties exist together with logical instance properties in that = case. > > >> If you are asking this model to cover three-four layer datacenters, = this approach is opposite some of the initial feedback to the group to = keep the initial model - that is to keep it simple and restricted to 2 = layers in order to test the concepts. If you are asking to provide text = (in introduction or appendix) that indicates the initial focus, this can = be added. > The document as it is written now tries to cover every possible = fabric. > If the scope is intended to be narrower - it needs to be stated. > Starting from bounded scope is certainly a right thing to do but that = is not how the document reads now. > > >> 2nd - Multiple layers and multiple roles. > Why DISCUSS? Two stage fabrics and fabrics with a perfectly clean node > role separation do indeed exist, but that is not necessary a common > deployment model. The document assumes that those are the only = possible > options. > >> The authors provide slides in several meetings I2RS meeting = repository regarding this point. >> The initial feedback suggested reducing the "why" text within the = draft. Again, the initial feedback was to reduce the initial model's = text to 2 layers and simple "whys". See proceedings from IETF 95 = forward on I2RS on fabric data model for discussions. > Would users of this model also be required to lookup proceedings of = past > IETF meetings in order to understand whether it may fit their use = cases? > > >> 3rd - The authors will comment on the port restrictions. Early = feedback during the I2RS meetings from vendors may have taken the = authors down this path. In my review, I expect major issues in this = area - but I will let the authors comment. > Why DISCUSS? The way how the model specifies port speeds is = conflicting > with common deployment practices. > >> 4 - policy is simple. >> >> Again, the initial feedback was to keep initial policies simple and = gain feedback from the deployments. > Why DISCUSS? What kind of policy is being discussed here? The = assumption > of one single universal policy fitting all deployments and use cases > contradicts to operational reality. > > "Policy is simple" does not clarify what kind of policy it is. > >> 5 - You indicate that the document requires a "major" rewrite = clarifying the logic. > Why DISCUSS? Model tries to prescribe a way how all DC networks should > be built. It intermixes concepts of underlay and overlay. There are > nodes in the model with unclear purpose and no documented details on > what and how they are doing. > >> Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested = taking out the lengthy descriptions regarding logic and history. If we = are switching the rules for the YANG models, would you please update the = requirements for the YANG models so that shepherds, rtg-dir, ops-dir, = and yang-doctors can have rules for review clearly spelled out. > YANG models, and any other deliverables of the IETF, are targetted to > the users of those deliverables and not necessary to the IETF itself. > The situation with YANG models is that the main consumer of IETF YANG > model for a noticeable period was IETF itself - it was required to > build the sufficient coverage of models for them to be practically > useful. We as an industry start to see more practical use of YANG > modules, and so far the main obstacle for YANG acceptance is the > difficulty in trying to use it. It is incorrect to assume that outside > of the IETF WGs that deal with developing the models there is enough = of > understanding of the reasoning behind modelling decisions made. It is > incorrect to assume that potential users of such models would try to > lookup proceedings of past IETF meeting trying to get answers - they > will chose other manageability technologies instead. YANG models need = to > be self-contained from the practical usability perspective - the = models > themselves should contain enough and meaningful descriptions of the > nodes that it would not raise questions for users trying to deploy = those > models. Descriptions equivalent to those found in command line > interfaces - if YANG is expected to become a new command line = interface, > it should be no worse than the command line interface. The reasoning > behind modelling decisions made also need to be documented - at least > for allowing model users to see whether the model is suitable for > deployment in the particular environment. As YANG is maturing and > starting to be deployed, naturally the focus of reviews will change to > reflect what is required for successful deployment of the technology. > >> Summary on Shepherd's comment: >> >> The authors will respond to others specifics, but in order to guide = these diligent authors - I need to know what rules you are setting for = the 2018 IESG approval of YANG models. If you are placing a DISCUSS on = a YANG model based on a set criteria, the criteria needs to be published = on a web page or in an RFC. If I've missed this criteria that the OPS = Area has specified, > RFC6087 and draft-ietf-netmod-rfc6087bis. > > There are two parts that are important for reviews - the model itself, > and how the model applies to the managed entities. And there is = nothing > new in the review criteria. The former is rather not that complex, and > typically can be done within IETF itself. The latter is more complex = and > generally would require feedback from the target users of the model. > There is a balance between a model being too generic to be practically > usable and model being too prescriptive to be practically usable. If = the > model puts requirements and restrictions on the managed entities in a > way that requires to build those managed entities in a specific way, > predefined by the model authors, the value of such model is > questionable. Speaking specifically about DC fabric model, it puts > network design prescriptions that are significantly misaligned with = how > fabric based networks have been and are built. Yes, it is possible to > find environments where the model would apply directly and with no > impact, but one would need to look for such deployments quite hard, = and > with a high probability that would be proof of concept or technology > demonstration type of environments. > > IETF is good at developing technology components and fragments, IETF > typically is not good at dealing with network design and how those > fragments need to be bound together - that is the reality, and that is > not necessarily wrong. IETF should be focusing on what it can do best = - > the fragments, and align with users of the fragments on how to improve > the fragments but not try to direct how users should be building their > networks. It is important for the reputation of IETF as a credible SDO = - > if IETF manageability mechanisms propose and enforce not necessarily > right - or just plain broken - network designs, that is a reputation > problem. This document tends to be proposed standard, and that sets a > strong message. > > Ignas > > >> Thank you for your review, >> Susan Hares >> >> -----Original Message----- >> From: Ignas Bagdonas [mailto:ibagdona@gmail.com] >> Sent: Tuesday, April 3, 2018 7:40 AM >> To: The IESG >> Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan = Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >> Subject: Ignas Bagdonas' Discuss on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = COMMENT) >> >> Ignas Bagdonas has entered the following ballot position for >> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-t= opology/ >> >> >> >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >> >> I have concerns about the practical usability of this proposed model = as it is specified now. >> >> The intended decoupling of fabric implementation properties (what is = termed as "underlay network infrastructure" in the document) and its = topology seems to be contradicting to general operational practices of = fabric based networks. It is generally true for the context of the = overlay but that is not what the document seems to be focusing on. = Fabric defines and implements the underlay, not the other way around. >> >> The document does not contain a sufficient description of the logic = of the model itself, the reasons for choices made for representation of = types and attributes, and at the same time descriptions in modules are = single lines that do not add clarification beyond being copies of leaf = names. Either there needs to be a section that describes the logic of = the model and how it relates to other models, also including examples, = or module description fields need to have enough content to be able to = have equivalent understanding of model intent and operation. Both are = strongly encouraged, as descriptions have value of itself for being a = reference for use, and model description is needed for understanding how = this particular model fits into the larger hierarchy. Network management = does not end at the boundary of the single domain-specific model, it is = important to build it into a whole system. >> >> Why TE topology model is not sufficient for modelling the = representation of DC fabric? Why is DC fabric network topology special = compared to any generic fabric based topology? >> >> How this model could be used for representing more than two stage = fabrics that are in wide deployment? >> >> Limiting port bandwidth to a fixed rate is too restrictive. The model = as specified already does not cover a set of port speeds that are in = deployment. >> >> How would a device that has more than a single role in the fabric be = represented? >> >> Service capabilities as they are described belong to the overlay = context while they are called device capabilities. Are those the only = possible service capabilities? What is the effect of configuring those = capabilities? >> >> What is compose-fabric RPC? The document does not define any RPCs. >> >> What is policy driven traffic behavior? Is there the only one policy = that fits all possible deployment scenarios? >> >> Looking at the history of the document from the individual submission = time and the comments received, it seems that the point fixes to the = text went in to cover the specific comments but not to address the = broader scope of comments. >> The document would definitely benefit from a major rewrite clarifying = the logic behind the decisions made, aligning more with the operational = practice of fabric based network design and deployment, and bringing the = content in YANG modules to be self-describing. >> >> >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >> >> Fabric and POD are not equivalent terms. >> >> I2RS use case requirements document has expired 11 months ago. Use = cases documents are good for tracking the work progress of specification = documents, it is questionable whether standalone use cases documents = provide value beyond historic record. Is the reference to I2RS use cases = document really needed? >> >> What is atomic network? >> >> VLAN is not a fabric building technology as such, while Ethernet is. >> >> What is the need for VNI capacity leaves? What is their effect if = configured? >> >> The document intermixes ietf-fabric-* and ietf-dc-fabric-* = namespaces. >> >> Serial port-type is present while Infiniband is not - Infiniband = based fabrics are widely deployed. What is the extensibility mechanism = for adding in new port types? >> >> Is there any deployment experience with this model? The ODL faas = project hasn't got much activity over last two years. Are you aware of = any other implementations or deployments? >> >> >> > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Apr 4 18:16:27 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1823412420B; Wed, 4 Apr 2018 18:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 wYfHO5eTHCYu; Wed, 4 Apr 2018 18:16:07 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 023A51201F2; Wed, 4 Apr 2018 18:16:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Sarah Banks'" , Cc: , , References: <152287502690.23944.16141591280916420608@ietfa.amsl.com> In-Reply-To: <152287502690.23944.16141591280916420608@ietfa.amsl.com> Date: Wed, 4 Apr 2018 21:15:29 -0400 Message-ID: <033b01d3cc7b$96874ed0$c395ec70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJoKiiQR17GSgwApxdxISTJ1TSQsKLIZuSg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Opsdir early review of draft-ietf-i2rs-rib-data-model-10 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 01:16:09 -0000 Sarah: Thank you for your comments. These are helpful. As a Shepherd, I'll help the authors address your comments in the latest revision. On #1) The nexthop chains are described in detail in draft-ietf-i2rs-rib-info-model in section 7.2.5. Would reference in the appropriate place provide the necessary detail or would you like additional comments added? On #2) Thank you for mentioning this point. I will work with the authors to reduce the Nits. On #3) Thank you for mentioning this point. The longer list of authors was vetted with the AD due to the combination of multiple drafts into 1. Since we cleared this with the AD early in the process, it seems unreasonable to change it at this point. Susan Hares -----Original Message----- From: Sarah Banks [mailto:sbanks@encrypted.net] Sent: Wednesday, April 4, 2018 4:50 PM To: ops-dir@ietf.org Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model.all@ietf.org; ietf@ietf.org Subject: Opsdir early review of draft-ietf-i2rs-rib-data-model-10 Reviewer: Sarah Banks Review result: Has Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Upon review, I think the document is in decent shape, but needs work in the WG first. There are 3 things I'd like to point out: 1. There are areas in the document where we assume the reader knows , but the document text could be helped if the authors were more concise in their wording. For example: "At the same time, nexthop chains can be used to specify multiple headers over a packet, before that particular packet is forwarded. Not every network device will be able to support all kinds of nexthop chains along with the arbitrary number of headers which are chained together." I would think that while this might often be true, it doesn't have to always be true, and depending on how wide the domain is, it might not be true. I realize this isn't written with normative language, and it's a minor point, but it lacks precision. 2. Nits has issues. Yup, a lot of authors think we'll just toss it in the queue and let the RFC Editors fix this, but I think it's our job to be sending clean docs into the queue. We pay for the RFC Editors service, why have them spending time on things we have a tool that allows the authors to do this for themselves? Fix your nits. :) 3. The document violates the number of named authors at the top - another expense of RFC Editors time and effort I don't think we should be doing. I'd prefer to see the authors/WG/WG Chairs address these items before they go into the queue. Thanks Sarah From nobody Wed Apr 4 18:31:06 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE65F126B72; Wed, 4 Apr 2018 18:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 6q7W5-pG-jH1; Wed, 4 Apr 2018 18:30:57 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 8DF451201F2; Wed, 4 Apr 2018 18:30:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: =?utf-8?Q?'Mirja_K=C3=BChlewind'?= , "'The IESG'" Cc: , , References: <152286547363.24015.12929083031389820321.idtracker@ietfa.amsl.com> In-Reply-To: <152286547363.24015.12929083031389820321.idtracker@ietfa.amsl.com> Date: Wed, 4 Apr 2018 21:30:47 -0400 Message-ID: <033d01d3cc7d$ba0822b0$2e186810$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ0c+aZVspcYX6U9Mau4TNY9imv0KKwE4Ug Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-i2rs-rib-data-model-10=3A_=28with_COMMENT=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 01:30:59 -0000 Mirja and Alissa: I will work with the authors addressing this in the next revision.=20 Cheerily, Susan Hares -----Original Message----- From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net]=20 Sent: Wednesday, April 4, 2018 2:11 PM To: The IESG Cc: draft-ietf-i2rs-rib-data-model@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-rib-data-model-10: (with COMMENT) Mirja K=C3=BChlewind has entered the following ballot position for draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alissa's comments on use of normative language. From nobody Wed Apr 4 18:32:43 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86C11252BA; Wed, 4 Apr 2018 18:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 7CXq_xqkr6Tb; Wed, 4 Apr 2018 18:32:35 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 14A201201F2; Wed, 4 Apr 2018 18:32:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: =?utf-8?Q?'Mirja_K=C3=BChlewind'?= , "'The IESG'" Cc: , , References: <152286477322.23998.1237380071004726529.idtracker@ietfa.amsl.com> In-Reply-To: <152286477322.23998.1237380071004726529.idtracker@ietfa.amsl.com> Date: Wed, 4 Apr 2018 21:32:27 -0400 Message-ID: <033f01d3cc7d$f55a9910$e00fcb30$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLZSUXV19tY4zlCqpAQFJ+yoJ8+pKHmaTJw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-i2rs-yang-dc-fabric-network-topology-08=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 01:32:37 -0000 Mirja: Thank you for mentioning the boilerplate. I'll work with the authors to = address in this in the next revision.=20 Cheerily, Susan Hares -----Original Message----- From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net]=20 Sent: Wednesday, April 4, 2018 2:00 PM To: The IESG Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan = Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT) Mirja K=C3=BChlewind has entered the following ballot position for draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-t= opology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please use RFC 8174 boilerplate! From nobody Wed Apr 4 18:37:29 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB701201F2; Wed, 4 Apr 2018 18:37:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-i2rs-rib-info-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152289224356.25972.5946145598014687422.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2018 18:37:23 -0700 Archived-At: Subject: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 01:37:24 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Warren's question (and, IIRC, asked a similar one about the associated data-model document). Just one other minor question: in Section 4 Route programming in the RIB MUST result in a return code that contains the following attributes: o Installed - Yes/No (Indicates whether the route got installed in the FIB) o Active - Yes/No (Indicates whether a route is fully resolved and is a candidate for selection) o Reason - e.g., Not authorized Is the Reason only relevant when one of the other two is "No"? From nobody Wed Apr 4 18:43:16 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BF8124235; Wed, 4 Apr 2018 18:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 nNiivzXvWNXp; Wed, 4 Apr 2018 18:43:14 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 7A5D51201F2; Wed, 4 Apr 2018 18:43:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Benjamin Kaduk'" , "'The IESG'" Cc: , , References: <152289224356.25972.5946145598014687422.idtracker@ietfa.amsl.com> In-Reply-To: <152289224356.25972.5946145598014687422.idtracker@ietfa.amsl.com> Date: Wed, 4 Apr 2018 21:43:07 -0400 Message-ID: <034101d3cc7f$72e1cd30$58a56790$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM8qJ9Kz8N5WEWm3I2uC23bntTqtKEfrOPg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 01:43:15 -0000 Benjamin:=20 Thank you for your comments. The authors work will to clarify this = portion.=20 As I recall (and my memory may be spotty), the reason was available for = both "yes" and "no" in case "yes" it is active, and "no" it is not = installed (example - 20 ECMP routes and only 10 get installed). Nitin = may have more details on this RFC.=20 Cheerily, Susan Hares -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@mit.edu]=20 Sent: Wednesday, April 4, 2018 9:37 PM To: The IESG Cc: draft-ietf-i2rs-rib-info-model@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Benjamin Kaduk's No Objection on = draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Warren's question (and, IIRC, asked a similar one about the = associated data-model document). Just one other minor question: in Section 4 Route programming in the RIB MUST result in a return code that contains the following attributes: o Installed - Yes/No (Indicates whether the route got installed in the FIB) o Active - Yes/No (Indicates whether a route is fully resolved and is a candidate for selection) o Reason - e.g., Not authorized Is the Reason only relevant when one of the other two is "No"? From nobody Wed Apr 4 21:39:29 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7ED6126C89; Wed, 4 Apr 2018 21:39:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-i2rs-rib-data-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152290316167.25799.2600141637113757077.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2018 21:39:21 -0700 Archived-At: Subject: [i2rs] Adam Roach's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 04:39:22 -0000 Adam Roach has entered the following ballot position for draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is similar enough to Suresh's DISCUSS that I don't see the point in making it a DISCUSS also (which it would be otherwise). I'll let him make sure field size issues are taken care of. > case mac-route { > description > "MAC route case."; > leaf mac-address { > type uint32 ; > mandatory true; > description > "The MAC address used for matching."; > } > } The intention here is to use IEEE EUI-48 and/or EUI-64 identifiers here, right? These don't fit into a uint32. This problem arises elsewhere in the module; e.g.: > leaf ieee-mac-address { > type uint32; > mandatory true; > description > "The nexthop points to an interface with > a specific mac-address."; > } =========================================================================== §2.6: > Nexthops can be fully resolved or an unresolved. Nit: remove "an" --------------------------------------------------------------------------- §3: > import ietf-interfaces { > prefix if; > reference "RFC 7223"; > } > > import ietf-yang-types { > prefix yang; > reference "RFC 6991"; > } The indenting of the "reference" fields seems odd. > identity ipv6-decapsulation { > base "tunnel-decapsulation-action"; > description > "IPv4 tunnel decapsulation."; > } The description here appears to be incorrect (should say "IPv6") > identity decrease-and-copy-to-next { > base "ttl-action"; > description > "Decrease TTL by one and copy the TTL > to the next header.For example: when > MPLS label swapping, decrease the TTL > of the inner label and copy it to the > outer label."; > } Nit: insert a space before "For". > identity resolved { > base "nexthop-state"; > description > "Reolved nexthop state."; > } Nit: "Resolved" rather than "Reolved." > typedef nexthop-lb-weight-definition { > type uint8 { > range "1..99"; > } > description > "Nexthop-lb-weight is used for load-balancing. > Each list member MUST be assigned a weight > between 1 and 99. The weight determines the > proportion of traffic to be sent over a nexthop > used for forwarding as a ratio of the weight of > this nexthop divided by the weights of all the > nexthops of this route that are used for forwarding. > To perform equal load-balancing, one MAY specify > a weight of 0 for all the member nexthops. The > value 0 is reserved for equal load-balancing > and if applied, MUST be applied to all member nexthops."; > } To match the text (which allows 0 as a special case), the range needs to be updated to be "0..99" rather than "1..99" > leaf hop-limit { > type uint8; > description > "The hop limit the header."; > } Nit: "The hop limit of the header." > choice nvgre-type { > description > "NvGRE can use eigher IPv4 > or IPv6 header for encapsulation."; Nit: "either" > leaf flow-id { > type uint16; > description > "The flow identifier of the NvGRE header."; > } Why is this a uint16 rather than a uint8? From nobody Wed Apr 4 22:08:19 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F864126C26; Wed, 4 Apr 2018 22:08:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-i2rs-rib-info-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152290489812.25948.2495908999143424774.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2018 22:08:18 -0700 Archived-At: Subject: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 05:08:18 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 2.3. Regarding the OSPF route for 2001:DB8::1/32 Did you mean 2001:DB8::1/128 for the host route? If not, this example is wrong since 2001:DB8::1/32 expands to 2001:DB8:0000:0000:0000:0000:0000:1/32 -> 2001:DB8::/32 as the route * Figure 4. Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into nexthop processing just like the derived nexthops do? * Section 6 I would have expected the match type to have some indication about whether it requires an exact match or LPM (e.g. A MAC route uses an exact match but an IPv6 route uses LPM). Has the WG discussed this? From nobody Thu Apr 5 04:14:23 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 019CA12D7ED; Thu, 5 Apr 2018 04:14:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ignas Bagdonas To: "The IESG" Cc: draft-ietf-i2rs-rib-data-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152292686099.25960.16142711099135250050.idtracker@ietfa.amsl.com> Date: Thu, 05 Apr 2018 04:14:20 -0700 Archived-At: Subject: [i2rs] Ignas Bagdonas' No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 11:14:21 -0000 Ignas Bagdonas has entered the following ballot position for draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I2RS use cases document seems to be abandoned, and generally use case documents best fit the purpose of tracking the work on specification documents. Is the reference really needed? Please address RTG-DIR comments on RIB/Rib/rib consistency, encap/encapsulation, decap/decapsulation consisteny. s/nexthop-replicates/nexthop-replicate, or change the description of base nexthop. s/blow/below s/VxLAN/VXLAN throughout the document. nexthop-lb-weight-definition: divided by the sum of weights. Or, to simplify the text, representing a proportion. Value of 0 is not in the range. From nobody Thu Apr 5 05:01:19 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC28B12D881; Thu, 5 Apr 2018 05:01:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ignas Bagdonas To: "The IESG" Cc: draft-ietf-i2rs-rib-info-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152292967776.25948.4861433804412654905.idtracker@ietfa.amsl.com> Date: Thu, 05 Apr 2018 05:01:17 -0700 Archived-At: Subject: [i2rs] Ignas Bagdonas' No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 12:01:18 -0000 Ignas Bagdonas has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few nits: Terminology: rib family vs address family. Address family term is more widely used in the industry. VPLS is a subset of L2VPN. ROUTER_ID usage is orthogonal to router virtualization. MUST restriction for the domain is factually incorrect - it is typically per source protocol, not per domain. From nobody Thu Apr 5 05:39:11 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E36A1273B1; Thu, 5 Apr 2018 05:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 k9E5L8uV-Qi4; Thu, 5 Apr 2018 05:39:08 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 1389E127201; Thu, 5 Apr 2018 05:39:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Ignas Bagdonas'" , "'The IESG'" Cc: , , References: <152292967776.25948.4861433804412654905.idtracker@ietfa.amsl.com> In-Reply-To: <152292967776.25948.4861433804412654905.idtracker@ietfa.amsl.com> Date: Thu, 5 Apr 2018 08:39:05 -0400 Message-ID: <03e101d3ccdb$1607a420$4216ec60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE0W70npgFU8mDNDZztarh3e5wFCaUw/nYg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 12:39:10 -0000 Ignas: Thank you for your comments. I will check that these are addressed in = the next version.=20 Cheerily, Susan Hares -----Original Message----- From: Ignas Bagdonas [mailto:ibagdona@gmail.com]=20 Sent: Thursday, April 5, 2018 8:01 AM To: The IESG Cc: draft-ietf-i2rs-rib-info-model@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Ignas Bagdonas' No Objection on = draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Ignas Bagdonas has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few nits: Terminology: rib family vs address family. Address family term is more = widely used in the industry. VPLS is a subset of L2VPN. ROUTER_ID usage is orthogonal to router virtualization. MUST restriction = for the domain is factually incorrect - it is typically per source = protocol, not per domain. From nobody Thu Apr 5 05:42:56 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7FC1273B1; Thu, 5 Apr 2018 05:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 la8NY2hL-Y0t; Thu, 5 Apr 2018 05:42:47 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 44332127201; Thu, 5 Apr 2018 05:42:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Suresh Krishnan'" , "'The IESG'" Cc: , , References: <152290489812.25948.2495908999143424774.idtracker@ietfa.amsl.com> In-Reply-To: <152290489812.25948.2495908999143424774.idtracker@ietfa.amsl.com> Date: Thu, 5 Apr 2018 08:42:42 -0400 Message-ID: <03e301d3ccdb$9788b7a0$c69a26e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGzXOuogYIVg/6+qC65IQQLrrWnfqQy/NVg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 12:42:49 -0000 Suresh:=20 On WG discussions,=20 LPM =3D Longest prefix match? If so, LPM was discussed.=20 I will follow-up with the authors on resolving this in section 6. = Thanks for catching this error.=20 Cheerily, Sue=20 -----Original Message----- From: Suresh Krishnan [mailto:suresh@kaloom.com]=20 Sent: Thursday, April 5, 2018 1:08 AM To: The IESG Cc: draft-ietf-i2rs-rib-info-model@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Suresh Krishnan's No Objection on = draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 2.3. Regarding the OSPF route for 2001:DB8::1/32 Did you mean 2001:DB8::1/128 for the host route? If not, this example is = wrong since 2001:DB8::1/32 expands to = 2001:DB8:0000:0000:0000:0000:0000:1/32 -> 2001:DB8::/32 as the route * Figure 4. Shouldn't the tunnel-encap and tunnel-decap also loop the packet back = into nexthop processing just like the derived nexthops do? * Section 6 I would have expected the match type to have some indication about = whether it requires an exact match or LPM (e.g. A MAC route uses an = exact match but an IPv6 route uses LPM). Has the WG discussed this? From nobody Thu Apr 5 06:29:33 2018 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7939A12D882; Thu, 5 Apr 2018 06:29:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-i2rs-rib-info-model@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org, peter@akayla.com X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152293497148.25908.12827399942547777265.idtracker@ietfa.amsl.com> Date: Thu, 05 Apr 2018 06:29:31 -0700 Archived-At: Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 13:29:31 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't see any response in email to the Gen-ART review, although some of the changes he proposed seemed to have been taken on board in the -15 version. These comments of his do not seem to have been addressed, however: Sec. 2.2, 1st paragraph after bullet list, last sentence: Routing instances are identified by ROUTER_IDs anyhow, so this sentence seems superfluous. Perhaps you are trying to get across the point that the ROUTER_ID (which is definitely present for the router) is not *used* by this routing instance. I think there's a discussion missing that may or may not be within scope of this document. RIBs appear to be typically divided according to the protocol for which they are providing routing (IPv4, MPLS, etc.) Section 7.1 discusses routing preferences, with an example of OSPF route and a route from some other protocol. When the OSPF route is withdrawn, the other route is installed in the FIB. What's not clear is what makes the decision to do this and cause a specific RIB to push its route into the FIB. Is that the routing instance or the RIB manager? A routing instance is described as a set of interfaces, RIBs, and routing parameters. It's description does not make it clear that it arbitrates among the RIBs or the routing protocols which are using the northbound interface to talk to the RIB manager. Figure 1 makes it seem like there is a RIB manger per RIB, in which case how can the RIB manager make decisions between multiple RIBs? Sec. 5: there are unstated assumptions about needing a subscription mechanism for subscribing to notifications, particularly notifications from RIBs that were not created by the entity. (This goes back to the concept on the previous page that entities may possibly read to or write from RIBs they did not create.) The discussion of notifications could use some fleshing out here. From nobody Thu Apr 5 06:30:58 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E7012D885; Thu, 5 Apr 2018 06:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=R+y4RXYi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XkhS2J44 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 sMw-6IDFIMi6; Thu, 5 Apr 2018 06:30:53 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC4C12D882; Thu, 5 Apr 2018 06:30:49 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 38D54210C9; Thu, 5 Apr 2018 09:30:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 05 Apr 2018 09:30:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=xBkl2SrK4eLgVEFPJ68o5ur6Cpst5 kSxslICVkDXRiA=; b=R+y4RXYivV/L+8mHLcZ8kEbvyib1oqb30ZPiK+hmB93Wf YcU37HwP9Up/ydlCga7ShEO3dMadLGlBFUAONMkHIZQcHOY3TrlxhZZrO8KuN37O M3t3YYtCVAji3eXwMYQazvMZ+UtJBs9zEvFxNB27FV1F4QevU+hNP51wSidP8rDO depRmI6OWhb1bkbXfOc2ogezKAUa0OYMv7Yfx8O+Ei1AkcIi2pIdEmx7Ca5iS+qA W6GJWy/Nv+gvJwtwNnbWJ+D14LsfgH/5CMfs6ppdz1r0fjNdteu40/tDVzS6Wab+ PIGWkVfU8UyEfbR+YpDrU5VsUBgLe6ngHJW0DHOIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=xBkl2S rK4eLgVEFPJ68o5ur6Cpst5kSxslICVkDXRiA=; b=XkhS2J44i86ZCmDQu054gp mjTNGiBjCTaYPjfoZ6zBX2/SbVFlLeVVjHEF6ksUl4EJLXA+ggAiNvPeOAnfv6JD NXDsrwum7SuoHNG0RSLdgdtdrglvVmrna/NwaNIPRH/lUK9D8+m9c/exXBhiFHKE RwhjTbC2fIqPQRc8sQg+WH2i8PczJHU0PQWO9KyhrwsDN8MjtzYyyPcypDC0Du6C THyKSnpW1+nwlaMTnsAiV7yT3M8rVAr+CG6WBfkHUNImk3zqQ/A549vybhftnomS 2TGNXzgvvN0rJczTwjOQ7c74RXQK7FCutpM2JStH2nx4sqTvL54HG30PkjcMf6zQ == X-ME-Sender: Received: from rtp-alcoop-nitro3.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id B3CA0102CB; Thu, 5 Apr 2018 09:30:48 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <151943613720.13683.15859889318714950058@ietfa.amsl.com> Date: Thu, 5 Apr 2018 09:30:48 -0400 Cc: IETF Gen-ART , i2rs@ietf.org, draft-ietf-i2rs-rib-info-model.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <25FDF4BD-F8E5-431C-80D0-CEB147B443C5@cooperw.in> References: <151943613720.13683.15859889318714950058@ietfa.amsl.com> To: Peter Yee X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [i2rs] [Gen-art] Genart last call review of draft-ietf-i2rs-rib-info-model-14 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 13:30:56 -0000 Peter, thanks for your review. Authors, thanks for addressing some of = Peter=E2=80=99s comments. I tried to pick out those of his comments that = remain unaddressed and put them in my No Objection ballot. Alissa > On Feb 23, 2018, at 8:35 PM, Peter Yee wrote: >=20 > Reviewer: Peter Yee > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-i2rs-rib-info-model-14 > Reviewer: Peter Yee > Review Date: 2018-02-22 > IETF LC End Date: 2018-02-23 > IESG Telechat date: 2018-03-08 >=20 > Summary: This Informational draft specifies an information model for = routing > information bases, providing modeling of the internal information of a = router > or similar network device. The draft is mostly ready, but has some = issues that > should be considered. [Ready with issues] >=20 > Major issues: None >=20 > Minor issues: >=20 > Page 4, 3rd full paragraph, 1st sentence: the draft introduces the = concept of > "RIB clients" in Figure 1, notes that they are generally routing = protocols, and > then never uses the term again. All other references to the what must = be the > users of the northbound interface are then called "external entities" = for the > most part. This is confusing because the term "external entity" is = not defined > nor fully equated with "RIB client". The term also seems to indicate = that the > "external entity" is not necessarily running on the network device. = While that > might be one way of looking at the feeding of data into the RIB via = NETCONF or > RESTCONF, that doesn't seem to be the case for a routing protocol. A = fuller > explanation of the users of the northbound interface and a revision to = Figure 1 > might help clarify this situation. >=20 > Page 7, 1st paragraph after bullet list, last sentence: Routing = instances are > identified by ROUTER_IDs anyhow, so this sentence seems superfluous. = Perhaps > you are trying to get across the point that the ROUTER_ID (which is = definitely > present for the router) is not *used* by this routing instance. >=20 > The term "ethernet" is used in several places in the document. Except = in the > grammar of section 6, change these to the capitalized "Ethernet". = This brings > up a larger point, however. Not all IEEE MAC addresses are associated = with > Ethernet interfaces and I believe this document is expected to be = applicable to > other IEEE 802 MACs such as IEEE 802.11 (WLAN) and IEEE 802.15 (WPAN). = IEEE > 802.15 has long and short forms of MAC addresses, so you may want to = give some > additional thought to what you want to say with this term and pick = something > more appropriate. >=20 > I think there's a discussion missing that may or may not be within = scope of > this document. RIBs appear to be typically divided according to the = protocol > for which they are providing routing (IPv4, MPLS, etc.) Section 7.1 = discusses > routing preferences, with an example of OSPF route and a route from = some other > protocol. When the OSPF route is withdrawn, the other route is = installed in > the FIB. What's not clear is what makes the decision to do this and = cause a > specific RIB to push its route into the FIB. Is that the routing = instance or > the RIB manager? A routing instance is described as a set of = interfaces, RIBs, > and routing parameters. It's description does not make it clear that = it > arbitrates among the RIBs or the routing protocols which are using the > northbound interface to talk to the RIB manager. Figure 1 makes it = seem like > there is a RIB manger per RIB, in which case how can the RIB manager = make > decisions between multiple RIBs? >=20 > Page 14, Section 3, 2nd paragraph, 2nd sentence: a "connection" is = mentioned > here. This document purports to deal with an API (and one that would = mostly be > used by local routing protocols if the figures are to be believed) and = hasn't > otherwise made any mention of a connection, let alone what constitutes = a > connection and defines its lifetime. More discussion is needed of = this concept > instead of just (possibly) resting the whole thing on brief mentions = of NETCONF > and RESTCONF (which aren't even brought into the picture until the = Security > Considerations section later on in the document). >=20 > Page 15, 1st partial paragraph: there are unstated assumptions about = needing a > subscription mechanism for subscribing to notifications, particularly > notifications from RIBs that were not created by the entity. (This = goes back > to the concept on the previous page that entities may possibly read to = or write > from RIBs they did not create.) The discussion of notifications could = use some > fleshing out here. >=20 > Nits/editorial comments: >=20 > General: >=20 > Append a comma after "i.e." and "e.g." Make all uses of "e.g." lower = case.=20 > Some uses of "e.g." have double spaces after them and those double = spaces > should be replaced with single spaces. >=20 > Change "use-cases" to "use cases" throughout the document. Or use the = other > way around. Just be consistent in the usage. Non-hyphenate usage = appears to > be preferred. >=20 > Insert a blank line before and after bullet lists for readability. = Consider > adding a blank line between entries to aid readability as well. >=20 > Specific: >=20 > Page 1, Abstract, 2nd sentence: delete the semicolon. >=20 > Page 1, Abstract, 4th sentence: replace the space between "higher" and = "level" > with a hyphen. >=20 > Page 3, Section 1, 2nd sentence: change "config" to "configuration = information" > (or something similar). >=20 > Page 3, Section 1, 3rd sentence: change "north-bound" to "northbound". = Append > a comma after each of "clients", "i.e.", and "protocols". >=20 > Page 3, Figure 1 caption: append a comma after "clients". >=20 > Page 4, 1st partial paragraph, 1st complete sentence: change "which" = to "that". > Append a comma after "policies". >=20 > Page 4, 1st partial paragraph, 4th complete sentence: replace the = space between > "publicly" and "documented" with a hyphen and then append a comma = after > "publicly-documented". >=20 > Page 4, 2nd full paragraph, 1st sentence: I'm not sure what "show = output screen > scraping" is. I'm familiar with screen scraping, but could not find a = good > source for your term. Perhaps you could explain or modify it? >=20 > Page 5, Section 1.1: you may wish to reference RFC 8174, which updates = RFC 2119 > and makes it applicable across more than Standards Track documents. >=20 > Page 5, Section 2, 4th sentence: delete the comma after "single". >=20 > Page 5, Section 2, 5th sentence: make "Section" lower case. >=20 > Page 5, Section 2, 6th sentence: change the space between "high" and = "level" to > a hyphen. >=20 > Page 5, Figure 2: remove the space between "routing-instance" and = "(s)". >=20 > Page 5, Section 2.1, 3rd sentence: change "intance" to "instance". = Also fix > the sentence or Figure 2: the sentence says 1 or more RIBs, the = diagram shows 0 > or more. I'm not sure how a zero RIB routing instance is useful, but = make the > two ranges consistent. >=20 > Page 6, 1st paragraph, 1st sentence: delete this sentence as it is = redundant > with information given in the previous paragraph on Page 5. >=20 > Page 6, 2nd paragraph, 1st sentence: Change "a" to "an" before > "ENABLE_IP_RPF_CHECK". Capitalize each word in "Reverse path = forwarding". >=20 > Page 6, 2nd paragraph, 2nd sentence: delete "Reverse path forwarding", = insert > the word "The" at the beginning of the sentence and remove the = parentheses > around "RPF". >=20 > Page 6, 2nd paragraph, 3rd and 4th sentences: change "rpf" to "RPF". >=20 > Page 6, Section 2.2, 1st paragraph, 3rd sentence: delete both = semicolons. >=20 > Page 6, "interface-list" bullet item, 3rd sentence: I think it reads = better > with "in" inserted before "on". >=20 > Page 7, "ROUTER_ID" bullet item: change "router-id" to "ROUTER_ID". = Or if you > want a descriptive term, change it to "router identification". >=20 > Page 8, MPLS bullet item: "change "a" to "an". >=20 > Page 8, paragraph after "route-vendor-attributes" bullet item, 1st = sentence: > change "Nexthop" to "nexthop". >=20 > Page 9, 1st partial paragraph, 4th full sentence: change "a" to "an" = before > "MPLS". >=20 > Page 9, 1st partial paragraph, 7th full sentence: append a comma after > "Conversely". Insert "the" before "case". >=20 > Page 10, 1st paragraph, 1st sentence: put a comma after "extensible". >=20 > Page 10, 1st paragraph, 5th sentence: change "it's" to "its". >=20 > Page 11, "EGRESS_INTERFACE" sub-bullet item: append a comma after = "logical". >=20 > Page 11, "EGRESS_INTERFACE and IP address" sub-bullet item: append a = comma > after "cases". >=20 > Page 11, "Tunnel nexthops" bullet item: change "Various" to "The". >=20 > Page 11, "tunnel encap" sub-bullet item: change "tunnel encap" to > "tunnel-encap" in the sub-bullet title to match Figure 4. Change = "encap" to > "encapsulation" in the first sentence. Change "tunnel encap" in the = 2nd > sentence to "tunnel-encap". >=20 > Page 11, "tunnel decap" sub-bullet item: change "tunnel decap" to > "tunnel-decap" in the sub-bullet title to match Figure 4. Change = "decap" to > "decapsulation" in the second sentence. Change the "a" before > "EGRESS_INTERFACE" to "an" in the third sentence. >=20 > Page 11, "logical tunnel" sub-bullet item: change "logical tunnel" to > "logical-tunnel" in the sub-bullet title to match Figure 4. Change = the "a" > before "MPLS" to "an". >=20 > Page 11, last (partial) paragraph, 2nd partial sentence: change = "end-point" to > "endpoint". >=20 > Page 12, Section 2.4.1.1, 1st sentence: change "drop" to "discard" to = match the > following discussion. >=20 > Page 12, Section 2.4.2, 1st paragraph after bullet items, 1st = sentence: delete > the comma. >=20 > Page 12, Section 2.4.2, 1st paragraph after bullet items, 3rd = sentence: delete > the comma. >=20 > Page 12, Section 2.4.2, 1st paragraph after bullet items, 6th = sentence: change > "and" to "or". Make "header" plural. >=20 > Page 13, Section 2.4.2.1, "NEXTHOP_PREFERENCE" bullet item, 4th = sentence: > insert "the" before "two". >=20 > Page 13, Section 2.4.2.1, "NEXTHOP_PREFERENCE" bullet item, last = sentence: > delete the asterisk and join "(Section 6)" with the rest of the = sentence. >=20 > Page 14, Section 3, 1st paragraph, 1st sentence: delete the comma. >=20 > Page 14, Section 3, 2nd paragraph, 2nd sentence: change "agent" to = "entity" to > at least be consistent with prior usage in the document. But also = refer back > to the issue listed above about use of the term "external entity". >=20 > Page 14, Section 4, 1st paragraph, 1st sentence: delete the comma. >=20 > Page 18, Section 6.1, 2nd sentence: append a comma after "preference". = Change > "multicasted" to "multicast" (the preferred form of the word). >=20 > Page 18, Section 7.2.1, last sentence: change "encap" to = "encapsulation".=20 > Change "decap" to "decapsulation". >=20 > Page 21, Section 7.2.6, 2nd sentence: delete the comma. >=20 > Page 21, Section 7.2.6, 5th sentence: change "Lets" to "Let's". >=20 > Page 23, Section 8, 2nd sentence: delete the comma. >=20 > Page 24, Section 11, 1st sentence: append a comma after "co-chair". = Change the > first occurrence of "on" to "for". >=20 > Page 24, Section 11, 2nd sentence: append a comma after "Hares". = Yeah, yeah, I > know, no one is going to require the Oxford comma here to figure out = what the > sentence means. ;-) >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Apr 5 06:46:51 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFDA120727; Thu, 5 Apr 2018 06:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 2jegeuiNErS0; Thu, 5 Apr 2018 06:46:41 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 0AE77120726; Thu, 5 Apr 2018 06:46:40 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Alissa Cooper'" , "'Peter Yee'" Cc: , "'IETF Gen-ART'" , References: <151943613720.13683.15859889318714950058@ietfa.amsl.com> <25FDF4BD-F8E5-431C-80D0-CEB147B443C5@cooperw.in> In-Reply-To: <25FDF4BD-F8E5-431C-80D0-CEB147B443C5@cooperw.in> Date: Thu, 5 Apr 2018 09:46:36 -0400 Message-ID: <041301d3cce4$84caa840$8e5ff8c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIMKZnvQMDnKR+mqnbhC/FAP4cB4ADtX02/o3oIRYA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] [Gen-art] Genart last call review of draft-ietf-i2rs-rib-info-model-14 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 13:46:44 -0000 Peter and Alissa:=20 Thank you for your careful review. I believe I saw Nitin's reply to = Peter's comments in email - so I'll look for that email and forward it.=20 As Shepherd, I will work with the authors to try to address the issues = in 2.2, and section 5.=20 >I think there's a discussion missing that may or may not be within = scope of >this document. RIBs appear to be typically divided according to the = protocol >for which they are providing routing (IPv4, MPLS, etc.) Section 7.1 = discusses >routing preferences, with an example of OSPF route and a route from = some other >protocol. When the OSPF route is withdrawn, the other route is = installed in >the FIB. What's not clear is what makes the decision to do this and = cause a >specific RIB to push its route into the FIB. Is that the routing = instance or >the RIB manager? A routing instance is described as a set of = interfaces, RIBs, >and routing parameters. It's description does not make it clear that = it >arbitrates among the RIBs or the routing protocols which are using the >northbound interface to talk to the RIB manager. Figure 1 makes it = seem like >there is a RIB manger per RIB, in which case how can the RIB manager = make >decisions between multiple RIBs? There is a RIB manager per RIB, but there is an overall RIB policy that = determines how the RIBs install things in specific FIBs. The specific = policy and issues may be guided by defacto standards (E.g. open-source = implementations or copying of a methodology among vendors). However, it = is a implementation detail. We'll try to work on a set of text that = explains this feature.=20 As Warren indicated this progresses into a nice introductions to how = RIBS work for University or for new hires. We'll work together to get = some text to explain this in the next revision.=20 Cheerily, Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: Thursday, April 5, 2018 9:31 AM To: Peter Yee Cc: i2rs@ietf.org; IETF Gen-ART; = draft-ietf-i2rs-rib-info-model.all@ietf.org Subject: Re: [i2rs] [Gen-art] Genart last call review of = draft-ietf-i2rs-rib-info-model-14 Peter, thanks for your review. Authors, thanks for addressing some of = Peter=E2=80=99s comments. I tried to pick out those of his comments that = remain unaddressed and put them in my No Objection ballot. Alissa > On Feb 23, 2018, at 8:35 PM, Peter Yee wrote: >=20 > Reviewer: Peter Yee > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area=20 > Review Team (Gen-ART) reviews all IETF documents being processed by=20 > the IESG for the IETF Chair. Please treat these comments just like=20 > any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-i2rs-rib-info-model-14 > Reviewer: Peter Yee > Review Date: 2018-02-22 > IETF LC End Date: 2018-02-23 > IESG Telechat date: 2018-03-08 >=20 > Summary: This Informational draft specifies an information model for=20 > routing information bases, providing modeling of the internal=20 > information of a router or similar network device. The draft is=20 > mostly ready, but has some issues that should be considered. [Ready=20 > with issues] >=20 > Major issues: None >=20 > Minor issues: >=20 > Page 4, 3rd full paragraph, 1st sentence: the draft introduces the=20 > concept of "RIB clients" in Figure 1, notes that they are generally=20 > routing protocols, and then never uses the term again. All other=20 > references to the what must be the users of the northbound interface=20 > are then called "external entities" for the most part. This is=20 > confusing because the term "external entity" is not defined nor fully=20 > equated with "RIB client". The term also seems to indicate that the=20 > "external entity" is not necessarily running on the network device. =20 > While that might be one way of looking at the feeding of data into the = > RIB via NETCONF or RESTCONF, that doesn't seem to be the case for a=20 > routing protocol. A fuller explanation of the users of the northbound = interface and a revision to Figure 1 might help clarify this situation. >=20 > Page 7, 1st paragraph after bullet list, last sentence: Routing=20 > instances are identified by ROUTER_IDs anyhow, so this sentence seems=20 > superfluous. Perhaps you are trying to get across the point that the=20 > ROUTER_ID (which is definitely present for the router) is not *used* = by this routing instance. >=20 > The term "ethernet" is used in several places in the document. Except = > in the grammar of section 6, change these to the capitalized=20 > "Ethernet". This brings up a larger point, however. Not all IEEE MAC = > addresses are associated with Ethernet interfaces and I believe this=20 > document is expected to be applicable to other IEEE 802 MACs such as=20 > IEEE 802.11 (WLAN) and IEEE 802.15 (WPAN). IEEE > 802.15 has long and short forms of MAC addresses, so you may want to=20 > give some additional thought to what you want to say with this term=20 > and pick something more appropriate. >=20 > I think there's a discussion missing that may or may not be within=20 > scope of this document. RIBs appear to be typically divided according = > to the protocol for which they are providing routing (IPv4, MPLS,=20 > etc.) Section 7.1 discusses routing preferences, with an example of=20 > OSPF route and a route from some other protocol. When the OSPF route=20 > is withdrawn, the other route is installed in the FIB. What's not=20 > clear is what makes the decision to do this and cause a specific RIB=20 > to push its route into the FIB. Is that the routing instance or the=20 > RIB manager? A routing instance is described as a set of interfaces,=20 > RIBs, and routing parameters. It's description does not make it clear = > that it arbitrates among the RIBs or the routing protocols which are=20 > using the northbound interface to talk to the RIB manager. Figure 1=20 > makes it seem like there is a RIB manger per RIB, in which case how = can the RIB manager make decisions between multiple RIBs? >=20 > Page 14, Section 3, 2nd paragraph, 2nd sentence: a "connection" is=20 > mentioned here. This document purports to deal with an API (and one=20 > that would mostly be used by local routing protocols if the figures=20 > are to be believed) and hasn't otherwise made any mention of a=20 > connection, let alone what constitutes a connection and defines its=20 > lifetime. More discussion is needed of this concept instead of just=20 > (possibly) resting the whole thing on brief mentions of NETCONF and=20 > RESTCONF (which aren't even brought into the picture until the = Security Considerations section later on in the document). >=20 > Page 15, 1st partial paragraph: there are unstated assumptions about=20 > needing a subscription mechanism for subscribing to notifications,=20 > particularly notifications from RIBs that were not created by the=20 > entity. (This goes back to the concept on the previous page that=20 > entities may possibly read to or write from RIBs they did not create.) = =20 > The discussion of notifications could use some fleshing out here. >=20 > Nits/editorial comments: >=20 > General: >=20 > Append a comma after "i.e." and "e.g." Make all uses of "e.g." lower = case.=20 > Some uses of "e.g." have double spaces after them and those double=20 > spaces should be replaced with single spaces. >=20 > Change "use-cases" to "use cases" throughout the document. Or use the = > other way around. Just be consistent in the usage. Non-hyphenate=20 > usage appears to be preferred. >=20 > Insert a blank line before and after bullet lists for readability. =20 > Consider adding a blank line between entries to aid readability as = well. >=20 > Specific: >=20 > Page 1, Abstract, 2nd sentence: delete the semicolon. >=20 > Page 1, Abstract, 4th sentence: replace the space between "higher" and = "level" > with a hyphen. >=20 > Page 3, Section 1, 2nd sentence: change "config" to "configuration = information" > (or something similar). >=20 > Page 3, Section 1, 3rd sentence: change "north-bound" to "northbound". = =20 > Append a comma after each of "clients", "i.e.", and "protocols". >=20 > Page 3, Figure 1 caption: append a comma after "clients". >=20 > Page 4, 1st partial paragraph, 1st complete sentence: change "which" = to "that". > Append a comma after "policies". >=20 > Page 4, 1st partial paragraph, 4th complete sentence: replace the=20 > space between "publicly" and "documented" with a hyphen and then=20 > append a comma after "publicly-documented". >=20 > Page 4, 2nd full paragraph, 1st sentence: I'm not sure what "show=20 > output screen scraping" is. I'm familiar with screen scraping, but=20 > could not find a good source for your term. Perhaps you could explain = or modify it? >=20 > Page 5, Section 1.1: you may wish to reference RFC 8174, which updates = > RFC 2119 and makes it applicable across more than Standards Track = documents. >=20 > Page 5, Section 2, 4th sentence: delete the comma after "single". >=20 > Page 5, Section 2, 5th sentence: make "Section" lower case. >=20 > Page 5, Section 2, 6th sentence: change the space between "high" and=20 > "level" to a hyphen. >=20 > Page 5, Figure 2: remove the space between "routing-instance" and = "(s)". >=20 > Page 5, Section 2.1, 3rd sentence: change "intance" to "instance". =20 > Also fix the sentence or Figure 2: the sentence says 1 or more RIBs,=20 > the diagram shows 0 or more. I'm not sure how a zero RIB routing=20 > instance is useful, but make the two ranges consistent. >=20 > Page 6, 1st paragraph, 1st sentence: delete this sentence as it is=20 > redundant with information given in the previous paragraph on Page 5. >=20 > Page 6, 2nd paragraph, 1st sentence: Change "a" to "an" before=20 > "ENABLE_IP_RPF_CHECK". Capitalize each word in "Reverse path = forwarding". >=20 > Page 6, 2nd paragraph, 2nd sentence: delete "Reverse path forwarding", = > insert the word "The" at the beginning of the sentence and remove the=20 > parentheses around "RPF". >=20 > Page 6, 2nd paragraph, 3rd and 4th sentences: change "rpf" to "RPF". >=20 > Page 6, Section 2.2, 1st paragraph, 3rd sentence: delete both = semicolons. >=20 > Page 6, "interface-list" bullet item, 3rd sentence: I think it reads=20 > better with "in" inserted before "on". >=20 > Page 7, "ROUTER_ID" bullet item: change "router-id" to "ROUTER_ID". =20 > Or if you want a descriptive term, change it to "router = identification". >=20 > Page 8, MPLS bullet item: "change "a" to "an". >=20 > Page 8, paragraph after "route-vendor-attributes" bullet item, 1st = sentence: > change "Nexthop" to "nexthop". >=20 > Page 9, 1st partial paragraph, 4th full sentence: change "a" to "an"=20 > before "MPLS". >=20 > Page 9, 1st partial paragraph, 7th full sentence: append a comma after = > "Conversely". Insert "the" before "case". >=20 > Page 10, 1st paragraph, 1st sentence: put a comma after "extensible". >=20 > Page 10, 1st paragraph, 5th sentence: change "it's" to "its". >=20 > Page 11, "EGRESS_INTERFACE" sub-bullet item: append a comma after = "logical". >=20 > Page 11, "EGRESS_INTERFACE and IP address" sub-bullet item: append a=20 > comma after "cases". >=20 > Page 11, "Tunnel nexthops" bullet item: change "Various" to "The". >=20 > Page 11, "tunnel encap" sub-bullet item: change "tunnel encap" to=20 > "tunnel-encap" in the sub-bullet title to match Figure 4. Change=20 > "encap" to "encapsulation" in the first sentence. Change "tunnel=20 > encap" in the 2nd sentence to "tunnel-encap". >=20 > Page 11, "tunnel decap" sub-bullet item: change "tunnel decap" to=20 > "tunnel-decap" in the sub-bullet title to match Figure 4. Change=20 > "decap" to "decapsulation" in the second sentence. Change the "a"=20 > before "EGRESS_INTERFACE" to "an" in the third sentence. >=20 > Page 11, "logical tunnel" sub-bullet item: change "logical tunnel" to=20 > "logical-tunnel" in the sub-bullet title to match Figure 4. Change = the "a" > before "MPLS" to "an". >=20 > Page 11, last (partial) paragraph, 2nd partial sentence: change=20 > "end-point" to "endpoint". >=20 > Page 12, Section 2.4.1.1, 1st sentence: change "drop" to "discard" to=20 > match the following discussion. >=20 > Page 12, Section 2.4.2, 1st paragraph after bullet items, 1st=20 > sentence: delete the comma. >=20 > Page 12, Section 2.4.2, 1st paragraph after bullet items, 3rd=20 > sentence: delete the comma. >=20 > Page 12, Section 2.4.2, 1st paragraph after bullet items, 6th=20 > sentence: change "and" to "or". Make "header" plural. >=20 > Page 13, Section 2.4.2.1, "NEXTHOP_PREFERENCE" bullet item, 4th = sentence: > insert "the" before "two". >=20 > Page 13, Section 2.4.2.1, "NEXTHOP_PREFERENCE" bullet item, last = sentence: > delete the asterisk and join "(Section 6)" with the rest of the = sentence. >=20 > Page 14, Section 3, 1st paragraph, 1st sentence: delete the comma. >=20 > Page 14, Section 3, 2nd paragraph, 2nd sentence: change "agent" to=20 > "entity" to at least be consistent with prior usage in the document. =20 > But also refer back to the issue listed above about use of the term = "external entity". >=20 > Page 14, Section 4, 1st paragraph, 1st sentence: delete the comma. >=20 > Page 18, Section 6.1, 2nd sentence: append a comma after "preference". = =20 > Change "multicasted" to "multicast" (the preferred form of the word). >=20 > Page 18, Section 7.2.1, last sentence: change "encap" to = "encapsulation".=20 > Change "decap" to "decapsulation". >=20 > Page 21, Section 7.2.6, 2nd sentence: delete the comma. >=20 > Page 21, Section 7.2.6, 5th sentence: change "Lets" to "Let's". >=20 > Page 23, Section 8, 2nd sentence: delete the comma. >=20 > Page 24, Section 11, 1st sentence: append a comma after "co-chair". =20 > Change the first occurrence of "on" to "for". >=20 > Page 24, Section 11, 2nd sentence: append a comma after "Hares". =20 > Yeah, yeah, I know, no one is going to require the Oxford comma here=20 > to figure out what the sentence means. ;-) >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Apr 5 06:48:44 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A63120727; Thu, 5 Apr 2018 06:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 gnHjulcvy3Cf; Thu, 5 Apr 2018 06:48:34 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 4E20E120726; Thu, 5 Apr 2018 06:48:34 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Suresh Krishnan'" , "'The IESG'" Cc: , , References: <152281674476.24011.1275548255371559292.idtracker@ietfa.amsl.com> In-Reply-To: <152281674476.24011.1275548255371559292.idtracker@ietfa.amsl.com> Date: Thu, 5 Apr 2018 09:48:27 -0400 Message-ID: <041501d3cce4$c7e59cc0$57b0d640$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIbu6ObnXRG2bdWXfOwGLqUvIyZi6NiQV8A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 13:48:36 -0000 Suresh: Thank you for catching these issues. I missed these as a Shepherd (as did the other reviewers) and AD. See my answers below. Would you or Martin hold a discuss until these critical issues are resolved and checked with the YANG doctors? I will work with the authors to resolve these issues. This revision will take some time as we seek advice from the YANG doctors and from the community on the IEEE MAC Address being an index or a full MAC Address. Susan Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Suresh Krishnan Sent: Wednesday, April 4, 2018 12:39 AM To: The IESG Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i2rs-chairs@ietf.org; shares@ndzh.com Subject: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This model tries to squeeze the 20 bit IPv6 flow label into a 16 bit field. This will result in a loss of data and needs to be fixed before the document is published. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 3 => Under identity ipv6-decapsulation { it looks like the description is wrong ("IPv4 tunnel decapsulation.") ---- You are correct. It will be replaced with the following ========= identity ipv6-decapsulation { base "tunnel-decapsulation-action"; description "IPv6 tunnel decapsulation."; } => What use case is the ttl-action decrease-and-copy-to-inner used for? ---- Good catch! This feature may be used for tunnels (7.2.1 of draft-ietf-i2rs-rib-info-model) or nexthops chains (section 7.2.5 of draft-ietf-i2rs-rib-info-model). Good catch in that it does not provide enough detail in this version. We've had comments over the last years to put this level of detail in or out of the YANG model. I believe the latest wisdom from NETMOD/NETCONF is to put the level of detail back in => Under case egress-interface-mac-nexthop { It is not clear to me how you fit a MAC address into a 32 bit space ,or am I misreading this somehow and this is some form of index? Good Catch. Early on it was a holding place for a the official IEEE:MAC table, and should have been transferred to either the IEEE:MAC-ADDRESS (see page 17 RIB-INFO draft). However, this definitely needs to get fixed. I need to check with the YANG Doctors to determine which is the preferred fix for this reference at this time. I'm sure implementers have been using a fully qualified IEEE_MAC_ADDRESS or a reference to the Table. High level - case points to an outgoing interface, ieee-mac address - case egress-interface-mac-nexthop { container egress-interface-mac-address { leaf outgoing-interface { type if:interface-ref; mandatory true; description "Name of the outgoing interface."; } leaf ieee-mac-address { type uint32; mandatory true; description "The nexthop points to an interface with a specific mac-address."; } description "The egress interface must be an Ethernet interface. Address resolution is not required for this nexthop."; } } It is not clear to me how you fit a MAC address into a 32 bit space ,or am I misreading this somehow and this is some form of index? " leaf ieee-mac-address { type uint32;" _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Apr 5 06:52:42 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E735B120727; Thu, 5 Apr 2018 06:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] 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 2X2k4h1H00uU; Thu, 5 Apr 2018 06:52:38 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 75D2D120726; Thu, 5 Apr 2018 06:52:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Alissa Cooper'" , "'Peter Yee'" Cc: , , "'The IESG'" , References: <691C7A84-6590-4823-9979-4EC48FC64B2C@yahoo.com> In-Reply-To: <691C7A84-6590-4823-9979-4EC48FC64B2C@yahoo.com> Date: Thu, 5 Apr 2018 09:52:32 -0400 Message-ID: <042701d3cce5$592af180$0b80d480$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0428_01D3CCC3.D21E3380" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHdHJP2Ok1/hiaKbF35u2xB7TEF9aPfkPsQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] FW: [Gen-art] Genart last call review of draft-ietf-i2rs-rib-info-model-14 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 13:52:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0428_01D3CCC3.D21E3380 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0429_01D3CCC3.D21E3380" ------=_NextPart_001_0429_01D3CCC3.D21E3380 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alissa: =20 Here=E2=80=99s Nitin=E2=80=99s response to Peter.=20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur Sent: Friday, March 23, 2018 2:55 AM To: peter@akayla.com Cc: i2rs@ietf.org Subject: Re: [i2rs] [Gen-art] Genart last call review of = draft-ietf-i2rs-rib-info-model-14 =20 Hi Peter, =20 Thanks for the Gen-art review. Sorry it missed my attention back = when you sent it. Please see NB> below for comments. =20 =20 Reviewer: Peter Yee Review result: Ready with Issues =20 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. =20 For more information, please see the FAQ at < = https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;. =20 Document: draft-ietf-i2rs-rib-info-model-14 Reviewer: Peter Yee Review Date: 2018-02-22 IETF LC End Date: 2018-02-23 IESG Telechat date: 2018-03-08 =20 Summary: This Informational draft specifies an information model for = routing information bases, providing modeling of the internal information of a = router or similar network device. The draft is mostly ready, but has some = issues that should be considered. [Ready with issues] =20 Major issues: None =20 Minor issues: =20 Page 4, 3rd full paragraph, 1st sentence: the draft introduces the = concept of "RIB clients" in Figure 1, notes that they are generally routing = protocols, and then never uses the term again. All other references to the what must = be the users of the northbound interface are then called "external entities" = for the most part. This is confusing because the term "external entity" is not = defined nor fully equated with "RIB client". The term also seems to indicate = that the "external entity" is not necessarily running on the network device. = While that might be one way of looking at the feeding of data into the RIB via = NETCONF or RESTCONF, that doesn't seem to be the case for a routing protocol. A = fuller explanation of the users of the northbound interface and a revision to = Figure 1 might help clarify this situation. =20 NB> You are right. I=E2=80=99m updating the draft to replace = =E2=80=9Cexternal entities=E2=80=9D to =E2=80=9CRIB client=E2=80=9D. =20 Page 7, 1st paragraph after bullet list, last sentence: Routing = instances are identified by ROUTER_IDs anyhow, so this sentence seems superfluous.=20 Perhaps you are trying to get across the point that the ROUTER_ID (which = is definitely present for the router) is not *used* by this routing instance. =20 NB> That sentence was requested by some folks to ensure that ROUTER_ID = based conflicts do not occur. =20 The term "ethernet" is used in several places in the document. Except = in the grammar of section 6, change these to the capitalized "Ethernet".=20 =20 NB> Done =20 This brings up a larger point, however. Not all IEEE MAC addresses are = associated with Ethernet interfaces and I believe this document is expected to be = applicable to other IEEE 802 MACs such as IEEE 802.11 (WLAN) and IEEE 802.15 (WPAN). = IEEE 802.15 has long and short forms of MAC addresses, so you may want to = give some additional thought to what you want to say with this term and pick = something more appropriate. =20 NB> In Section 2.4.1, when talking about the IEEE MAC we say that = =E2=80=9CThe egress interface=20 must be an Ethernet interface.=E2=80=9D So the MAC is to be used only in = the context of Ethernet interfaces. =20 NB> With regards to short and long form of MAC addresses, these should = get specified in the data-model,=20 since the data-model will need to validate things. =20 I think there's a discussion missing that may or may not be within scope = of this document. RIBs appear to be typically divided according to the = protocol for which they are providing routing (IPv4, MPLS, etc.) Section 7.1 = discusses routing preferences, with an example of OSPF route and a route from some = other protocol. When the OSPF route is withdrawn, the other route is = installed in the FIB. What's not clear is what makes the decision to do this and = cause a specific RIB to push its route into the FIB. Is that the routing = instance or the RIB manager?=20 =20 NB> It should be the RIB manager. =20 A routing instance is described as a set of interfaces, RIBs, and routing parameters. It's description does not make it clear that it arbitrates among the RIBs or the routing protocols which are using the northbound interface to talk to the RIB manager. Figure 1 makes it seem = like there is a RIB manger per RIB, in which case how can the RIB manager = make decisions between multiple RIBs? =20 NB> Good point. I=E2=80=99ll change the figure to indicate that the RIB = manager handles 1 or more RIBs. =20 Page 14, Section 3, 2nd paragraph, 2nd sentence: a "connection" is = mentioned here. This document purports to deal with an API (and one that would = mostly be used by local routing protocols if the figures are to be believed) and = hasn't otherwise made any mention of a connection, let alone what constitutes a connection and defines its lifetime. More discussion is needed of this = concept instead of just (possibly) resting the whole thing on brief mentions of = NETCONF and RESTCONF (which aren't even brought into the picture until the = Security Considerations section later on in the document). =20 NB> Removed the sentence related to =E2=80=9Cconnection=E2=80=9D. You = are right that this sentence causes more confusion and little value. =20 Page 15, 1st partial paragraph: there are unstated assumptions about = needing a subscription mechanism for subscribing to notifications, particularly notifications from RIBs that were not created by the entity. (This goes = back to the concept on the previous page that entities may possibly read to = or write from RIBs they did not create.) The discussion of notifications could = use some fleshing out here. =20 NB> How notifications are sent, whether using a subscription model or = something else is left to the Data Model. And it=E2=80=99s left = un-fleshed to allow the data-model writers to decide what to do here. =20 Nits/editorial comments: =20 NB> I=E2=80=99m addressing all your nits in version 15. For nits not = being addressed, see NB> below. =20 General: =20 Append a comma after "i.e." and "e.g." Make all uses of "e.g." lower = case.=20 Some uses of "e.g." have double spaces after them and those double = spaces should be replaced with single spaces. =20 Change "use-cases" to "use cases" throughout the document. Or use the = other way around. Just be consistent in the usage. Non-hyphenate usage = appears to be preferred.. =20 Insert a blank line before and after bullet lists for readability. = Consider adding a blank line between entries to aid readability as well. =20 Specific: =20 Page 1, Abstract, 2nd sentence: delete the semicolon. =20 Page 1, Abstract, 4th sentence: replace the space between "higher" and = "level" with a hyphen. =20 Page 3, Section 1, 2nd sentence: change "config" to "configuration = information" (or something similar). =20 Page 3, Section 1, 3rd sentence: change "north-bound" to "northbound". = Append a comma after each of "clients", "i.e.", and "protocols". =20 Page 3, Figure 1 caption: append a comma after "clients". =20 Page 4, 1st partial paragraph, 1st complete sentence: change "which" to = "that". Append a comma after "policies". =20 Page 4, 1st partial paragraph, 4th complete sentence: replace the space = between "publicly" and "documented" with a hyphen and then append a comma after "publicly-documented". =20 Page 4, 2nd full paragraph, 1st sentence: I'm not sure what "show output = screen scraping" is. I'm familiar with screen scraping, but could not find a = good source for your term. Perhaps you could explain or modify it? =20 NB> Modified it to =E2=80=9Cscreen scraping=E2=80=9D =20 Page 5, Section 1.1: you may wish to reference RFC 8174, which updates = RFC 2119 and makes it applicable across more than Standards Track documents. =20 NB> Done =20 Page 5, Section 2, 4th sentence: delete the comma after "single". =20 Page 5, Section 2, 5th sentence: make "Section" lower case. =20 Page 5, Section 2, 6th sentence: change the space between "high" and = "level" to a hyphen. =20 Page 5, Figure 2: remove the space between "routing-instance" and "(s)". =20 Page 5, Section 2.1, 3rd sentence: change "intance" to "instance". Also = fix the sentence or Figure 2: the sentence says 1 or more RIBs, the diagram = shows 0 or more. I'm not sure how a zero RIB routing instance is useful, but = make the two ranges consistent. =20 NB> Updated =20 Page 6, 1st paragraph, 1st sentence: delete this sentence as it is = redundant with information given in the previous paragraph on Page 5. =20 NB> While it is redundant, it adds clarity where the item is being = defined. =20 Page 6, 2nd paragraph, 1st sentence: Change "a" to "an" before "ENABLE_IP_RPF_CHECK". Capitalize each word in "Reverse path = forwarding". =20 Page 6, 2nd paragraph, 2nd sentence: delete "Reverse path forwarding", = insert the word "The" at the beginning of the sentence and remove the = parentheses around "RPF". =20 Page 6, 2nd paragraph, 3rd and 4th sentences: change "rpf" to "RPF". =20 Page 6, Section 2.2, 1st paragraph, 3rd sentence: delete both = semicolons. =20 Page 6, "interface-list" bullet item, 3rd sentence: I think it reads = better with "in" inserted before "on". =20 Page 7, "ROUTER_ID" bullet item: change "router-id" to "ROUTER_ID". Or = if you want a descriptive term, change it to "router identification". =20 Page 8, MPLS bullet item: "change "a" to "an". =20 Page 8, paragraph after "route-vendor-attributes" bullet item, 1st = sentence: change "Nexthop" to "nexthop". =20 Page 9, 1st partial paragraph, 4th full sentence: change "a" to "an" = before "MPLS". =20 Page 9, 1st partial paragraph, 7th full sentence: append a comma after "Conversely". Insert "the" before "case". =20 Page 10, 1st paragraph, 1st sentence: put a comma after "extensible". =20 Page 10, 1st paragraph, 5th sentence: change "it's" to "its". =20 Page 11, "EGRESS_INTERFACE" sub-bullet item: append a comma after = "logical". =20 Page 11, "EGRESS_INTERFACE and IP address" sub-bullet item: append a = comma after "cases". =20 Page 11, "Tunnel nexthops" bullet item: change "Various" to "The". =20 Page 11, "tunnel encap" sub-bullet item: change "tunnel encap" to "tunnel-encap" in the sub-bullet title to match Figure 4. Change = "encap" to "encapsulation" in the first sentence. Change "tunnel encap" in the 2nd sentence to "tunnel-encap". =20 Page 11, "tunnel decap" sub-bullet item: change "tunnel decap" to "tunnel-decap" in the sub-bullet title to match Figure 4. Change = "decap" to "decapsulation" in the second sentence. Change the "a" before "EGRESS_INTERFACE" to "an" in the third sentence. =20 Page 11, "logical tunnel" sub-bullet item: change "logical tunnel" to "logical-tunnel" in the sub-bullet title to match Figure 4. Change the = "a" before "MPLS" to "an". =20 Page 11, last (partial) paragraph, 2nd partial sentence: change = "end-point" to "endpoint". =20 Page 12, Section 2.4.1.1, 1st sentence: change "drop" to "discard" to = match the following discussion. =20 Page 12, Section 2.4.2, 1st paragraph after bullet items, 1st sentence: = delete the comma.. =20 Page 12, Section 2.4.2, 1st paragraph after bullet items, 3rd sentence: = delete the comma. =20 Page 12, Section 2.4.2, 1st paragraph after bullet items, 6th sentence: = change "and" to "or". Make "header" plural. =20 Page 13, Section 2.4.2.1, "NEXTHOP_PREFERENCE" bullet item, 4th = sentence: insert "the" before "two". =20 Page 13, Section 2.4.2.1, "NEXTHOP_PREFERENCE" bullet item, last = sentence: delete the asterisk and join "(Section 6)" with the rest of the = sentence. =20 Page 14, Section 3, 1st paragraph, 1st sentence: delete the comma. =20 Page 14, Section 3, 2nd paragraph, 2nd sentence: change "agent" to = "entity" to at least be consistent with prior usage in the document. But also refer = back to the issue listed above about use of the term "external entity". =20 Page 14, Section 4, 1st paragraph, 1st sentence: delete the comma. =20 Page 18, Section 6.1, 2nd sentence: append a comma after "preference". = Change "multicasted" to "multicast" (the preferred form of the word). =20 Page 18, Section 7.2.1, last sentence: change "encap" to = "encapsulation".=20 Change "decap" to "decapsulation". =20 Page 21, Section 7.2.6, 2nd sentence: delete the comma. =20 Page 21, Section 7.2.6, 5th sentence: change "Lets" to "Let's". =20 Page 23, Section 8, 2nd sentence: delete the comma. =20 Page 24, Section 11, 1st sentence: append a comma after "co-chair". = Change the first occurrence of "on" to "for". =20 Page 24, Section 11, 2nd sentence: append a comma after "Hares". Yeah, = yeah, I know, no one is going to require the Oxford comma here to figure out = what the sentence means. ;-) =20 Thanks Nitin ------=_NextPart_001_0429_01D3CCC3.D21E3380 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Alissa:

 

Here=E2=80=99s Nitin=E2=80=99s = response to Peter.

 

Sue = Hares

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin = Bahadur
Sent: Friday, March 23, 2018 2:55 AM
To: = peter@akayla.com
Cc: i2rs@ietf.org
Subject: Re: = [i2rs] [Gen-art] Genart last call review of = draft-ietf-i2rs-rib-info-model-14

 

Hi Peter,

 

   =    Thanks for the Gen-art review. Sorry it missed my = attention back when you sent it. Please see NB> below for = comments.

 

 

Reviewer: Peter =
Yee
Review result: Ready with =
Issues
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>I am the assigned Gen-ART = reviewer for this draft. The General Area
Review Team (Gen-ART) reviews =
all IETF documents being processed
by the IESG for the IETF =
Chair.  Please treat these comments =
just
like any other last call =
comments.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>For more information, please = see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>=
;.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Document: = draft-ietf-i2rs-rib-info-model-14
Reviewer: Peter =
Yee
Review Date: =
2018-02-22
IETF LC End Date: =
2018-02-23
IESG Telechat date: =
2018-03-08
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Summary: This Informational = draft specifies an information model for = routing
information bases, providing =
modeling of the internal information of a =
router
or similar network =
device.  The draft is mostly ready, but has some issues =
that
should be considered. [Ready =
with issues]
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Major issues: = None
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Minor = issues:
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 4, 3rd full paragraph, = 1st sentence: the draft introduces the concept = of
"RIB clients" in =
Figure 1, notes that they are generally routing protocols, =
and
then never uses the term =
again.  All other references to the what must be =
the
users of the northbound =
interface are then called "external entities" for =
the
most part.  This is =
confusing because the term "external entity" is not =
defined
nor fully equated with =
"RIB client".  The term also seems to indicate that =
the
"external entity" is =
not necessarily running on the network device.  While =
that
might be one way of looking at =
the feeding of data into the RIB via NETCONF =
or
RESTCONF, that doesn't seem to =
be the case for a routing protocol.  A =
fuller
explanation of the users of =
the northbound interface and a revision to Figure =
1
might help clarify this =
situation.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> You are right. = I=E2=80=99m updating the draft to replace =E2=80=9Cexternal = entities=E2=80=9D to =E2=80=9CRIB = client=E2=80=9D.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 7, 1st paragraph after = bullet list, last sentence: Routing instances = are
identified by ROUTER_IDs =
anyhow, so this sentence seems superfluous. 
Perhaps you are trying to get =
across the point that the ROUTER_ID (which is =
definitely
present for the router) is not =
*used* by this routing instance.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> That sentence was = requested by some folks to ensure that ROUTER_ID based conflicts do not = occur.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>The term "ethernet" = is used in several places in the document.  Except in = the
grammar of section 6, change =
these to the capitalized "Ethernet". =

 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> = Done
 
<= pre style=3D'background:white;margin-bottom:7..5pt'>This brings up a larger point, = however.  Not all IEEE MAC addresses are associated = with
Ethernet interfaces and I =
believe this document is expected to be applicable =
to
other IEEE 802 MACs such as =
IEEE 802.11 (WLAN) and IEEE 802.15 (WPAN).  =
IEEE
802.15 has long and short =
forms of MAC addresses, so you may want to give =
some
additional thought to what you =
want to say with this term and pick =
something
more =
appropriate.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> In Section 2.4.1, when = talking about the IEEE MAC we say that =E2=80=9CThe egress interface = 
must be an Ethernet =
interface.=E2=80=9D So the MAC is to be used only in the context of =
Ethernet interfaces.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> With regards to short = and long form of MAC addresses, these should get specified in the = data-model, 
since the data-model will need =
to validate things.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>I think there's a discussion = missing that may or may not be within scope = of
this document.  RIBs =
appear to be typically divided according to the =
protocol
for which they are providing =
routing (IPv4, MPLS, etc.)  Section 7.1 =
discusses
routing preferences, with an =
example of OSPF route and a route from some =
other
protocol.  When the OSPF =
route is withdrawn, the other route is installed =
in
the FIB.  What's not =
clear is what makes the decision to do this and cause =
a
specific RIB to push its route =
into the FIB.  Is that the routing instance =
or
the RIB manager? =

 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> It should be the RIB = manager.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'> A routing instance is = described as a set of interfaces, RIBs,
and routing parameters.  =
It's description does not make it clear that =
it
arbitrates among the RIBs or =
the routing protocols which are using the
northbound interface to talk =
to the RIB manager.  Figure 1 makes it seem =
like
there is a RIB manger per RIB, =
in which case how can the RIB manager make
decisions between multiple =
RIBs?
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> Good point. = I=E2=80=99ll change the figure to indicate that the RIB manager handles = 1 or more RIBs.
 
<= pre style=3D'background:white;margin-bottom:7..5pt'>Page 14, Section 3, 2nd = paragraph, 2nd sentence: a "connection" is = mentioned
here.  This document =
purports to deal with an API (and one that would mostly =
be
used by local routing =
protocols if the figures are to be believed) and =
hasn't
otherwise made any mention of =
a connection, let alone what constitutes a
connection and defines its =
lifetime.  More discussion is needed of this =
concept
instead of just (possibly) =
resting the whole thing on brief mentions of =
NETCONF
and RESTCONF (which aren't =
even brought into the picture until the =
Security
Considerations section later =
on in the document).
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> Removed the sentence = related to =E2=80=9Cconnection=E2=80=9D. You are right that this = sentence causes more confusion and little = value.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 15, 1st partial = paragraph: there are unstated assumptions about needing = a
subscription mechanism for =
subscribing to notifications, particularly
notifications from RIBs that =
were not created by the entity.  (This goes =
back
to the concept on the previous =
page that entities may possibly read to or =
write
from RIBs they did not =
create.)  The discussion of notifications could use =
some
fleshing out =
here.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> How notifications are = sent, whether using a subscription model or something else is left to = the Data Model. And it=E2=80=99s left un-fleshed to allow the data-model = writers to decide what to do here.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Nits/editorial = comments:
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> I=E2=80=99m addressing = all your nits in version 15. For nits not being addressed, see NB> = below.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>General:<= /pre>
 
Append a comma after =
"i.e." and "e.g."  Make all uses of =
"e.g." lower case. 
Some uses of "e.g." =
have double spaces after them and those double =
spaces
should be replaced with single =
spaces.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Change "use-cases" = to "use cases" throughout the document.  Or use the = other
way around.  Just be =
consistent in the usage.  Non-hyphenate usage appears =
to
be =
preferred..
 
Insert a blank line before and =
after bullet lists for readability.  =
Consider
adding a blank line between =
entries to aid readability as well.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Specific:= 
 
Page 1, Abstract, 2nd =
sentence: delete the semicolon.
 
Page 1, Abstract, 4th =
sentence: replace the space between "higher" and =
"level"
with a =
hyphen.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 3, Section 1, 2nd = sentence: change "config" to "configuration = information"
(or something =
similar).
 
Page 3, Section 1, 3rd =
sentence: change "north-bound" to =
"northbound".  Append
a comma after each of =
"clients", "i.e.", and =
"protocols".
 
Page 3, Figure 1 caption: =
append a comma after =
"clients".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 4, 1st partial paragraph, = 1st complete sentence: change "which" to = "that".
 Append a comma after =
"policies".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 4, 1st partial paragraph, = 4th complete sentence: replace the space = between
"publicly" and =
"documented" with a hyphen and then append a comma =
after
"publicly-documented"=
.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 4, 2nd full paragraph, = 1st sentence: I'm not sure what "show output = screen
scraping" is.  I'm =
familiar with screen scraping, but could not find a =
good
source for your term.  =
Perhaps you could explain or modify it?
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> Modified it to = =E2=80=9Cscreen scraping=E2=80=9D
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 5, Section 1.1: you may = wish to reference RFC 8174, which updates RFC = 2119
and makes it applicable across =
more than Standards Track documents.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> = Done
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 5, Section 2, 4th = sentence: delete the comma after = "single".
 
Page 5, Section 2, 5th =
sentence: make "Section" lower =
case.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 5, Section 2, 6th = sentence: change the space between "high" and = "level" to
a =
hyphen.
 
Page 5, Figure 2: remove the =
space between "routing-instance" and =
"(s)".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 5, Section 2.1, 3rd = sentence: change "intance" to "instance".  = Also = fix
the sentence or Figure 2: the =
sentence says 1 or more RIBs, the diagram shows =
0
or more.  I'm not sure =
how a zero RIB routing instance is useful, but make =
the
two ranges =
consistent.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> = Updated
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 6, 1st paragraph, 1st = sentence: delete this sentence as it is = redundant
with information given in the =
previous paragraph on Page 5.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>NB> While it is redundant, = it adds clarity where the item is being = defined.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 6, 2nd paragraph, 1st = sentence: Change "a" to "an" = before
"ENABLE_IP_RPF_CHECK"=
.  Capitalize each word in "Reverse path =
forwarding".
 
<= pre style=3D'background:white;margin-bottom:7..5pt'>Page 6, 2nd paragraph, 2nd = sentence: delete "Reverse path forwarding", = insert
the word "The" at =
the beginning of the sentence and remove the =
parentheses
around =
"RPF".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 6, 2nd paragraph, 3rd and = 4th sentences: change "rpf" to = "RPF".
 
Page 6, Section 2.2, 1st =
paragraph, 3rd sentence: delete both =
semicolons.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 6, = "interface-list" bullet item, 3rd sentence: I think it reads = better
with "in" inserted =
before "on".
 
Page 7, "ROUTER_ID" =
bullet item: change "router-id" to =
"ROUTER_ID".  Or if you
want a descriptive term, =
change it to "router =
identification".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 8, MPLS bullet item: = "change "a" to = "an".
 
Page 8, paragraph after =
"route-vendor-attributes" bullet item, 1st =
sentence:
change "Nexthop" to =
"nexthop".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 9, 1st partial paragraph, = 4th full sentence: change "a" to "an" = before
"MPLS".
 
Page 9, 1st partial paragraph, =
7th full sentence: append a comma after
"Conversely".  =
Insert "the" before =
"case".
 
Page 10, 1st paragraph, 1st =
sentence: put a comma after =
"extensible".
 
Page 10, 1st paragraph, 5th =
sentence: change "it's" to =
"its".
 
Page 11, =
"EGRESS_INTERFACE" sub-bullet item: append a comma after =
"logical".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 11, = "EGRESS_INTERFACE and IP address" sub-bullet item: append a = comma
after =
"cases".
 
Page 11, "Tunnel =
nexthops" bullet item: change "Various" to =
"The".
 
Page 11, "tunnel =
encap" sub-bullet item: change "tunnel encap" =
to
"tunnel-encap" in =
the sub-bullet title to match Figure 4.  Change "encap" =
to
"encapsulation" in =
the first sentence.  Change "tunnel encap" in the =
2nd
sentence to =
"tunnel-encap".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 11, "tunnel = decap" sub-bullet item: change "tunnel decap" = to
"tunnel-decap" in =
the sub-bullet title to match Figure 4.  Change "decap" =
to
"decapsulation" in =
the second sentence.  Change the "a" =
before
"EGRESS_INTERFACE" =
to "an" in the third sentence.
 
Page 11, "logical =
tunnel" sub-bullet item: change "logical tunnel" =
to
"logical-tunnel" in =
the sub-bullet title to match Figure 4.  Change the =
"a"
before "MPLS" to =
"an".
 
Page 11, last (partial) =
paragraph, 2nd partial sentence: change "end-point" =
to
"endpoint".
 
Page 12, Section 2.4.1.1, 1st =
sentence: change "drop" to "discard" to match =
the
following =
discussion.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 12, Section 2.4.2, 1st = paragraph after bullet items, 1st sentence: = delete
the =
comma..
 
Page 12, Section 2.4.2, 1st =
paragraph after bullet items, 3rd sentence: =
delete
the =
comma.
 
Page 12, Section 2.4.2, 1st =
paragraph after bullet items, 6th sentence: =
change
"and" to =
"or".  Make "header" =
plural.
 
Page 13, Section 2.4.2.1, =
"NEXTHOP_PREFERENCE" bullet item, 4th =
sentence:
insert "the" before =
"two".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 13, Section 2.4.2.1, = "NEXTHOP_PREFERENCE" bullet item, last = sentence:
delete the asterisk and join =
"(Section 6)" with the rest of the =
sentence.
 
Page 14, Section 3, 1st =
paragraph, 1st sentence: delete the comma.
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 14, Section 3, 2nd = paragraph, 2nd sentence: change "agent" to "entity" = to
at least be consistent with =
prior usage in the document.  But also refer =
back
to the issue listed above =
about use of the term "external =
entity".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 14, Section 4, 1st = paragraph, 1st sentence: delete the = comma.
 
Page 18, Section 6.1, 2nd =
sentence: append a comma after "preference".  =
Change
"multicasted" to =
"multicast" (the preferred form of the =
word).
 
Page 18, Section 7.2.1, last =
sentence: change "encap" to "encapsulation". =

Change "decap" to =
"decapsulation".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 21, Section 7.2.6, 2nd = sentence: delete the comma.
 
Page 21, Section 7.2.6, 5th =
sentence: change "Lets" to =
"Let's".
 
Page 23, Section 8, 2nd =
sentence: delete the comma.
 
Page 24, Section 11, 1st =
sentence: append a comma after "co-chair".  Change =
the
first occurrence of =
"on" to "for".
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Page 24, Section 11, 2nd = sentence: append a comma after "Hares".  Yeah, yeah, = I
know, no one is going to =
require the Oxford comma here to figure out what =
the
sentence means. =
;-)
 
<= pre style=3D'margin-bottom:7.5pt;background:white'>Thanks<= pre style=3D'margin-bottom:7.5pt;background:white'>Nitin ------=_NextPart_001_0429_01D3CCC3.D21E3380-- ------=_NextPart_000_0428_01D3CCC3.D21E3380 Content-Type: text/plain; name="Untitled attachment 00620.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Untitled attachment 00620.txt" _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_0428_01D3CCC3.D21E3380-- From nobody Thu Apr 5 07:05:17 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01587129C6B; Thu, 5 Apr 2018 07:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 he-rU4Sukoro; Thu, 5 Apr 2018 07:05:14 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 70FBF127599; Thu, 5 Apr 2018 07:05:14 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Suresh Krishnan'" , "'The IESG'" Cc: , , References: <152290489812.25948.2495908999143424774.idtracker@ietfa.amsl.com> In-Reply-To: <152290489812.25948.2495908999143424774.idtracker@ietfa.amsl.com> Date: Thu, 5 Apr 2018 10:05:10 -0400 Message-ID: <045701d3cce7$1c8bec00$55a3c400$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGzXOuogYIVg/6+qC65IQQLrrWnfqQzEdVA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 14:05:16 -0000 Suresh: Thank you for catching these errors. See my comments below. Summary: Section 2.3 (good catch). Section 4 and 6 - I think the document represents the WG consensus. I will review the emails, WG documents, and contact previous chairs. Susan Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Suresh Krishnan Sent: Thursday, April 5, 2018 1:08 AM To: The IESG Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; shares@ndzh.com; draft-ietf-i2rs-rib-info-model@ietf.org Subject: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 2.3. Regarding the OSPF route for 2001:DB8::1/32 Did you mean 2001:DB8::1/128 for the host route? If not, this example is wrong since 2001:DB8::1/32 expands to 2001:DB8:0000:0000:0000:0000:0000:1/32 -> 2001:DB8::/32 as the route Sue: Yes - this is an error. * Figure 4. Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into nexthop processing just like the derived nexthops do? Suresh - I need to check the email list archives and get back to you on this point. My recollection was that there was a case where things people did not want to automatically loop this back. However, I cannot bring the discussion of 3.5 years ago to mind. I will take this as an action item as a reviewer to try to recreate the discussion. Thank you for mentioning this point. It is important to clarify in either case. * Section 6 I would have expected the match type to have some indication about whether it requires an exact match or LPM (e.g. A MAC route uses an exact match but an IPv6 route uses LPM). Has the WG discussed this? The short answer is yes, extensive in early interims, list discussions and in session. Can you provide more depth to your questions. For the early discussions, I may need to query Alia Atlas and Jeff Haas (previous chairs) to get the institutional memory on this topic. (One of the reason I really want to have this document discussed with Alia Atlas as AD0. _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Apr 5 07:05:48 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3CC129C6B; Thu, 5 Apr 2018 07:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTmH-OAt7y7C; Thu, 5 Apr 2018 07:05:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 290B6127599; Thu, 5 Apr 2018 07:05:44 -0700 (PDT) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id C2CD11AE047B; Thu, 5 Apr 2018 16:05:41 +0200 (CEST) Date: Thu, 05 Apr 2018 16:05:41 +0200 (CEST) Message-Id: <20180405.160541.2135154939537620152.mbj@tail-f.com> To: shares@ndzh.com Cc: suresh@kaloom.com, iesg@ietf.org, i2rs@ietf.org, draft-ietf-i2rs-rib-data-model@ietf.org, i2rs-chairs@ietf.org From: Martin Bjorklund In-Reply-To: <041501d3cce4$c7e59cc0$57b0d640$@ndzh.com> References: <152281674476.24011.1275548255371559292.idtracker@ietfa.amsl.com> <041501d3cce4$c7e59cc0$57b0d640$@ndzh.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 14:05:46 -0000 Hi, There are standard types for IPv6 flow label and for MAC addresses defined in RFC 6991: inet:ipv6-flow-label yang:mac-address /martin "Susan Hares" wrote: > Suresh: > > Thank you for catching these issues. I missed these as a Shepherd (as did > the other reviewers) and AD. See my answers below. > > Would you or Martin hold a discuss until these critical issues are resolved > and checked with the YANG doctors? I will work with the authors to resolve > these issues. This revision will take some time as we seek advice from the > YANG doctors and from the community on the IEEE MAC Address being an index > or a full MAC Address. > > Susan Hares > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Suresh Krishnan > Sent: Wednesday, April 4, 2018 12:39 AM > To: The IESG > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; > i2rs-chairs@ietf.org; shares@ndzh.com > Subject: [i2rs] Suresh Krishnan's Discuss on > draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) > > Suresh Krishnan has entered the following ballot position for > draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This model tries to squeeze the 20 bit IPv6 flow label into a 16 bit field. > This will result in a loss of data and needs to be fixed before the document > is published. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Section 3 > > => Under > > identity ipv6-decapsulation { > > it looks like the description is wrong ("IPv4 tunnel decapsulation.") > ---- > You are correct. It will be replaced with the following > ========= > identity ipv6-decapsulation { > base "tunnel-decapsulation-action"; > description > "IPv6 tunnel decapsulation."; > } > > => What use case is the ttl-action decrease-and-copy-to-inner used for? > ---- > Good catch! > This feature may be used for tunnels (7.2.1 of > draft-ietf-i2rs-rib-info-model) or nexthops chains (section 7.2.5 of > draft-ietf-i2rs-rib-info-model). Good catch in that it does not provide > enough detail in this version. > > We've had comments over the last years to put this level of detail in or out > of the YANG model. I believe the latest wisdom from NETMOD/NETCONF is to > put the level of detail back in > > => Under case egress-interface-mac-nexthop { > > It is not clear to me how you fit a MAC address into a 32 bit space ,or am I > misreading this somehow and this is some form of index? > > Good Catch. > > Early on it was a holding place for a the official IEEE:MAC table, and > should have been transferred to either the IEEE:MAC-ADDRESS (see page 17 > RIB-INFO draft). However, this definitely needs to get fixed. I need to > check with the YANG Doctors to determine which is the preferred fix for this > reference at this time. I'm sure implementers have been using a fully > qualified IEEE_MAC_ADDRESS or a reference to the Table. > > High level - case points to an outgoing interface, ieee-mac address - > > case egress-interface-mac-nexthop { > container egress-interface-mac-address { > leaf outgoing-interface { > type if:interface-ref; > mandatory true; > description > "Name of the outgoing interface."; > } > leaf ieee-mac-address { > type uint32; > mandatory true; > description > "The nexthop points to an interface with > a specific mac-address."; > } > description > "The egress interface must be an Ethernet > interface. Address resolution is not required > for this nexthop."; > } > } > > It is not clear to me how you fit a MAC address into a 32 bit space ,or am I > misreading this somehow and this is some form of index? > > " leaf ieee-mac-address { > type uint32;" > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Thu Apr 5 07:07:59 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE7F129C6B; Thu, 5 Apr 2018 07:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 AwNPGxXAXRxl; Thu, 5 Apr 2018 07:07:56 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C0E34127599; Thu, 5 Apr 2018 07:07:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Martin Bjorklund'" Cc: , , , , References: <152281674476.24011.1275548255371559292.idtracker@ietfa.amsl.com> <041501d3cce4$c7e59cc0$57b0d640$@ndzh.com> <20180405.160541.2135154939537620152.mbj@tail-f.com> In-Reply-To: <20180405.160541.2135154939537620152.mbj@tail-f.com> Date: Thu, 5 Apr 2018 10:07:40 -0400 Message-ID: <045901d3cce7$75cf54f0$616dfed0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIbu6ObnXRG2bdWXfOwGLqUvIyZiwGWJiuxARvLgjmjTMemoA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 14:07:58 -0000 Martin: Thank you for the proactive response on the types. I'll work with the authors to change to these standard types. Sue -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Thursday, April 5, 2018 10:06 AM To: shares@ndzh.com Cc: suresh@kaloom.com; iesg@ietf.org; i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) Hi, There are standard types for IPv6 flow label and for MAC addresses defined in RFC 6991: inet:ipv6-flow-label yang:mac-address /martin "Susan Hares" wrote: > Suresh: > > Thank you for catching these issues. I missed these as a Shepherd (as did > the other reviewers) and AD. See my answers below. > > Would you or Martin hold a discuss until these critical issues are > resolved and checked with the YANG doctors? I will work with the authors to resolve > these issues. This revision will take some time as we seek advice from the > YANG doctors and from the community on the IEEE MAC Address being an > index or a full MAC Address. > > Susan Hares > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Suresh Krishnan > Sent: Wednesday, April 4, 2018 12:39 AM > To: The IESG > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; > i2rs-chairs@ietf.org; shares@ndzh.com > Subject: [i2rs] Suresh Krishnan's Discuss on > draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) > > Suresh Krishnan has entered the following ballot position for > draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This model tries to squeeze the 20 bit IPv6 flow label into a 16 bit field. > This will result in a loss of data and needs to be fixed before the > document is published. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Section 3 > > => Under > > identity ipv6-decapsulation { > > it looks like the description is wrong ("IPv4 tunnel decapsulation.") > ---- > You are correct. It will be replaced with the following ========= > identity ipv6-decapsulation { > base "tunnel-decapsulation-action"; > description > "IPv6 tunnel decapsulation."; > } > > => What use case is the ttl-action decrease-and-copy-to-inner used for? > ---- > Good catch! > This feature may be used for tunnels (7.2.1 of > draft-ietf-i2rs-rib-info-model) or nexthops chains (section 7.2.5 of > draft-ietf-i2rs-rib-info-model). Good catch in that it does not provide > enough detail in this version. > > We've had comments over the last years to put this level of detail in > or out of the YANG model. I believe the latest wisdom from > NETMOD/NETCONF is to put the level of detail back in > > => Under case egress-interface-mac-nexthop { > > It is not clear to me how you fit a MAC address into a 32 bit space ,or am I > misreading this somehow and this is some form of index? > > Good Catch. > > Early on it was a holding place for a the official IEEE:MAC table, and > should have been transferred to either the IEEE:MAC-ADDRESS (see page > 17 RIB-INFO draft). However, this definitely needs to get fixed. I > need to check with the YANG Doctors to determine which is the > preferred fix for this reference at this time. I'm sure implementers > have been using a fully qualified IEEE_MAC_ADDRESS or a reference to the Table. > > High level - case points to an outgoing interface, ieee-mac address - > > case egress-interface-mac-nexthop { > container egress-interface-mac-address { > leaf outgoing-interface { > type if:interface-ref; > mandatory true; > description > "Name of the outgoing interface."; > } > leaf ieee-mac-address { > type uint32; > mandatory true; > description > "The nexthop points to an interface with > a specific mac-address."; > } > description > "The egress interface must be an Ethernet > interface. Address resolution is not required > for this nexthop."; > } > } > > It is not clear to me how you fit a MAC address into a 32 bit space > ,or am I misreading this somehow and this is some form of index? > > " leaf ieee-mac-address { > type uint32;" > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Thu Apr 5 07:14:32 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F0712D889; Thu, 5 Apr 2018 07:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 i4D-FUcG-H9D; Thu, 5 Apr 2018 07:14:24 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 9A3E812D885; Thu, 5 Apr 2018 07:14:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Adam Roach'" , "'The IESG'" Cc: , , References: <152290316167.25799.2600141637113757077.idtracker@ietfa.amsl.com> In-Reply-To: <152290316167.25799.2600141637113757077.idtracker@ietfa.amsl.com> Date: Thu, 5 Apr 2018 10:14:20 -0400 Message-ID: <046701d3cce8$64af37c0$2e0da740$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK6Pq0YRtjuCJbD8BvvQ0vqXuT+mKIlUeTQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Adam Roach's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 14:14:25 -0000 Adam: Good catch. If you see any others, please let me know. This initially = was a "hack" to provide references. We'll go with the yang:mac-address = for the MAC Address. =20 I will also ask the RTG-DIR whether we should make this an index into = the actual MACS. I do not think that is appropriate, but it is worth a = question to the RTG-DIR and OPS-DIR.=20 We will move this references to the standard references that Martin = mentioned in his email.=20 inet:ipv6-flow-label yang:mac-address I really appreciate all the new reviews on this draft. Due to the = history on this draft, please mention any questionable references you = might have notice. I will track them down.=20 Susan Hares=20 -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Thursday, April 5, 2018 12:39 AM To: The IESG Cc: draft-ietf-i2rs-rib-data-model@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Adam Roach's No Objection on draft-ietf-i2rs-rib-data-model-10: = (with COMMENT) Adam Roach has entered the following ballot position for draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is similar enough to Suresh's DISCUSS that I don't see the point in = making it a DISCUSS also (which it would be otherwise). I'll let him = make sure field size issues are taken care of. > case mac-route { > description > "MAC route case."; > leaf mac-address { > type uint32 ; > mandatory true; > description > "The MAC address used for matching."; > } > } The intention here is to use IEEE EUI-48 and/or EUI-64 identifiers here, = right? These don't fit into a uint32. This problem arises elsewhere in the module; e.g.: > leaf ieee-mac-address { > type uint32; > mandatory true; > description > "The nexthop points to an interface with > a specific mac-address."; > } =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =C2=A72.6: > Nexthops can be fully resolved or an unresolved. Nit: remove "an" -------------------------------------------------------------------------= -- =C2=A73: > import ietf-interfaces { > prefix if; > reference "RFC 7223"; > } > > import ietf-yang-types { > prefix yang; > reference "RFC 6991"; > } The indenting of the "reference" fields seems odd. > identity ipv6-decapsulation { > base "tunnel-decapsulation-action"; > description > "IPv4 tunnel decapsulation."; > } The description here appears to be incorrect (should say "IPv6") > identity decrease-and-copy-to-next { > base "ttl-action"; > description > "Decrease TTL by one and copy the TTL > to the next header.For example: when > MPLS label swapping, decrease the TTL > of the inner label and copy it to the > outer label."; > } Nit: insert a space before "For". > identity resolved { > base "nexthop-state"; > description > "Reolved nexthop state."; > } Nit: "Resolved" rather than "Reolved." > typedef nexthop-lb-weight-definition { > type uint8 { > range "1..99"; > } > description > "Nexthop-lb-weight is used for load-balancing. > Each list member MUST be assigned a weight > between 1 and 99. The weight determines the > proportion of traffic to be sent over a nexthop > used for forwarding as a ratio of the weight of > this nexthop divided by the weights of all the > nexthops of this route that are used for forwarding. > To perform equal load-balancing, one MAY specify > a weight of 0 for all the member nexthops. The > value 0 is reserved for equal load-balancing > and if applied, MUST be applied to all member nexthops."; } To match the text (which allows 0 as a special case), the range needs to = be updated to be "0..99" rather than "1..99" > leaf hop-limit { > type uint8; > description > "The hop limit the header."; > } Nit: "The hop limit of the header." > choice nvgre-type { > description > "NvGRE can use eigher IPv4 > or IPv6 header for encapsulation."; Nit: "either" > leaf flow-id { > type uint16; > description > "The flow identifier of the NvGRE header."; > } Why is this a uint16 rather than a uint8? From nobody Thu Apr 5 07:30:58 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C3D12D94E; Thu, 5 Apr 2018 07:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] 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 uoZ9yH-4Upvs; Thu, 5 Apr 2018 07:30:43 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 F302C12D94A; Thu, 5 Apr 2018 07:30:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: Cc: , "'The IESG'" , , Date: Thu, 5 Apr 2018 10:30:17 -0400 Message-ID: <048601d3ccea$9f108570$dd319050$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0487_01D3CCC9.17FFF6E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdPM6cLt/ut98NjJRSGC13rjZOJEJw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Warren Kumari's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 14:30:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0487_01D3CCC9.17FFF6E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Warren: I cannot find your original text - so I hope this email finds you quickly. As the shepherd reviewer, I'll encourage the authors to fix the nits. Thank you. Do you want re-review any of issues before publication? Susan Hares -------------- On the large question, see below. I do have a large question, a comment, and a bunch of nits: 1: Question: o NEXTHOP_LB_WEIGHT: This is used for load-balancing. Each list member MUST be assigned a weight between 1 and 99. The weight determines the proportion of traffic to be sent over a nexthop used for forwarding as a ratio of the weight of this nexthop divided by the weights of all the nexthops of this route that are used for forwarding. To perform equal load-balancing, one MAY specify a weight of "0" for all the member nexthops. The value "0" is reserved for equal load-balancing and if applied, MUST be applied to all member nexthops. I'm confused what makes 0 special -- if I have e.g 17 links and I assign a weight of e.g 42 to each of them I'll still get equal load-balancing, yes? Why is 0 reserved? I get that having one link with a weigh of e.g 12 and another link with a weight of 0 that would cause issues, but perhaps 0 should simply be unusable? I a: really don't understand and b: thing the document should have some text answering this. Sue: I agree the document should have text that resolves discusses why zero is unique. My recollection of 3 years ago - is that that "0" was utilized by many RIB functions as a unique case. In order to ease gluing this to the current operational RIBS, the "zero" value was deemed as reserved. In doing the text update, I will go back to past chairs (Alia Atlas and Jeff Haas) to get context. Or you can send Alia an Email. [Sigh - this would have been easier in March]. 2: Comment: Section 7.1. Using route preference The entire "Route preference can also be used..." paragraph, while true, feels very out of place. I'd suggest jsut removing it. I'll review this with the authors and send proposed text. This paragraph was suggested to be insert in some past reviews. [Sigh] ------=_NextPart_000_0487_01D3CCC9.17FFF6E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Warren:

 

I cannot = find your original text – so I hope this email finds you = quickly. 

 

As the = shepherd reviewer, I’ll encourage the authors to fix the = nits.  Thank you.  Do you want re-review any of issues before = publication?

 

Susan Hares

--------------

 

On the large = question, see below.

 

I do = have a large question, a comment,  and a bunch of = nits:

1: = Question:

o  = NEXTHOP_LB_WEIGHT: This is used for load-balancing.  Each = list

      member MUST be assigned = a weight between 1 and 99.  The weight

      determines the = proportion of traffic to be sent over a nexthop

      used for forwarding as = a ratio of the weight of this nexthop

      divided by the weights = of all the nexthops of this route that are

      used for = forwarding.  To perform equal load-balancing, one = MAY

      specify a weight of = "0" for all the member nexthops.  The = value

      "0" is = reserved for equal load-balancing and if applied, MUST = be

      applied to all member = nexthops.

 

I'm = confused what makes 0 special -- if I have e.g 17 links and I assign a = weight of e.g 42 to each of them I'll still get equal load-balancing, = yes?

 

Why is = 0 reserved? I get that having one link with a weigh of e.g 12 and = another link with a weight of 0 that would cause issues, but perhaps 0 = should simply be unusable?

I a: = really don't understand and b: thing the document should have some text = answering this.

 

Sue: I = agree the document should have text that resolves discusses why zero is = unique. 

 

My = recollection of 3 years ago – is that that “0” was = utilized by many RIB functions as a unique case.  In order to ease = gluing this to the current operational RIBS, the “zero” = value was deemed as reserved. In doing the text update, I will go back = to past chairs (Alia Atlas and Jeff Haas) to get context.  Or you = can send Alia an Email.

[Sigh = – this would have been easier in March].

 

2: = Comment: Section 7.1.  Using route = preference

The = entire "Route preference can also be used..." paragraph, while = true, feels very out of place. I'd suggest jsut removing it. =

 

I’ll review this with the authors and send  = proposed text.   This paragraph was suggested to be insert in = some past reviews.  [Sigh]

 

------=_NextPart_000_0487_01D3CCC9.17FFF6E0-- From nobody Thu Apr 5 08:12:52 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47886129C70; Thu, 5 Apr 2018 08:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 eg3NSYjMEyip; Thu, 5 Apr 2018 08:12:48 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 D2F09127698; Thu, 5 Apr 2018 08:12:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Ignas Bagdonas'" , , Cc: , , , , "'The IESG'" References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <01c701d3cc26$09865b20$1c931160$@ndzh.com> <02d001d3cc61$768db9d0$63a92d70$@ndzh.com> In-Reply-To: <02d001d3cc61$768db9d0$63a92d70$@ndzh.com> Date: Thu, 5 Apr 2018 11:12:40 -0400 Message-ID: <04bb01d3ccf0$8a9e64d0$9fdb2e70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrfpTnkeJxdov8ELnNq0f+qOuaSgCz2sVuAohvGooB77/MfwGGdu5JAhwv8qijfGZxwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 15:12:51 -0000 Ignas and Warren: Your comments on the IESG telechat (4/5/2018) have two components:=20 1) a DISCUSS based on direct comparison of the I2RS models (dynamic and = configuration) with the TE models (configuration only), 2) "This will = not work". I need clarity to guide the WG/authors to a successful = resolution of your DISCUSS/Abstain.=20 1) a DISCUSS based on direct comparison of the I2RS models (dynamic and = configuration) with the TE models (configuration only).=20 The I2RS models are both available for the dynamic and configuration = datastore. The dynamic configuration models are for models that do not = exactly align with perceptions of the configuration model. These set = of models are for situations that do not align with the configuration = store only. =20 As Martin indicated, trying these alternate management Yang models in = dynamic/configuration model configuration needs feedback based on = deployment and interoperability issues.=20 This does not align with RFC8342 (NMDA) or and I2RS requirement = documents (RFC8242). If this is your DISCUSS Criteria, then I have a = strong objection to your DISCUSS based on these RFCs.=20 If the Discuss/Abstain is based on one of the following discuss = criteria, please state this clear in your emails so I can guide the = authors and the WG.=20 1) The protocol has technical flaws that will prevent it from working = properly, or the description is unclear in such a way that the reader = cannot understand it without ambiguity. 2) Widespread deployment would be damaging to the Internet or an = enterprise network for reasons of congestion control, scalability, or = the like. These are objections I take seriously as a shepherd/WG chair. However, = I need you both to disambiguate between these two components. I have = been trying to get clarity on which DISCUSS criteria Ignas' comments = indicate.=20 I expect an IESG members to be able to inform a WG chair which the = discuss criteria you are specifying. Please let me know if you have = additional questions. Your comments on the telechat did not indicate = you understood my concerns.=20 Cheerily, Susan Hares -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Wednesday, April 4, 2018 6:08 PM To: 'Ignas Bagdonas'; 'The IESG' Cc: i2rs@ietf.org; = draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; = i2rs-chairs@ietf.org Subject: RE: [i2rs] Ignas Bagdonas' Discuss on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = COMMENT) Ignas: I'm not saying yes/no to change this model. I've forwarded Yan's = comments regarding changes to your specific issues. Yan is very = proactive. It is likely that she will change most of the details if you = respond to her. I am acting as a shepherd/WG chair. I'm trying to determine Discuss = Criteria are you using from the following document are you using to = restrict I2RS models (dynamic + configuration capable) because there are = TE specific models in the same area: https://www.ietf.org/blog/discuss-criteria-iesg-review/ This goes against the design criteria I2RS has used. You asked for text sequences that lead me to this conclusion: (1st thread): [Ignas] > Excellent. Please get feedback from user community - even if = it is not yet implemented and operations groups will not be able to = provide feedback, architecture and engineering groups look into upcoming = things and will have what to say. [Sue]: (Repeating earlier comments from email and shepherd's ) We = obtain a vendor (Huawei) and a target deployment situation (Data = Centers) with two potential data centers in China who wanted to work = with this type of logical=20 deployment. To this shepherd's eyes, this is the operational = information. [Sue] (new clarifying comments): If you are still objecting, what else = do you want as proof that the WG did due diligence on obtaining the = operational feedback for deployment of a model which has I2RS = capabilities (dynamic and configuration) must be judged against any TE (configuration only ) data = models. (2) Further indication that you are comparing I2RS data models against = the 4 TE models without a consideration to dynamic datastore design = issues: [Sue's comment]: 3rd - How many of the user community have implemented = I2RS dynamic models or the RFC version of the TE models? [Ignas] I am aware of 1 I2RS model family implementation. I am aware of = 4 TE model implementations that I happen to use daily, and aware of = several more that I do not deal with. And I am not certain what value = such counting of implementations brings to this discussion. Summary of my question: I2RS models (configuration and dynamic) are different than regular TE = models and you are lumping the I2RS models in with the configuration = datastore TE models. Please provide me with the DISCUSS criteria or = RFCs you are using to make categorization. After we settle on these issues, we can go on to the other comments. Sue Hares -----Original Message----- From: Ignas Bagdonas [mailto:ibagdona@gmail.com] Sent: Wednesday, April 4, 2018 2:40 PM To: Susan Hares; 'The IESG' Cc: i2rs@ietf.org; = draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; i2rs-chairs@ietf.org Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) On 04/04/2018 16:03, Susan Hares wrote: > Ignas: > > I am not trying to clarify the specifics. This response (as I=20 > mentioned), will come from the authors. As a shepherd/WG chair, I am=20 > asking for information regarding the basis of your DISCUSS models for=20 > specific points. > > The 2014 document on the IESG discuss criteria is at: > https://www.ietf.org/blog/discuss-criteria-iesg-review/ > > What on this list does the following comment refer to: > "Why DISCUSS? DC fabric is a type of network topology, yes, it has=20 > some specifics, but nothing radically different than any purpose built = > network topology. Developing a separate model for a specific use case=20 > at the same time when there is generic and extensible TE model is = questionable." The fact that for managing similar functionality there appears to be a = need for different models that would as a result require different model = lifecycle management clearly falls into the category of operational = issues. > Perhaps you are not considering the fact this is an I2RS model. Let=20 > me provide 3 comments regaring that point: I am considering the fact that this model defines configuration of = something that is widely deployed in a way that is not compatible with = how it is deployed. The fact that this may be I2RS model is not of the = primary importance. > > 1st - I2RS is focusing on models that are capable for the dynamic=20 > state and configuration state. These models have qualitative=20 > differences. The mechanisms of a model which does both dynamic state=20 > and configuration state is qualitative different that the basic TE = models. This model > extends the TE models toward this approach (see module=20 > ietf-dc-fabric-topology reference import of ietf-network-topology). > > 2nd - During the I2RS process we talked to the TE topology authors and = > the TE WG. We agreed that this model has differences. As a WG=20 > Co-chair, I spent time reviewing this interaction. > > 3rd - How many of the user community have implemented I2RS dynamic=20 > models or the RFC version of the TE models? I am aware of 1 I2RS model family implementation. I am aware of 4 TE = model implementations that I happen to use daily, and aware of several = more that I do not deal with. And I am not certain what value such = counting of implementations brings to this discussion. > See the comments from Chris Hopps and others on slow pace of the=20 > netconf work. If you are going to restrict to two deployed=20 > implementations, you will be joining the IDR camp of requirements and = slowing the work further. > The only reason we require 2 implementations for IDR is for the=20 > fragile BGP environment and that operators request it due to the=20 > global consequences. Network Management of these early yang models=20 > have a much more restricted case. May I ask you to point to where I have said anything about two deployed = implementations? Ignas > Sue Hares > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ignas Bagdonas > Sent: Wednesday, April 4, 2018 10:31 AM > To: Susan Hares; 'The IESG' > Cc: i2rs@ietf.org;=20 > draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org;=20 > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ignas Bagdonas' Discuss on=20 > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and=20 > COMMENT) > > Hi Sue, > > > On 03/04/2018 14:59, Susan Hares wrote: >> Ignas: >> >> Yan will answer for the authors but I would like to share some=20 >> information related to the I2RS working group reviews. In your = response,=20 >> please specify why each question is a "DISCUSS" quality question = rather=20 >> than a "Comment" question. The authors and I (as the shepherd) will = work=20 >> to resolve both DISCUSS and comment issues. >> >> Let me review only 5 of your many points because they are pointing in = a=20 >> direction which is different from earlier QA reviews of this document = >> (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 timeframe. >> 1st - Why TE topology model is not sufficient for modelling the=20 >> representation of DC fabric? Why is DC fabric network topology = special=20 >> compared to any generic fabric based topology? > Why DISCUSS? DC fabric is a type of network topology, yes, it has some = > specifics, but nothing radically different than any purpose built = network=20 > topology. Developing a separate model for a specific use case at the = same=20 > time when there is generic and extensible TE model is questionable. > >> This document was reviewed by authors with the TE topology models to = make=20 >> sure there was no conflict or duplication. >> >> Your question implies that only one yang model is appropriate for = each=20 >> type of fabric. > That is exactly opposite. What is special about DC fabric that it has = to=20 > have a separate model? What is special about fabric type of topology = that=20 > it has to have a separate model? Why is TE model not suitable? > >> This theory of one yang mode per fabric does not apply to = dynamic=20 >> (ephemeral) datastore versus configuration datastore models. It is = also=20 >> not true of all models even within the configuration datastore. >> Since there is a yang catalog and selection of yang models is = specific to=20 >> a implemented, there has been no early winnowing of the yang models = per=20 >> type. If you are insisting on this theory of "one yang model" per = fabric=20 >> type, please provide an RFC reference so that I can help review this=20 >> DISCUSS criteria with the authors. >> >> This yang model has been implemented by 1 vendor, and there was = interest=20 >> by other vendors. A deployment target has been identified for this=20 >> model, and feedback is expected from the users. > Excellent. Please get feedback from user community - even if it is not = yet=20 > implemented and operations groups will not be able to provide = feedback,=20 > architecture and engineering groups look into upcoming things and will = > have what to say. > > Speaking of implementations, the ODL faas project (from where the = majority=20 > of this model seems to be coming from) deals with an instance of = overlay=20 > that is subsequently treated as an underlay, and that is different = that=20 > the underlay on top of which that instance is being run. > If the model focus is on the "fabric as a service" type of topologies = then=20 > it explicitly needs to state that, and then justify why physical node=20 > properties exist together with logical instance properties in that = case. > > >> If you are asking this model to cover three-four layer datacenters, = this=20 >> approach is opposite some of the initial feedback to the group to = keep=20 >> the initial model - that is to keep it simple and restricted to 2 = layers=20 >> in order to test the concepts. If you are asking to provide text (in = >> introduction or appendix) that indicates the initial focus, this can = be=20 >> added. > The document as it is written now tries to cover every possible = fabric. > If the scope is intended to be narrower - it needs to be stated. > Starting from bounded scope is certainly a right thing to do but that = is=20 > not how the document reads now. > > >> 2nd - Multiple layers and multiple roles. > Why DISCUSS? Two stage fabrics and fabrics with a perfectly clean node > role separation do indeed exist, but that is not necessary a common > deployment model. The document assumes that those are the only = possible > options. > >> The authors provide slides in several meetings I2RS meeting = repository=20 >> regarding this point. >> The initial feedback suggested reducing the "why" text within the = draft.=20 >> Again, the initial feedback was to reduce the initial model's text to = 2=20 >> layers and simple "whys". See proceedings from IETF 95 forward on = I2RS=20 >> on fabric data model for discussions. > Would users of this model also be required to lookup proceedings of = past > IETF meetings in order to understand whether it may fit their use = cases? > > >> 3rd - The authors will comment on the port restrictions. Early = feedback=20 >> during the I2RS meetings from vendors may have taken the authors down = >> this path. In my review, I expect major issues in this area - but I = will=20 >> let the authors comment. > Why DISCUSS? The way how the model specifies port speeds is = conflicting > with common deployment practices. > >> 4 - policy is simple. >> >> Again, the initial feedback was to keep initial policies simple and = gain=20 >> feedback from the deployments. > Why DISCUSS? What kind of policy is being discussed here? The = assumption > of one single universal policy fitting all deployments and use cases > contradicts to operational reality. > > "Policy is simple" does not clarify what kind of policy it is. > >> 5 - You indicate that the document requires a "major" rewrite = clarifying=20 >> the logic. > Why DISCUSS? Model tries to prescribe a way how all DC networks should > be built. It intermixes concepts of underlay and overlay. There are > nodes in the model with unclear purpose and no documented details on > what and how they are doing. > >> Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested=20 >> taking out the lengthy descriptions regarding logic and history. If = we=20 >> are switching the rules for the YANG models, would you please update = the=20 >> requirements for the YANG models so that shepherds, rtg-dir, ops-dir, = and=20 >> yang-doctors can have rules for review clearly spelled out. > YANG models, and any other deliverables of the IETF, are targetted to > the users of those deliverables and not necessary to the IETF itself. > The situation with YANG models is that the main consumer of IETF YANG > model for a noticeable period was IETF itself - it was required to > build the sufficient coverage of models for them to be practically > useful. We as an industry start to see more practical use of YANG > modules, and so far the main obstacle for YANG acceptance is the > difficulty in trying to use it. It is incorrect to assume that outside > of the IETF WGs that deal with developing the models there is enough = of > understanding of the reasoning behind modelling decisions made. It is > incorrect to assume that potential users of such models would try to > lookup proceedings of past IETF meeting trying to get answers - they > will chose other manageability technologies instead. YANG models need = to > be self-contained from the practical usability perspective - the = models > themselves should contain enough and meaningful descriptions of the > nodes that it would not raise questions for users trying to deploy = those > models. Descriptions equivalent to those found in command line > interfaces - if YANG is expected to become a new command line = interface, > it should be no worse than the command line interface. The reasoning > behind modelling decisions made also need to be documented - at least > for allowing model users to see whether the model is suitable for > deployment in the particular environment. As YANG is maturing and > starting to be deployed, naturally the focus of reviews will change to > reflect what is required for successful deployment of the technology. > >> Summary on Shepherd's comment: >> >> The authors will respond to others specifics, but in order to guide = these=20 >> diligent authors - I need to know what rules you are setting for the = 2018=20 >> IESG approval of YANG models. If you are placing a DISCUSS on a YANG = >> model based on a set criteria, the criteria needs to be published on = a=20 >> web page or in an RFC. If I've missed this criteria that the OPS Area = has=20 >> specified, > RFC6087 and draft-ietf-netmod-rfc6087bis. > > There are two parts that are important for reviews - the model itself, > and how the model applies to the managed entities. And there is = nothing > new in the review criteria. The former is rather not that complex, and > typically can be done within IETF itself. The latter is more complex = and > generally would require feedback from the target users of the model. > There is a balance between a model being too generic to be practically > usable and model being too prescriptive to be practically usable. If = the > model puts requirements and restrictions on the managed entities in a > way that requires to build those managed entities in a specific way, > predefined by the model authors, the value of such model is > questionable. Speaking specifically about DC fabric model, it puts > network design prescriptions that are significantly misaligned with = how > fabric based networks have been and are built. Yes, it is possible to > find environments where the model would apply directly and with no > impact, but one would need to look for such deployments quite hard, = and > with a high probability that would be proof of concept or technology > demonstration type of environments. > > IETF is good at developing technology components and fragments, IETF > typically is not good at dealing with network design and how those > fragments need to be bound together - that is the reality, and that is > not necessarily wrong. IETF should be focusing on what it can do best = - > the fragments, and align with users of the fragments on how to improve > the fragments but not try to direct how users should be building their > networks. It is important for the reputation of IETF as a credible SDO = - > if IETF manageability mechanisms propose and enforce not necessarily > right - or just plain broken - network designs, that is a reputation > problem. This document tends to be proposed standard, and that sets a > strong message. > > Ignas > > >> Thank you for your review, >> Susan Hares >> >> -----Original Message----- >> From: Ignas Bagdonas [mailto:ibagdona@gmail.com] >> Sent: Tuesday, April 3, 2018 7:40 AM >> To: The IESG >> Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan=20 >> Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >> Subject: Ignas Bagdonas' Discuss on=20 >> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = >> COMMENT) >> >> Ignas Bagdonas has entered the following ballot position for >> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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=20 >> 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-i2rs-yang-dc-fabric-network-t= opology/ >> >> >> >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >> >> I have concerns about the practical usability of this proposed model = as=20 >> it is specified now. >> >> The intended decoupling of fabric implementation properties (what is=20 >> termed as "underlay network infrastructure" in the document) and its=20 >> topology seems to be contradicting to general operational practices = of=20 >> fabric based networks. It is generally true for the context of the=20 >> overlay but that is not what the document seems to be focusing on. = Fabric=20 >> defines and implements the underlay, not the other way around. >> >> The document does not contain a sufficient description of the logic = of=20 >> the model itself, the reasons for choices made for representation of=20 >> types and attributes, and at the same time descriptions in modules = are=20 >> single lines that do not add clarification beyond being copies of = leaf=20 >> names. Either there needs to be a section that describes the logic of = the=20 >> model and how it relates to other models, also including examples, or = >> module description fields need to have enough content to be able to = have=20 >> equivalent understanding of model intent and operation. Both are = strongly=20 >> encouraged, as descriptions have value of itself for being a = reference=20 >> for use, and model description is needed for understanding how this=20 >> particular model fits into the larger hierarchy. Network management = does=20 >> not end at the boundary of the single domain-specific model, it is=20 >> important to build it into a whole system. >> >> Why TE topology model is not sufficient for modelling the = representation=20 >> of DC fabric? Why is DC fabric network topology special compared to = any=20 >> generic fabric based topology? >> >> How this model could be used for representing more than two stage = fabrics=20 >> that are in wide deployment? >> >> Limiting port bandwidth to a fixed rate is too restrictive. The model = as=20 >> specified already does not cover a set of port speeds that are in=20 >> deployment. >> >> How would a device that has more than a single role in the fabric be=20 >> represented? >> >> Service capabilities as they are described belong to the overlay = context=20 >> while they are called device capabilities. Are those the only = possible=20 >> service capabilities? What is the effect of configuring those=20 >> capabilities? >> >> What is compose-fabric RPC? The document does not define any RPCs. >> >> What is policy driven traffic behavior? Is there the only one policy = that=20 >> fits all possible deployment scenarios? >> >> Looking at the history of the document from the individual submission = >> time and the comments received, it seems that the point fixes to the = text=20 >> went in to cover the specific comments but not to address the broader = >> scope of comments. >> The document would definitely benefit from a major rewrite clarifying = the=20 >> logic behind the decisions made, aligning more with the operational=20 >> practice of fabric based network design and deployment, and bringing = the=20 >> content in YANG modules to be self-describing. >> >> >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >> >> Fabric and POD are not equivalent terms. >> >> I2RS use case requirements document has expired 11 months ago. Use = cases=20 >> documents are good for tracking the work progress of specification=20 >> documents, it is questionable whether standalone use cases documents=20 >> provide value beyond historic record. Is the reference to I2RS use = cases=20 >> document really needed? >> >> What is atomic network? >> >> VLAN is not a fabric building technology as such, while Ethernet is. >> >> What is the need for VNI capacity leaves? What is their effect if=20 >> configured? >> >> The document intermixes ietf-fabric-* and ietf-dc-fabric-* = namespaces. >> >> Serial port-type is present while Infiniband is not - Infiniband = based=20 >> fabrics are widely deployed. What is the extensibility mechanism for=20 >> adding in new port types? >> >> Is there any deployment experience with this model? The ODL faas = project=20 >> hasn't got much activity over last two years. Are you aware of any = other=20 >> implementations or deployments? >> >> >> > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Thu Apr 5 08:19:16 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B160412DA48 for ; Thu, 5 Apr 2018 08:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 4n_Y7ASbwMz0 for ; Thu, 5 Apr 2018 08:19:12 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 5218312DA41 for ; Thu, 5 Apr 2018 08:19:12 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id m13so29066733wrj.5 for ; Thu, 05 Apr 2018 08:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4VHCiedIMhrLKuS/Rui7wZeqcOAVtpVgMT0b1o+9Q5Y=; b=KwuBSZqHk0KeU2HbnQ64pYcuR6J7RjT6ec+9VU8UnXlhbdEdVih6or0eZU49RQs+jk d1coCiUd8HmsKheVkDyb3D7PHOy169rNbVGOdkNkZBWjYlfYBxX3riMgxX5RSB7+25M1 7Wx+pTv9nCI9Rugm9BoOY0xPfQRvUtqdmVJ2eDPR7fzy8aQ3sTA+Txh2wsXnj5HN/kLh qbfUTduXiQnOZlujKJ1gB9ft5BTVUFF5PKmkP4llIUgQPY0Q5Fi9LKqPEd182eQFKovR 9KbZQ+Mj8PzZnoY1IGbbJ+mFBGa7B4E2/3W0ivK8os5D6k7Ako+Xss2r1u4Ntc9Yqd77 8H4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4VHCiedIMhrLKuS/Rui7wZeqcOAVtpVgMT0b1o+9Q5Y=; b=aS8WRzWYAFS/mVBC6BW8AT6g843VQyibKtBKPkGn1sbnJKedbygsPxwJxvRNjA3qKG SSdOV2YWjc2cpaTXus7PcjN8Idw2v4KKrcqIk6fVohdOxzmKgg7XVsnnNQ6e0fCsupcl yrQfowGy9d3MWt0ZOVXIw/Xn7B5GoFltiDDORm+OYRUwA6It/lTiTv1soeMQeReb13Ys NppMOfQMI8X4m9Cj7FZnd97rIO4vitv+2K2Dm+0+rxGyDK2iR1GoTlITFH3OxqkAJwEg BXrKmzSn2kTx9qMOcixqbDTGva2rDliM3rBvQSuN1KU96jzAxiGjBAYQ7WOWZl3H9gy0 xWXw== X-Gm-Message-State: AElRT7G4NA8SqFSrst7lZ76R82xdCw145nIJDkrn21oUT5e73zpXr/lK 9oym4Yj8Xw28hXysvsbyeDdrIy/fdtarqz0M6FjomQ== X-Google-Smtp-Source: AIpwx49ZWnptNh9cxfIQ2dumbzu9Rbcgcr7rqjjGjPXIOFqXKByRD+bpZxESF5oq3q3gpNTfaQB7jur/pfxBkqymXes= X-Received: by 10.223.170.213 with SMTP id i21mr17372322wrc.10.1522941550125; Thu, 05 Apr 2018 08:19:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.226.76 with HTTP; Thu, 5 Apr 2018 08:18:29 -0700 (PDT) In-Reply-To: <048601d3ccea$9f108570$dd319050$@ndzh.com> References: <048601d3ccea$9f108570$dd319050$@ndzh.com> From: Warren Kumari Date: Thu, 5 Apr 2018 11:18:29 -0400 Message-ID: To: Susan Hares Cc: i2rs@ietf.org, The IESG , i2rs-chairs@ietf.org, draft-ietf-i2rs-rib-info-model@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [i2rs] Warren Kumari's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 15:19:15 -0000 On Thu, Apr 5, 2018 at 10:30 AM, Susan Hares wrote: > Warren: > > > > I cannot find your original text =E2=80=93 so I hope this email finds you= quickly. > > > > As the shepherd reviewer, I=E2=80=99ll encourage the authors to fix the n= its. Thank > you. Do you want re-review any of issues before publication? > > Nah. I mean I'd be interested, but don't bother waiting on me... > > Susan Hares > > -------------- > > > > On the large question, see below. > > > > I do have a large question, a comment, and a bunch of nits: > > 1: Question: > > o NEXTHOP_LB_WEIGHT: This is used for load-balancing. Each list > > member MUST be assigned a weight between 1 and 99. The weight > > determines the proportion of traffic to be sent over a nexthop > > used for forwarding as a ratio of the weight of this nexthop > > divided by the weights of all the nexthops of this route that are > > used for forwarding. To perform equal load-balancing, one MAY > > specify a weight of "0" for all the member nexthops. The value > > "0" is reserved for equal load-balancing and if applied, MUST be > > applied to all member nexthops. > > > > I'm confused what makes 0 special -- if I have e.g 17 links and I assign = a > weight of e.g 42 to each of them I'll still get equal load-balancing, yes= ? > > > > Why is 0 reserved? I get that having one link with a weigh of e.g 12 and > another link with a weight of 0 that would cause issues, but perhaps 0 > should simply be unusable? > > I a: really don't understand and b: thing the document should have some t= ext > answering this. > > > > Sue: I agree the document should have text that resolves discusses why ze= ro > is unique. > > > > My recollection of 3 years ago =E2=80=93 is that that =E2=80=9C0=E2=80=9D= was utilized by many RIB > functions as a unique case. In order to ease gluing this to the current > operational RIBS, the =E2=80=9Czero=E2=80=9D value was deemed as reserved= . In doing the text > update, I will go back to past chairs (Alia Atlas and Jeff Haas) to get > context. Or you can send Alia an Email. > > [Sigh =E2=80=93 this would have been easier in March]. Ok A note of "0 is specially because of historical raisons" or something would also work for me. Mainly I'm interested. > > > > 2: Comment: Section 7.1. Using route preference > > The entire "Route preference can also be used..." paragraph, while true, > feels very out of place. I'd suggest jsut removing it. > > > > I=E2=80=99ll review this with the authors and send proposed text. This= paragraph > was suggested to be insert in some past reviews. [Sigh] While reading the document I stumbled over this text and it distracted me, but I'm fine with it remaining if people prefer... W > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Apr 5 10:53:04 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1659612E038 for ; Thu, 5 Apr 2018 10:53:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 yfK9AZH7o3Iq for ; Thu, 5 Apr 2018 10:52:56 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 0127412DFE0 for ; Thu, 5 Apr 2018 10:52:54 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id g8so7852980wmd.2 for ; Thu, 05 Apr 2018 10:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3kZq8sipbjPhhfMj1qZTc82pNJ8zsnw1haJy4OEfz6o=; b=dIum+6eeLl4dE3CrxnCvJi8lRNvz5vbuEB05hLTy6cOF3Vj2OdFztFZqaLYEP4DLC3 3Zi2BiRLRQkh1/29OvAZ3mkPOdi/fMSa2yX4R+B5dj+e7H3P2gY+d8Yj2EBs1wHY1XuR rP3eWrhhEXiBZqJ3wtQFtmC8psYzc+i0OJ3sFV0uoHiUfezN4eXQ9tzz7sUSfwXRrTG/ /NTeOnR6v/MSTnf4vVYTy6OfUGX1rQP2BGZZsNvry0ZZdSGao+DUdn1GMNtzukRAr8sk R3hqIGNjlklXPKAtn92fB/rQdJLDgjCY4VFtxapeK+JriDIdNeQr4TxTFsBDxylgg3YT IEfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3kZq8sipbjPhhfMj1qZTc82pNJ8zsnw1haJy4OEfz6o=; b=bl79fUvXpyU6X9TkkgYHUSd5J2efTl+b6X+ho/vugunuNkbrWKYBxO2Eiy7NzmA8jz PSzowi+JwsuzADo8en1eX1MeXEgJ1RuEHdQSUs+RdGPV7MPi8w1xFoC/jgUZrHfRd7zz BL6soSXOubwWXZNX19SCYzc3GlAk7t26JEx5USaxGXIDP24hDt9rSNJ+H19C5qgKZSqJ qqhqQVPWWSevDHNAaCyQ5VI/8cjiEnA7m3nB/1q44Q+ve/TXlEtDBW/JP7lJAI/9M8Cw uWfVY93CrfgpJiC+EEOtsfRLzvRZMsaAMH+4kZxBM1ukFsL61gJoWhCWG9+XP65I+hxd AiOg== X-Gm-Message-State: AElRT7F/3euRgB2MOIDZMbFyEBUfZtaqfDlRjrVuys+sr1R1dFRA5imC PM3xgc6Sbl2A0ADRuftyw2VGfaPgsYapqm/UpootI0U3S0c= X-Google-Smtp-Source: AIpwx48BQEBNqO8ovr3mRvT7V2hM1Gb1RaBZDjgziom2f5Wec/W4AX7tYDH5A4Q5ZCOifM9US1ctFUzoJWxL8E7D25M= X-Received: by 10.28.139.18 with SMTP id n18mr10576634wmd.26.1522950772712; Thu, 05 Apr 2018 10:52:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.226.76 with HTTP; Thu, 5 Apr 2018 10:52:11 -0700 (PDT) In-Reply-To: <04bb01d3ccf0$8a9e64d0$9fdb2e70$@ndzh.com> References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <01c701d3cc26$09865b20$1c931160$@ndzh.com> <02d001d3cc61$768db9d0$63a92d70$@ndzh.com> <04bb01d3ccf0$8a9e64d0$9fdb2e70$@ndzh.com> From: Warren Kumari Date: Thu, 5 Apr 2018 13:52:11 -0400 Message-ID: To: Susan Hares Cc: Ignas Bagdonas , martin.vigoureux@nokia.com, i2rs@ietf.org, draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, i2rs-chairs@ietf.org, The IESG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 17:53:01 -0000 On Thu, Apr 5, 2018 at 11:12 AM, Susan Hares wrote: > Ignas and Warren: > > Your comments on the IESG telechat (4/5/2018) have two components: > 1) a DISCUSS based on direct comparison of the I2RS models (dynamic and c= onfiguration) with the TE models (configuration only), 2) "This will not wo= rk". I need clarity to guide the WG/authors to a successful resolution of = your DISCUSS/Abstain. > > 1) a DISCUSS based on direct comparison of the I2RS models (dynamic and c= onfiguration) with the TE models (configuration only). > > The I2RS models are both available for the dynamic and configuration data= store. The dynamic configuration models are for models that do not exactly= align with perceptions of the configuration model. These set of models = are for situations that do not align with the configuration store only. > > As Martin indicated, trying these alternate management Yang models in dy= namic/configuration model configuration needs feedback based on deployment = and interoperability issues. > > This does not align with RFC8342 (NMDA) or and I2RS requirement documents= (RFC8242). If this is your DISCUSS Criteria, then I have a strong objec= tion to your DISCUSS based on these RFCs. > > If the Discuss/Abstain is based on one of the following discuss criteria,= please state this clear in your emails so I can guide the authors and the = WG. > > 1) The protocol has technical flaws that will prevent it from working pro= perly, or the description is unclear in such a way that the reader cannot u= nderstand it without ambiguity. > 2) Widespread deployment would be damaging to the Internet or an enterpri= se network for reasons of congestion control, scalability, or the like. > > These are objections I take seriously as a shepherd/WG chair. However, I= need you both to disambiguate between these two components. I have been = trying to get clarity on which DISCUSS criteria Ignas' comments indicate. > > I expect an IESG members to be able to inform a WG chair which the discus= s criteria you are specifying. I specifically did not ballot DISCUSS as there are no Discuss criteria which I felt applied - Abstain is a non-blocking position (and so practically indistinguishable from No Record, and fairly similar to No Objection). Much of my twitchiness with the document is that it feels like it is trying to define what a datacenter fabric is (in an Introduction and a single term - "Fabric: also known as a POD, is a module of network, compute, storage, and application components that work together to deliver networking services. It represents a repeatable design pattern. Its components maximize the modularity, scalability, and manageability of data centers."). There are a huge number of different data center "fabric" designs, and I don't really think that the document goes into enough detail about what exactly it is meaning when it says fabric. It also asserts: "for a DC network, a fabric can be considered as an atomic structure for management purposes." -- at some level this is probably true, but at the level that I look at fabrics it definitely isn't -- a fabric is a thingie made up of many devices and they all require management and monitoring and care and feeding and love and attention. A lot of the document seems to be written with a specific sets of views and assumptions (yes, it is obviously extensible, but the base selections reflect a certain understanding / world view): the 'fabric-type' can be Vxlan, Vlan or Trill (most fabrics I've seen are plain ethernet), 'port-types' are "Port type: ethernet or serial or others" (I've never seen a serial fabric, and this leaves out InfiniBand), 'traffic-behavior' can be normal or policy-driven (with no description of what the actual difference is, nor what 'policy-driven' means), the 'fabric-options' are not really options I'd expect to be of primary imp= ort, the 'gateway-mode' options of 'centralized' vs 'distributed' don't really align with the descriptions (on spine vs leaf), nor do I understand what that would be critical enough that it is given such priority and things like the base protocol used isn't), the descriptions for things like 'fabrictypes:node-ref' ("The device the fabric includes.") are very unclear. The document / model is at such an unusual level of abstraction (simultaneously very high and low) that I simply don't understand how this could usefully be used -- if I view a "fabric" as simply a commodity thingie that I ride over, and the model is simply informational, then it contains much which is not useful to me, and leaves out things like cross sectional BW / locality hints, etc which would be. If I instead view this as something that I might want to use to administer / monitor / model a fabric then it is way too simplistic. But, again, I think that this is simply that my views / levels of abstraction don't align with whatever the authors / WGs are -- and so I'm not blocking the document, but rather "I oppose this document but understand that others differ and am not going to stand in the way of the others." - there is simply a large gulf between my worldview of what a fabric is (and what levels of abstraction would be useful), and what this document provides. W > Please let me know if you have additional questions. Your comments on t= he telechat did not indicate you understood my concerns. > > Cheerily, Susan Hares > > > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Wednesday, April 4, 2018 6:08 PM > To: 'Ignas Bagdonas'; 'The IESG' > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.o= rg; i2rs-chairs@ietf.org > Subject: RE: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fa= bric-network-topology-08: (with DISCUSS and COMMENT) > > Ignas: > > I'm not saying yes/no to change this model. I've forwarded Yan's comment= s regarding changes to your specific issues. Yan is very proactive. It is= likely that she will change most of the details if you respond to her. > > I am acting as a shepherd/WG chair. I'm trying to determine Discuss Cri= teria are you using from the following document are you using to restrict I= 2RS models (dynamic + configuration capable) because there are TE specific = models in the same area: > https://www.ietf.org/blog/discuss-criteria-iesg-review/ > > This goes against the design criteria I2RS has used. > > You asked for text sequences that lead me to this conclusion: > (1st thread): > [Ignas] > Excellent. Please get feedback from user community - even if i= t is not yet implemented and operations groups will not be able to provide = feedback, architecture and engineering groups look into upcoming things and= will have what to say. > > [Sue]: (Repeating earlier comments from email and shepherd's ) We obtai= n a vendor (Huawei) and a target deployment situation (Data Centers) with t= wo potential data centers in China who wanted to work with this type of log= ical > deployment. To this shepherd's eyes, this is the operational informatio= n. > > [Sue] (new clarifying comments): If you are still objecting, what else do= you want as proof that the WG did due diligence on obtaining the operation= al feedback for deployment of a model which has I2RS capabilities (dynamic = and > configuration) must be judged against any TE (configuration only ) data m= odels. > > (2) Further indication that you are comparing I2RS data models against th= e 4 TE models without a consideration to dynamic datastore design issues: > > [Sue's comment]: 3rd - How many of the user community have implemented I= 2RS dynamic models or the RFC version of the TE models? > > [Ignas] I am aware of 1 I2RS model family implementation. I am aware of 4= TE model implementations that I happen to use daily, and aware of several = more that I do not deal with. And I am not certain what value such counting= of implementations brings to this discussion. > > Summary of my question: > I2RS models (configuration and dynamic) are different than regular TE mod= els and you are lumping the I2RS models in with the configuration datastore= TE models. Please provide me with the DISCUSS criteria or RFCs you are us= ing to make categorization. > > After we settle on these issues, we can go on to the other comments. > > Sue Hares > > -----Original Message----- > From: Ignas Bagdonas [mailto:ibagdona@gmail.com] > Sent: Wednesday, April 4, 2018 2:40 PM > To: Susan Hares; 'The IESG' > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.o= rg; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ignas Bagdonas' Discuss on > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and > COMMENT) > > > > On 04/04/2018 16:03, Susan Hares wrote: >> Ignas: >> >> I am not trying to clarify the specifics. This response (as I >> mentioned), will come from the authors. As a shepherd/WG chair, I am >> asking for information regarding the basis of your DISCUSS models for >> specific points. >> >> The 2014 document on the IESG discuss criteria is at: >> https://www.ietf.org/blog/discuss-criteria-iesg-review/ >> >> What on this list does the following comment refer to: >> "Why DISCUSS? DC fabric is a type of network topology, yes, it has >> some specifics, but nothing radically different than any purpose built >> network topology. Developing a separate model for a specific use case >> at the same time when there is generic and extensible TE model is questi= onable." > The fact that for managing similar functionality there appears to be a ne= ed for different models that would as a result require different model life= cycle management clearly falls into the category of operational issues. > > >> Perhaps you are not considering the fact this is an I2RS model. Let >> me provide 3 comments regaring that point: > I am considering the fact that this model defines configuration of someth= ing that is widely deployed in a way that is not compatible with how it is = deployed. The fact that this may be I2RS model is not of the primary import= ance. > >> >> 1st - I2RS is focusing on models that are capable for the dynamic >> state and configuration state. These models have qualitative >> differences. The mechanisms of a model which does both dynamic state >> and configuration state is qualitative different that the basic TE model= s. This model >> extends the TE models toward this approach (see module >> ietf-dc-fabric-topology reference import of ietf-network-topology). >> >> 2nd - During the I2RS process we talked to the TE topology authors and >> the TE WG. We agreed that this model has differences. As a WG >> Co-chair, I spent time reviewing this interaction. >> >> 3rd - How many of the user community have implemented I2RS dynamic >> models or the RFC version of the TE models? > I am aware of 1 I2RS model family implementation. I am aware of 4 TE mode= l implementations that I happen to use daily, and aware of several more tha= t I do not deal with. And I am not certain what value such counting of impl= ementations brings to this discussion. > >> See the comments from Chris Hopps and others on slow pace of the >> netconf work. If you are going to restrict to two deployed >> implementations, you will be joining the IDR camp of requirements and sl= owing the work further. >> The only reason we require 2 implementations for IDR is for the >> fragile BGP environment and that operators request it due to the >> global consequences. Network Management of these early yang models >> have a much more restricted case. > > May I ask you to point to where I have said anything about two deployed i= mplementations? > > > Ignas > >> Sue Hares >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ignas Bagdonas >> Sent: Wednesday, April 4, 2018 10:31 AM >> To: Susan Hares; 'The IESG' >> Cc: i2rs@ietf.org; >> draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; >> i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Ignas Bagdonas' Discuss on >> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and >> COMMENT) >> >> Hi Sue, >> >> >> On 03/04/2018 14:59, Susan Hares wrote: >>> Ignas: >>> >>> Yan will answer for the authors but I would like to share some >>> information related to the I2RS working group reviews. In your respons= e, >>> please specify why each question is a "DISCUSS" quality question rather >>> than a "Comment" question. The authors and I (as the shepherd) will wo= rk >>> to resolve both DISCUSS and comment issues. >>> >>> Let me review only 5 of your many points because they are pointing in a >>> direction which is different from earlier QA reviews of this document >>> (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 timeframe. >>> 1st - Why TE topology model is not sufficient for modelling the >>> representation of DC fabric? Why is DC fabric network topology special >>> compared to any generic fabric based topology? >> Why DISCUSS? DC fabric is a type of network topology, yes, it has some >> specifics, but nothing radically different than any purpose built networ= k >> topology. Developing a separate model for a specific use case at the sam= e >> time when there is generic and extensible TE model is questionable. >> >>> This document was reviewed by authors with the TE topology models to ma= ke >>> sure there was no conflict or duplication. >>> >>> Your question implies that only one yang model is appropriate for each >>> type of fabric. >> That is exactly opposite. What is special about DC fabric that it has to >> have a separate model? What is special about fabric type of topology tha= t >> it has to have a separate model? Why is TE model not suitable? >> >>> This theory of one yang mode per fabric does not apply to dynamic >>> (ephemeral) datastore versus configuration datastore models. It is als= o >>> not true of all models even within the configuration datastore. >>> Since there is a yang catalog and selection of yang models is specific = to >>> a implemented, there has been no early winnowing of the yang models per >>> type. If you are insisting on this theory of "one yang model" per fabr= ic >>> type, please provide an RFC reference so that I can help review this >>> DISCUSS criteria with the authors. >>> >>> This yang model has been implemented by 1 vendor, and there was interes= t >>> by other vendors. A deployment target has been identified for this >>> model, and feedback is expected from the users. >> Excellent. Please get feedback from user community - even if it is not y= et >> implemented and operations groups will not be able to provide feedback, >> architecture and engineering groups look into upcoming things and will >> have what to say. >> >> Speaking of implementations, the ODL faas project (from where the majori= ty >> of this model seems to be coming from) deals with an instance of overlay >> that is subsequently treated as an underlay, and that is different that >> the underlay on top of which that instance is being run. >> If the model focus is on the "fabric as a service" type of topologies th= en >> it explicitly needs to state that, and then justify why physical node >> properties exist together with logical instance properties in that case. >> >> >>> If you are asking this model to cover three-four layer datacenters, thi= s >>> approach is opposite some of the initial feedback to the group to keep >>> the initial model - that is to keep it simple and restricted to 2 layer= s >>> in order to test the concepts. If you are asking to provide text (in >>> introduction or appendix) that indicates the initial focus, this can be >>> added. >> The document as it is written now tries to cover every possible fabric. >> If the scope is intended to be narrower - it needs to be stated. >> Starting from bounded scope is certainly a right thing to do but that is >> not how the document reads now. >> >> >>> 2nd - Multiple layers and multiple roles. >> Why DISCUSS? Two stage fabrics and fabrics with a perfectly clean node >> role separation do indeed exist, but that is not necessary a common >> deployment model. The document assumes that those are the only possible >> options. >> >>> The authors provide slides in several meetings I2RS meeting reposito= ry >>> regarding this point. >>> The initial feedback suggested reducing the "why" text within the draft= . >>> Again, the initial feedback was to reduce the initial model's text to 2 >>> layers and simple "whys". See proceedings from IETF 95 forward on I2RS >>> on fabric data model for discussions. >> Would users of this model also be required to lookup proceedings of past >> IETF meetings in order to understand whether it may fit their use cases? >> >> >>> 3rd - The authors will comment on the port restrictions. Early feedbac= k >>> during the I2RS meetings from vendors may have taken the authors down >>> this path. In my review, I expect major issues in this area - but I wi= ll >>> let the authors comment. >> Why DISCUSS? The way how the model specifies port speeds is conflicting >> with common deployment practices. >> >>> 4 - policy is simple. >>> >>> Again, the initial feedback was to keep initial policies simple and gai= n >>> feedback from the deployments. >> Why DISCUSS? What kind of policy is being discussed here? The assumption >> of one single universal policy fitting all deployments and use cases >> contradicts to operational reality. >> >> "Policy is simple" does not clarify what kind of policy it is. >> >>> 5 - You indicate that the document requires a "major" rewrite clarifyin= g >>> the logic. >> Why DISCUSS? Model tries to prescribe a way how all DC networks should >> be built. It intermixes concepts of underlay and overlay. There are >> nodes in the model with unclear purpose and no documented details on >> what and how they are doing. >> >>> Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested >>> taking out the lengthy descriptions regarding logic and history. If we >>> are switching the rules for the YANG models, would you please update th= e >>> requirements for the YANG models so that shepherds, rtg-dir, ops-dir, a= nd >>> yang-doctors can have rules for review clearly spelled out. >> YANG models, and any other deliverables of the IETF, are targetted to >> the users of those deliverables and not necessary to the IETF itself. >> The situation with YANG models is that the main consumer of IETF YANG >> model for a noticeable period was IETF itself - it was required to >> build the sufficient coverage of models for them to be practically >> useful. We as an industry start to see more practical use of YANG >> modules, and so far the main obstacle for YANG acceptance is the >> difficulty in trying to use it. It is incorrect to assume that outside >> of the IETF WGs that deal with developing the models there is enough of >> understanding of the reasoning behind modelling decisions made. It is >> incorrect to assume that potential users of such models would try to >> lookup proceedings of past IETF meeting trying to get answers - they >> will chose other manageability technologies instead. YANG models need to >> be self-contained from the practical usability perspective - the models >> themselves should contain enough and meaningful descriptions of the >> nodes that it would not raise questions for users trying to deploy those >> models. Descriptions equivalent to those found in command line >> interfaces - if YANG is expected to become a new command line interface, >> it should be no worse than the command line interface. The reasoning >> behind modelling decisions made also need to be documented - at least >> for allowing model users to see whether the model is suitable for >> deployment in the particular environment. As YANG is maturing and >> starting to be deployed, naturally the focus of reviews will change to >> reflect what is required for successful deployment of the technology. >> >>> Summary on Shepherd's comment: >>> >>> The authors will respond to others specifics, but in order to guide the= se >>> diligent authors - I need to know what rules you are setting for the 20= 18 >>> IESG approval of YANG models. If you are placing a DISCUSS on a YANG >>> model based on a set criteria, the criteria needs to be published on a >>> web page or in an RFC. If I've missed this criteria that the OPS Area h= as >>> specified, >> RFC6087 and draft-ietf-netmod-rfc6087bis. >> >> There are two parts that are important for reviews - the model itself, >> and how the model applies to the managed entities. And there is nothing >> new in the review criteria. The former is rather not that complex, and >> typically can be done within IETF itself. The latter is more complex and >> generally would require feedback from the target users of the model. >> There is a balance between a model being too generic to be practically >> usable and model being too prescriptive to be practically usable. If the >> model puts requirements and restrictions on the managed entities in a >> way that requires to build those managed entities in a specific way, >> predefined by the model authors, the value of such model is >> questionable. Speaking specifically about DC fabric model, it puts >> network design prescriptions that are significantly misaligned with how >> fabric based networks have been and are built. Yes, it is possible to >> find environments where the model would apply directly and with no >> impact, but one would need to look for such deployments quite hard, and >> with a high probability that would be proof of concept or technology >> demonstration type of environments. >> >> IETF is good at developing technology components and fragments, IETF >> typically is not good at dealing with network design and how those >> fragments need to be bound together - that is the reality, and that is >> not necessarily wrong. IETF should be focusing on what it can do best - >> the fragments, and align with users of the fragments on how to improve >> the fragments but not try to direct how users should be building their >> networks. It is important for the reputation of IETF as a credible SDO - >> if IETF manageability mechanisms propose and enforce not necessarily >> right - or just plain broken - network designs, that is a reputation >> problem. This document tends to be proposed standard, and that sets a >> strong message. >> >> Ignas >> >> >>> Thank you for your review, >>> Susan Hares >>> >>> -----Original Message----- >>> From: Ignas Bagdonas [mailto:ibagdona@gmail.com] >>> Sent: Tuesday, April 3, 2018 7:40 AM >>> To: The IESG >>> Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan >>> Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >>> Subject: Ignas Bagdonas' Discuss on >>> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and >>> COMMENT) >>> >>> Ignas Bagdonas has entered the following ballot position for >>> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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.ht= ml >>> 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-i2rs-yang-dc-fabric-network= -topology/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I have concerns about the practical usability of this proposed model as >>> it is specified now. >>> >>> The intended decoupling of fabric implementation properties (what is >>> termed as "underlay network infrastructure" in the document) and its >>> topology seems to be contradicting to general operational practices of >>> fabric based networks. It is generally true for the context of the >>> overlay but that is not what the document seems to be focusing on. Fabr= ic >>> defines and implements the underlay, not the other way around. >>> >>> The document does not contain a sufficient description of the logic of >>> the model itself, the reasons for choices made for representation of >>> types and attributes, and at the same time descriptions in modules are >>> single lines that do not add clarification beyond being copies of leaf >>> names. Either there needs to be a section that describes the logic of t= he >>> model and how it relates to other models, also including examples, or >>> module description fields need to have enough content to be able to hav= e >>> equivalent understanding of model intent and operation. Both are strong= ly >>> encouraged, as descriptions have value of itself for being a reference >>> for use, and model description is needed for understanding how this >>> particular model fits into the larger hierarchy. Network management doe= s >>> not end at the boundary of the single domain-specific model, it is >>> important to build it into a whole system. >>> >>> Why TE topology model is not sufficient for modelling the representatio= n >>> of DC fabric? Why is DC fabric network topology special compared to any >>> generic fabric based topology? >>> >>> How this model could be used for representing more than two stage fabri= cs >>> that are in wide deployment? >>> >>> Limiting port bandwidth to a fixed rate is too restrictive. The model a= s >>> specified already does not cover a set of port speeds that are in >>> deployment. >>> >>> How would a device that has more than a single role in the fabric be >>> represented? >>> >>> Service capabilities as they are described belong to the overlay contex= t >>> while they are called device capabilities. Are those the only possible >>> service capabilities? What is the effect of configuring those >>> capabilities? >>> >>> What is compose-fabric RPC? The document does not define any RPCs. >>> >>> What is policy driven traffic behavior? Is there the only one policy th= at >>> fits all possible deployment scenarios? >>> >>> Looking at the history of the document from the individual submission >>> time and the comments received, it seems that the point fixes to the te= xt >>> went in to cover the specific comments but not to address the broader >>> scope of comments. >>> The document would definitely benefit from a major rewrite clarifying t= he >>> logic behind the decisions made, aligning more with the operational >>> practice of fabric based network design and deployment, and bringing th= e >>> content in YANG modules to be self-describing. >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Fabric and POD are not equivalent terms. >>> >>> I2RS use case requirements document has expired 11 months ago. Use case= s >>> documents are good for tracking the work progress of specification >>> documents, it is questionable whether standalone use cases documents >>> provide value beyond historic record. Is the reference to I2RS use case= s >>> document really needed? >>> >>> What is atomic network? >>> >>> VLAN is not a fabric building technology as such, while Ethernet is. >>> >>> What is the need for VNI capacity leaves? What is their effect if >>> configured? >>> >>> The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces. >>> >>> Serial port-type is present while Infiniband is not - Infiniband based >>> fabrics are widely deployed. What is the extensibility mechanism for >>> adding in new port types? >>> >>> Is there any deployment experience with this model? The ODL faas projec= t >>> hasn't got much activity over last two years. Are you aware of any othe= r >>> implementations or deployments? >>> >>> >>> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Apr 5 11:05:07 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F20B126BF6; Thu, 5 Apr 2018 11:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 gfbKY_dC2NdO; Thu, 5 Apr 2018 11:04:51 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 37A3912AAB6; Thu, 5 Apr 2018 11:04:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Warren Kumari'" Cc: "'Ignas Bagdonas'" , , , , , "'The IESG'" References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <01c701d3cc26$09865b20$1c931160$@ndzh.com> <02d001d3cc61$768db9d0$63a92d70$@ndzh.com> <04bb01d3ccf0$8a9e64d0$9fdb2e70$@ndzh.com> In-Reply-To: Date: Thu, 5 Apr 2018 14:04:42 -0400 Message-ID: <05be01d3cd08$937b9a60$ba72cf20$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrfpTnkeJxdov8ELnNq0f+qOuaSgCz2sVuAohvGooB77/MfwGGdu5JAhwv8qgB2fU06gHy4TM2o142kVA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 18:04:56 -0000 Warren: Thank you for making clear your concerns. I started with the same = concerns and came to resolve these concerns. I will try to write up a = clear summary of why I resolved it. However, I do not have some of the = same datacenter perspective you or Ignas has. I would like your review = on these concerns and the authors comments on these points. =20 The delay until Friday is due to my day jobs (professor and other IETF = hats). I'm just out of time to do a proper job of this work.=20 Sue Hares=20 -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net]=20 Sent: Thursday, April 5, 2018 1:52 PM To: Susan Hares Cc: Ignas Bagdonas; martin.vigoureux@nokia.com; i2rs@ietf.org; = draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; = i2rs-chairs@ietf.org; The IESG Subject: Re: [i2rs] Ignas Bagdonas' Discuss on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = COMMENT) On Thu, Apr 5, 2018 at 11:12 AM, Susan Hares wrote: > Ignas and Warren: > > Your comments on the IESG telechat (4/5/2018) have two components: > 1) a DISCUSS based on direct comparison of the I2RS models (dynamic = and configuration) with the TE models (configuration only), 2) "This = will not work". I need clarity to guide the WG/authors to a successful = resolution of your DISCUSS/Abstain. > > 1) a DISCUSS based on direct comparison of the I2RS models (dynamic = and configuration) with the TE models (configuration only). > > The I2RS models are both available for the dynamic and configuration = datastore. The dynamic configuration models are for models that do not = exactly align with perceptions of the configuration model. These set = of models are for situations that do not align with the configuration = store only. > > As Martin indicated, trying these alternate management Yang models in = dynamic/configuration model configuration needs feedback based on = deployment and interoperability issues. > > This does not align with RFC8342 (NMDA) or and I2RS requirement = documents (RFC8242). If this is your DISCUSS Criteria, then I have a = strong objection to your DISCUSS based on these RFCs. > > If the Discuss/Abstain is based on one of the following discuss = criteria, please state this clear in your emails so I can guide the = authors and the WG. > > 1) The protocol has technical flaws that will prevent it from working = properly, or the description is unclear in such a way that the reader = cannot understand it without ambiguity. > 2) Widespread deployment would be damaging to the Internet or an = enterprise network for reasons of congestion control, scalability, or = the like. > > These are objections I take seriously as a shepherd/WG chair. = However, I need you both to disambiguate between these two components. = I have been trying to get clarity on which DISCUSS criteria Ignas' = comments indicate. > > I expect an IESG members to be able to inform a WG chair which the = discuss criteria you are specifying. I specifically did not ballot DISCUSS as there are no Discuss criteria = which I felt applied - Abstain is a non-blocking position (and so = practically indistinguishable from No Record, and fairly similar to No = Objection). Much of my twitchiness with the document is that it feels like it is = trying to define what a datacenter fabric is (in an Introduction and a = single term - "Fabric: also known as a POD, is a module of network, = compute, storage, and application components that work together to = deliver networking services. It represents a repeatable design pattern. = Its components maximize the modularity, scalability, and manageability = of data centers."). There are a huge number of different data center "fabric" designs, and I = don't really think that the document goes into enough detail about what = exactly it is meaning when it says fabric. It also asserts: "for a DC network, a fabric can be considered as an atomic structure for = management purposes." -- at some level this is probably true, but at the = level that I look at fabrics it definitely isn't -- a fabric is a = thingie made up of many devices and they all require management and = monitoring and care and feeding and love and attention. A lot of the document seems to be written with a specific sets of views = and assumptions (yes, it is obviously extensible, but the base = selections reflect a certain understanding / world view): the 'fabric-type' can be Vxlan, Vlan or Trill (most fabrics I've seen = are plain ethernet), 'port-types' are "Port type: ethernet or serial or = others" (I've never seen a serial fabric, and this leaves out = InfiniBand), 'traffic-behavior' can be normal or policy-driven (with no = description of what the actual difference is, nor what 'policy-driven' = means), the 'fabric-options' are not really options I'd expect to be of = primary import, the 'gateway-mode' options of 'centralized' vs = 'distributed' don't really align with the descriptions (on spine vs = leaf), nor do I understand what that would be critical enough that it is = given such priority and things like the base protocol used isn't), the = descriptions for things like 'fabrictypes:node-ref' ("The device the = fabric includes.") are very unclear. The document / model is at such an unusual level of abstraction = (simultaneously very high and low) that I simply don't understand how = this could usefully be used -- if I view a "fabric" as simply a = commodity thingie that I ride over, and the model is simply = informational, then it contains much which is not useful to me, and = leaves out things like cross sectional BW / locality hints, etc which = would be. If I instead view this as something that I might want to use = to administer / monitor / model a fabric then it is way too simplistic. But, again, I think that this is simply that my views / levels of = abstraction don't align with whatever the authors / WGs are -- and so = I'm not blocking the document, but rather "I oppose this document but = understand that others differ and am not going to stand in the way of = the others." - there is simply a large gulf between my worldview of what = a fabric is (and what levels of abstraction would be useful), and what = this document provides. W > Please let me know if you have additional questions. Your comments = on the telechat did not indicate you understood my concerns. > > Cheerily, Susan Hares > > > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Wednesday, April 4, 2018 6:08 PM > To: 'Ignas Bagdonas'; 'The IESG' > Cc: i2rs@ietf.org;=20 > draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org;=20 > i2rs-chairs@ietf.org > Subject: RE: [i2rs] Ignas Bagdonas' Discuss on=20 > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and=20 > COMMENT) > > Ignas: > > I'm not saying yes/no to change this model. I've forwarded Yan's = comments regarding changes to your specific issues. Yan is very = proactive. It is likely that she will change most of the details if you = respond to her. > > I am acting as a shepherd/WG chair. I'm trying to determine Discuss = Criteria are you using from the following document are you using to = restrict I2RS models (dynamic + configuration capable) because there are = TE specific models in the same area: > https://www.ietf.org/blog/discuss-criteria-iesg-review/ > > This goes against the design criteria I2RS has used. > > You asked for text sequences that lead me to this conclusion: > (1st thread): > [Ignas] > Excellent. Please get feedback from user community - even = if it is not yet implemented and operations groups will not be able to = provide feedback, architecture and engineering groups look into upcoming = things and will have what to say. > > [Sue]: (Repeating earlier comments from email and shepherd's ) We = obtain a vendor (Huawei) and a target deployment situation (Data = Centers) with two potential data centers in China who wanted to work = with this type of logical > deployment. To this shepherd's eyes, this is the operational = information. > > [Sue] (new clarifying comments): If you are still objecting, what else = > do you want as proof that the WG did due diligence on obtaining the=20 > operational feedback for deployment of a model which has I2RS=20 > capabilities (dynamic and > configuration) must be judged against any TE (configuration only ) = data models. > > (2) Further indication that you are comparing I2RS data models against = the 4 TE models without a consideration to dynamic datastore design = issues: > > [Sue's comment]: 3rd - How many of the user community have = implemented I2RS dynamic models or the RFC version of the TE models? > > [Ignas] I am aware of 1 I2RS model family implementation. I am aware = of 4 TE model implementations that I happen to use daily, and aware of = several more that I do not deal with. And I am not certain what value = such counting of implementations brings to this discussion. > > Summary of my question: > I2RS models (configuration and dynamic) are different than regular TE = models and you are lumping the I2RS models in with the configuration = datastore TE models. Please provide me with the DISCUSS criteria or = RFCs you are using to make categorization. > > After we settle on these issues, we can go on to the other comments. > > Sue Hares > > -----Original Message----- > From: Ignas Bagdonas [mailto:ibagdona@gmail.com] > Sent: Wednesday, April 4, 2018 2:40 PM > To: Susan Hares; 'The IESG' > Cc: i2rs@ietf.org;=20 > draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ignas Bagdonas' Discuss on > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and > COMMENT) > > > > On 04/04/2018 16:03, Susan Hares wrote: >> Ignas: >> >> I am not trying to clarify the specifics. This response (as I=20 >> mentioned), will come from the authors. As a shepherd/WG chair, I am = >> asking for information regarding the basis of your DISCUSS models for = >> specific points. >> >> The 2014 document on the IESG discuss criteria is at: >> https://www.ietf.org/blog/discuss-criteria-iesg-review/ >> >> What on this list does the following comment refer to: >> "Why DISCUSS? DC fabric is a type of network topology, yes, it has=20 >> some specifics, but nothing radically different than any purpose=20 >> built network topology. Developing a separate model for a specific=20 >> use case at the same time when there is generic and extensible TE = model is questionable." > The fact that for managing similar functionality there appears to be a = need for different models that would as a result require different model = lifecycle management clearly falls into the category of operational = issues. > > >> Perhaps you are not considering the fact this is an I2RS model. Let=20 >> me provide 3 comments regaring that point: > I am considering the fact that this model defines configuration of = something that is widely deployed in a way that is not compatible with = how it is deployed. The fact that this may be I2RS model is not of the = primary importance. > >> >> 1st - I2RS is focusing on models that are capable for the dynamic=20 >> state and configuration state. These models have qualitative=20 >> differences. The mechanisms of a model which does both dynamic state = >> and configuration state is qualitative different that the basic TE = models. This model >> extends the TE models toward this approach (see module >> ietf-dc-fabric-topology reference import of ietf-network-topology). >> >> 2nd - During the I2RS process we talked to the TE topology authors=20 >> and the TE WG. We agreed that this model has differences. As a WG=20 >> Co-chair, I spent time reviewing this interaction. >> >> 3rd - How many of the user community have implemented I2RS dynamic=20 >> models or the RFC version of the TE models? > I am aware of 1 I2RS model family implementation. I am aware of 4 TE = model implementations that I happen to use daily, and aware of several = more that I do not deal with. And I am not certain what value such = counting of implementations brings to this discussion. > >> See the comments from Chris Hopps and others on slow pace of the=20 >> netconf work. If you are going to restrict to two deployed=20 >> implementations, you will be joining the IDR camp of requirements and = slowing the work further. >> The only reason we require 2 implementations for IDR is for the=20 >> fragile BGP environment and that operators request it due to the=20 >> global consequences. Network Management of these early yang models=20 >> have a much more restricted case. > > May I ask you to point to where I have said anything about two = deployed implementations? > > > Ignas > >> Sue Hares >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ignas Bagdonas >> Sent: Wednesday, April 4, 2018 10:31 AM >> To: Susan Hares; 'The IESG' >> Cc: i2rs@ietf.org; >> draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; >> i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Ignas Bagdonas' Discuss on >> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and >> COMMENT) >> >> Hi Sue, >> >> >> On 03/04/2018 14:59, Susan Hares wrote: >>> Ignas: >>> >>> Yan will answer for the authors but I would like to share some=20 >>> information related to the I2RS working group reviews. In your=20 >>> response, please specify why each question is a "DISCUSS" quality=20 >>> question rather than a "Comment" question. The authors and I (as=20 >>> the shepherd) will work to resolve both DISCUSS and comment issues. >>> >>> Let me review only 5 of your many points because they are pointing=20 >>> in a direction which is different from earlier QA reviews of this=20 >>> document (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 = timeframe. >>> 1st - Why TE topology model is not sufficient for modelling the=20 >>> representation of DC fabric? Why is DC fabric network topology=20 >>> special compared to any generic fabric based topology? >> Why DISCUSS? DC fabric is a type of network topology, yes, it has=20 >> some specifics, but nothing radically different than any purpose=20 >> built network topology. Developing a separate model for a specific=20 >> use case at the same time when there is generic and extensible TE = model is questionable. >> >>> This document was reviewed by authors with the TE topology models to = >>> make sure there was no conflict or duplication. >>> >>> Your question implies that only one yang model is appropriate for=20 >>> each type of fabric. >> That is exactly opposite. What is special about DC fabric that it has = >> to have a separate model? What is special about fabric type of=20 >> topology that it has to have a separate model? Why is TE model not = suitable? >> >>> This theory of one yang mode per fabric does not apply to=20 >>> dynamic >>> (ephemeral) datastore versus configuration datastore models. It is=20 >>> also not true of all models even within the configuration datastore. >>> Since there is a yang catalog and selection of yang models is=20 >>> specific to a implemented, there has been no early winnowing of the=20 >>> yang models per type. If you are insisting on this theory of "one=20 >>> yang model" per fabric type, please provide an RFC reference so that = >>> I can help review this DISCUSS criteria with the authors. >>> >>> This yang model has been implemented by 1 vendor, and there was=20 >>> interest by other vendors. A deployment target has been identified=20 >>> for this model, and feedback is expected from the users. >> Excellent. Please get feedback from user community - even if it is=20 >> not yet implemented and operations groups will not be able to provide = >> feedback, architecture and engineering groups look into upcoming=20 >> things and will have what to say. >> >> Speaking of implementations, the ODL faas project (from where the=20 >> majority of this model seems to be coming from) deals with an=20 >> instance of overlay that is subsequently treated as an underlay, and=20 >> that is different that the underlay on top of which that instance is = being run. >> If the model focus is on the "fabric as a service" type of topologies = >> then it explicitly needs to state that, and then justify why physical = >> node properties exist together with logical instance properties in = that case. >> >> >>> If you are asking this model to cover three-four layer datacenters,=20 >>> this approach is opposite some of the initial feedback to the group=20 >>> to keep the initial model - that is to keep it simple and restricted = >>> to 2 layers in order to test the concepts. If you are asking to=20 >>> provide text (in introduction or appendix) that indicates the=20 >>> initial focus, this can be added. >> The document as it is written now tries to cover every possible = fabric. >> If the scope is intended to be narrower - it needs to be stated. >> Starting from bounded scope is certainly a right thing to do but that = >> is not how the document reads now. >> >> >>> 2nd - Multiple layers and multiple roles. >> Why DISCUSS? Two stage fabrics and fabrics with a perfectly clean=20 >> node role separation do indeed exist, but that is not necessary a=20 >> common deployment model. The document assumes that those are the only = >> possible options. >> >>> The authors provide slides in several meetings I2RS meeting=20 >>> repository regarding this point. >>> The initial feedback suggested reducing the "why" text within the = draft. >>> Again, the initial feedback was to reduce the initial model's text=20 >>> to 2 layers and simple "whys". See proceedings from IETF 95 forward = >>> on I2RS on fabric data model for discussions. >> Would users of this model also be required to lookup proceedings of=20 >> past IETF meetings in order to understand whether it may fit their = use cases? >> >> >>> 3rd - The authors will comment on the port restrictions. Early=20 >>> feedback during the I2RS meetings from vendors may have taken the=20 >>> authors down this path. In my review, I expect major issues in this = >>> area - but I will let the authors comment. >> Why DISCUSS? The way how the model specifies port speeds is=20 >> conflicting with common deployment practices. >> >>> 4 - policy is simple. >>> >>> Again, the initial feedback was to keep initial policies simple and=20 >>> gain feedback from the deployments. >> Why DISCUSS? What kind of policy is being discussed here? The=20 >> assumption of one single universal policy fitting all deployments and = >> use cases contradicts to operational reality. >> >> "Policy is simple" does not clarify what kind of policy it is. >> >>> 5 - You indicate that the document requires a "major" rewrite=20 >>> clarifying the logic. >> Why DISCUSS? Model tries to prescribe a way how all DC networks=20 >> should be built. It intermixes concepts of underlay and overlay.=20 >> There are nodes in the model with unclear purpose and no documented=20 >> details on what and how they are doing. >> >>> Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested=20 >>> taking out the lengthy descriptions regarding logic and history. If = >>> we are switching the rules for the YANG models, would you please=20 >>> update the requirements for the YANG models so that shepherds,=20 >>> rtg-dir, ops-dir, and yang-doctors can have rules for review clearly = spelled out. >> YANG models, and any other deliverables of the IETF, are targetted to = >> the users of those deliverables and not necessary to the IETF itself. >> The situation with YANG models is that the main consumer of IETF YANG = >> model for a noticeable period was IETF itself - it was required to=20 >> build the sufficient coverage of models for them to be practically=20 >> useful. We as an industry start to see more practical use of YANG=20 >> modules, and so far the main obstacle for YANG acceptance is the=20 >> difficulty in trying to use it. It is incorrect to assume that=20 >> outside of the IETF WGs that deal with developing the models there is = >> enough of understanding of the reasoning behind modelling decisions=20 >> made. It is incorrect to assume that potential users of such models=20 >> would try to lookup proceedings of past IETF meeting trying to get=20 >> answers - they will chose other manageability technologies instead.=20 >> YANG models need to be self-contained from the practical usability=20 >> perspective - the models themselves should contain enough and=20 >> meaningful descriptions of the nodes that it would not raise=20 >> questions for users trying to deploy those models. Descriptions=20 >> equivalent to those found in command line interfaces - if YANG is=20 >> expected to become a new command line interface, it should be no=20 >> worse than the command line interface. The reasoning behind modelling = >> decisions made also need to be documented - at least for allowing=20 >> model users to see whether the model is suitable for deployment in=20 >> the particular environment. As YANG is maturing and starting to be=20 >> deployed, naturally the focus of reviews will change to reflect what = is required for successful deployment of the technology. >> >>> Summary on Shepherd's comment: >>> >>> The authors will respond to others specifics, but in order to guide=20 >>> these diligent authors - I need to know what rules you are setting=20 >>> for the 2018 IESG approval of YANG models. If you are placing a=20 >>> DISCUSS on a YANG model based on a set criteria, the criteria needs=20 >>> to be published on a web page or in an RFC. If I've missed this=20 >>> criteria that the OPS Area has specified, >> RFC6087 and draft-ietf-netmod-rfc6087bis. >> >> There are two parts that are important for reviews - the model=20 >> itself, and how the model applies to the managed entities. And there=20 >> is nothing new in the review criteria. The former is rather not that=20 >> complex, and typically can be done within IETF itself. The latter is=20 >> more complex and generally would require feedback from the target = users of the model. >> There is a balance between a model being too generic to be=20 >> practically usable and model being too prescriptive to be practically = >> usable. If the model puts requirements and restrictions on the=20 >> managed entities in a way that requires to build those managed=20 >> entities in a specific way, predefined by the model authors, the=20 >> value of such model is questionable. Speaking specifically about DC=20 >> fabric model, it puts network design prescriptions that are=20 >> significantly misaligned with how fabric based networks have been and = >> are built. Yes, it is possible to find environments where the model=20 >> would apply directly and with no impact, but one would need to look=20 >> for such deployments quite hard, and with a high probability that=20 >> would be proof of concept or technology demonstration type of = environments. >> >> IETF is good at developing technology components and fragments, IETF=20 >> typically is not good at dealing with network design and how those=20 >> fragments need to be bound together - that is the reality, and that=20 >> is not necessarily wrong. IETF should be focusing on what it can do=20 >> best - the fragments, and align with users of the fragments on how to = >> improve the fragments but not try to direct how users should be=20 >> building their networks. It is important for the reputation of IETF=20 >> as a credible SDO - if IETF manageability mechanisms propose and=20 >> enforce not necessarily right - or just plain broken - network=20 >> designs, that is a reputation problem. This document tends to be=20 >> proposed standard, and that sets a strong message. >> >> Ignas >> >> >>> Thank you for your review, >>> Susan Hares >>> >>> -----Original Message----- >>> From: Ignas Bagdonas [mailto:ibagdona@gmail.com] >>> Sent: Tuesday, April 3, 2018 7:40 AM >>> To: The IESG >>> Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan=20 >>> Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >>> Subject: Ignas Bagdonas' Discuss on >>> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS=20 >>> and >>> COMMENT) >>> >>> Ignas Bagdonas has entered the following ballot position for >>> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: Discuss >>> >>> When responding, please keep the subject line intact and reply to=20 >>> all email addresses included in the To and CC lines. (Feel free to=20 >>> cut this introductory paragraph, however.) >>> >>> >>> Please refer to=20 >>> 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-i2rs-yang-dc-fabric-netw >>> ork-topology/ >>> >>> >>> >>> -------------------------------------------------------------------- >>> -- >>> DISCUSS: >>> -------------------------------------------------------------------- >>> -- >>> >>> I have concerns about the practical usability of this proposed model = >>> as it is specified now. >>> >>> The intended decoupling of fabric implementation properties (what is = >>> termed as "underlay network infrastructure" in the document) and its = >>> topology seems to be contradicting to general operational practices=20 >>> of fabric based networks. It is generally true for the context of=20 >>> the overlay but that is not what the document seems to be focusing=20 >>> on. Fabric defines and implements the underlay, not the other way = around. >>> >>> The document does not contain a sufficient description of the logic=20 >>> of the model itself, the reasons for choices made for representation = >>> of types and attributes, and at the same time descriptions in=20 >>> modules are single lines that do not add clarification beyond being=20 >>> copies of leaf names. Either there needs to be a section that=20 >>> describes the logic of the model and how it relates to other models, = >>> also including examples, or module description fields need to have=20 >>> enough content to be able to have equivalent understanding of model=20 >>> intent and operation. Both are strongly encouraged, as descriptions=20 >>> have value of itself for being a reference for use, and model=20 >>> description is needed for understanding how this particular model=20 >>> fits into the larger hierarchy. Network management does not end at=20 >>> the boundary of the single domain-specific model, it is important to = build it into a whole system. >>> >>> Why TE topology model is not sufficient for modelling the=20 >>> representation of DC fabric? Why is DC fabric network topology=20 >>> special compared to any generic fabric based topology? >>> >>> How this model could be used for representing more than two stage=20 >>> fabrics that are in wide deployment? >>> >>> Limiting port bandwidth to a fixed rate is too restrictive. The=20 >>> model as specified already does not cover a set of port speeds that=20 >>> are in deployment. >>> >>> How would a device that has more than a single role in the fabric be = >>> represented? >>> >>> Service capabilities as they are described belong to the overlay=20 >>> context while they are called device capabilities. Are those the=20 >>> only possible service capabilities? What is the effect of=20 >>> configuring those capabilities? >>> >>> What is compose-fabric RPC? The document does not define any RPCs. >>> >>> What is policy driven traffic behavior? Is there the only one policy = >>> that fits all possible deployment scenarios? >>> >>> Looking at the history of the document from the individual=20 >>> submission time and the comments received, it seems that the point=20 >>> fixes to the text went in to cover the specific comments but not to=20 >>> address the broader scope of comments. >>> The document would definitely benefit from a major rewrite=20 >>> clarifying the logic behind the decisions made, aligning more with=20 >>> the operational practice of fabric based network design and=20 >>> deployment, and bringing the content in YANG modules to be = self-describing. >>> >>> >>> -------------------------------------------------------------------- >>> -- >>> COMMENT: >>> -------------------------------------------------------------------- >>> -- >>> >>> Fabric and POD are not equivalent terms. >>> >>> I2RS use case requirements document has expired 11 months ago. Use=20 >>> cases documents are good for tracking the work progress of=20 >>> specification documents, it is questionable whether standalone use=20 >>> cases documents provide value beyond historic record. Is the=20 >>> reference to I2RS use cases document really needed? >>> >>> What is atomic network? >>> >>> VLAN is not a fabric building technology as such, while Ethernet is. >>> >>> What is the need for VNI capacity leaves? What is their effect if=20 >>> configured? >>> >>> The document intermixes ietf-fabric-* and ietf-dc-fabric-* = namespaces. >>> >>> Serial port-type is present while Infiniband is not - Infiniband=20 >>> based fabrics are widely deployed. What is the extensibility=20 >>> mechanism for adding in new port types? >>> >>> Is there any deployment experience with this model? The ODL faas=20 >>> project hasn't got much activity over last two years. Are you aware=20 >>> of any other implementations or deployments? >>> >>> >>> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > -- I don't think the execution is relevant when it was obviously a bad idea = in the first place. This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants. ---maf From nobody Thu Apr 5 13:35:50 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391D312D77B; Thu, 5 Apr 2018 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSYP-BiVANW2; Thu, 5 Apr 2018 13:35:44 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 3027D1200B9; Thu, 5 Apr 2018 13:35:44 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id s12so19912562wrc.8; Thu, 05 Apr 2018 13:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=FI6r6L7dHUJs9CarF96XT0JZ49oqwTbNx4jXNjaVaPw=; b=X10spwHh141G+c/ve1b9iD5DcD8jrEX9gxovMLTJ7XPNXNbyN9hKCafVAhW9t4BQD7 gGJe5/12I4bXVf0O5qaSMfr+u+9joOzc8tloNAGBSSIxHNM5EB9mH8X+4KabDWCKkbAR kyGx+oHwnD9PMX0VQkfjP0PTwA1as+jvg4OwILwUNrpBXdhq06IMK1M0ySwhrrtdASeG XJLgDLRlprL2O/xOfbjyr0A17yalUrw7augZ4DeBWFaNjkVkMYrT4eLvRhNCjFOZSWmI ynYLeF1xDNzXWBWTUW16uYpmJXg916rPPwdRim30zMkO9XysdMlsLyvmwhgCAf8/JYIY 3GUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FI6r6L7dHUJs9CarF96XT0JZ49oqwTbNx4jXNjaVaPw=; b=SShNxNLNv5Ok1e6nmJ4lw42Xu6RPAZWdBhyidA4jSAKe14UOaDKjj10GFtXF+Bss7A XB8P90WiLbHoDzuO+Z2e/LnhVI7w60jz1ll62wOY9htw4EAc1OBTx2/bKy3Q9m6ROGO/ p7LEHe2ETWhcCI8ok2RF5Rn/YWs9FU46fPaUfsRYXWAxwbuG35fBYS4P5Sstbvx+3opp jMXnqournOI62jsoKhxN8wUXXQYl2PMBITh3LPxrtcbDlP2dbZtVmHCU1rVrSckKAtIf kvd9AN+Vr/jkaxXCHJPZoZKetICMcSROYiZnqSOOWONOPkbgy5KOy8G3dwS+he8RLrbA /xPA== X-Gm-Message-State: AElRT7HBvaE6NRdXxOT5w2AgEK//XPwq3vkuV0d80Sq1dg1cxlF4dhEu Tkt6cBsHZ7RZOtSxQIgcQ5dYpM5gIk8= X-Google-Smtp-Source: AIpwx4/mxhi1Z5pPqAYsWvJlwuX0foW8oVzIyrQl0hRjaL8WVo188GRV2Xbq0AMv7CEBHj8OPmtINg== X-Received: by 10.223.210.73 with SMTP id o9mr19358849wri.248.1522960541855; Thu, 05 Apr 2018 13:35:41 -0700 (PDT) Received: from [192.168.96.203] ([80.69.10.100]) by smtp.gmail.com with ESMTPSA id s21sm6080678wra.66.2018.04.05.13.35.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 13:35:41 -0700 (PDT) To: Susan Hares , warren@kumari.net, martin.vigoureux@nokia.com Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org, i2rs-chairs@ietf.org, 'The IESG' References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <01c701d3cc26$09865b20$1c931160$@ndzh.com> <02d001d3cc61$768db9d0$63a92d70$@ndzh.com> <04bb01d3ccf0$8a9e64d0$9fdb2e70$@ndzh.com> From: Ignas Bagdonas Message-ID: <6c1cdaa1-a0ab-701b-0f7e-cd47ed486359@gmail.com> Date: Thu, 5 Apr 2018 21:35:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <04bb01d3ccf0$8a9e64d0$9fdb2e70$@ndzh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 20:35:49 -0000 Hi Sue, I am responding as a DISCUSS holder. Warren may have different ABSTAIN views. On 05/04/2018 16:12, Susan Hares wrote: > Ignas and Warren: > > Your comments on the IESG telechat (4/5/2018) have two components: > 1) a DISCUSS based on direct comparison of the I2RS models (dynamic and configuration) with the TE models (configuration only), This is incorrect. DISCUSS is based on very different background. I2RS and TE models are a small fragment in that background, and as I have mentioned in previous mails, it is not of primary importance. > 2) "This will not work". This is incorrect. DISCUSS is based on the impact of proposed mechanism to operations. Please take a look at my DISCUSS notes again. And let's analyse them in detail then. Network management mechanisms do not exist in vacuum, they are applied onto the entities being managed. Management mechanisms need to fit with the entities (in a broad sense of the word, including network elements and how those elements bind together - the network design) that they are trying to manage. Network design prescribes how the management mechanism will look and operate. DC fabric topology document appears to try to do the opposite - it provides assumptions and restrictions on how the network design that would be suitable for this model to be applied to has to look like. And that design appears to be substantially different than majority of practical deployments in DC network space. Given that this document is on standards track, it sends a strong message to the community saying that if one wants to use IETF approved DC network management mechanism, one needs to design a network based on the assumptions in this document. This is the core of my DISCUSS - the document as it is worded now prescribes network designs and manageability approaches that are disconnected from operational reality. If this was an informational document - likely I would not have much concerns on the same basis, but STD track document has a different impact. Now onto the detailed parts of the DISCUSS. The scope of this model - where is it intended to be applied? Underlay? Overlay? Both at the same time? The text intermixes underlay and overlay scope, there are parts that seem to target one, the other, and both of them. The scope of ODL FAAS project does not help either - it intermixes the concepts even more freely. What might have been authors' intention - and I am not prescribing that, just guessing - was to take a single overlay instance and present it as an underlay, a "fabric as a service" in marketing terms, and to provide a model for managing the elements of that specific instance _ONLY_. I do not see problems with such approach, but the document needs to be very clear on the scope and the proposed mechanisms. If authors' scope intentions were different then it needs to be clarified in detail - the document, at least to me, does not provide clarity on the scope. This is a major part of DISCUSS. The clarity of the model's logic. Model based network management is the new command line interface. It needs to be no worse than the industry norms for CLI. Having in a model leaf-this with a description of "this is leaf-this" does not seem to be sufficient. This is a minor part of DISCUSS. TE topology - I fail to see anything resembling suggestions in the text of the DISCUSS. That is a question. It is a minor part of DISCUSS. Stages, ports, roles, policies - those all are questions. All are minor parts of DISCUSS. RPC - again, that was a question. I fail to see anything resembling a suggestion. That is a minor part of DISCUSS. > I need clarity to guide the WG/authors to a successful resolution of your DISCUSS/Abstain. > > 1) a DISCUSS based on direct comparison of the I2RS models (dynamic and configuration) with the TE models (configuration only). The DISCUSS problem is above the specific details of specific models. > The I2RS models are both available for the dynamic and configuration datastore. The dynamic configuration models are for models that do not exactly align with perceptions of the configuration model. These set of models are for situations that do not align with the configuration store only. > > As Martin indicated, trying these alternate management Yang models in dynamic/configuration model configuration needs feedback based on deployment and interoperability issues. > > This does not align with RFC8342 (NMDA) or and I2RS requirement documents (RFC8242). If this is your DISCUSS Criteria, then I have a strong objection to your DISCUSS based on these RFCs. > > If the Discuss/Abstain is based on one of the following discuss criteria, please state this clear in your emails so I can guide the authors and the WG. > 1) The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity. Yes. Model is not a protocol as such, and the flaws in model would impact not the model directly but the entities being managed by that model - it is a specifics of models vs protocols. > 2) Widespread deployment would be damaging to the Internet or an enterprise network for reasons of congestion control, scalability, or the like. Yes. Or the like - manageability practices. > These are objections I take seriously as a shepherd/WG chair. However, I need you both to disambiguate between these two components. I have been trying to get clarity on which DISCUSS criteria Ignas' comments indicate. > > I expect an IESG members to be able to inform a WG chair which the discuss criteria you are specifying. Please let me know if you have additional questions. Your comments on the telechat did not indicate you understood my concerns. What are your concerns? Ignas > Cheerily, Susan Hares > > > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Wednesday, April 4, 2018 6:08 PM > To: 'Ignas Bagdonas'; 'The IESG' > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; i2rs-chairs@ietf.org > Subject: RE: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) > > Ignas: > > I'm not saying yes/no to change this model. I've forwarded Yan's comments regarding changes to your specific issues. Yan is very proactive. It is likely that she will change most of the details if you respond to her. > > I am acting as a shepherd/WG chair. I'm trying to determine Discuss Criteria are you using from the following document are you using to restrict I2RS models (dynamic + configuration capable) because there are TE specific models in the same area: > https://www.ietf.org/blog/discuss-criteria-iesg-review/ > > This goes against the design criteria I2RS has used. > > You asked for text sequences that lead me to this conclusion: > (1st thread): > [Ignas] > Excellent. Please get feedback from user community - even if it is not yet implemented and operations groups will not be able to provide feedback, architecture and engineering groups look into upcoming things and will have what to say. > > [Sue]: (Repeating earlier comments from email and shepherd's ) We obtain a vendor (Huawei) and a target deployment situation (Data Centers) with two potential data centers in China who wanted to work with this type of logical > deployment. To this shepherd's eyes, this is the operational information. > > [Sue] (new clarifying comments): If you are still objecting, what else do you want as proof that the WG did due diligence on obtaining the operational feedback for deployment of a model which has I2RS capabilities (dynamic and > configuration) must be judged against any TE (configuration only ) data models. > > (2) Further indication that you are comparing I2RS data models against the 4 TE models without a consideration to dynamic datastore design issues: > > [Sue's comment]: 3rd - How many of the user community have implemented I2RS dynamic models or the RFC version of the TE models? > > [Ignas] I am aware of 1 I2RS model family implementation. I am aware of 4 TE model implementations that I happen to use daily, and aware of several more that I do not deal with. And I am not certain what value such counting of implementations brings to this discussion. > > Summary of my question: > I2RS models (configuration and dynamic) are different than regular TE models and you are lumping the I2RS models in with the configuration datastore TE models. Please provide me with the DISCUSS criteria or RFCs you are using to make categorization. > > After we settle on these issues, we can go on to the other comments. > > Sue Hares > > -----Original Message----- > From: Ignas Bagdonas [mailto:ibagdona@gmail.com] > Sent: Wednesday, April 4, 2018 2:40 PM > To: Susan Hares; 'The IESG' > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ignas Bagdonas' Discuss on > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and > COMMENT) > > > > On 04/04/2018 16:03, Susan Hares wrote: >> Ignas: >> >> I am not trying to clarify the specifics. This response (as I >> mentioned), will come from the authors. As a shepherd/WG chair, I am >> asking for information regarding the basis of your DISCUSS models for >> specific points. >> >> The 2014 document on the IESG discuss criteria is at: >> https://www.ietf.org/blog/discuss-criteria-iesg-review/ >> >> What on this list does the following comment refer to: >> "Why DISCUSS? DC fabric is a type of network topology, yes, it has >> some specifics, but nothing radically different than any purpose built >> network topology. Developing a separate model for a specific use case >> at the same time when there is generic and extensible TE model is questionable." > The fact that for managing similar functionality there appears to be a need for different models that would as a result require different model lifecycle management clearly falls into the category of operational issues. > > >> Perhaps you are not considering the fact this is an I2RS model. Let >> me provide 3 comments regaring that point: > I am considering the fact that this model defines configuration of something that is widely deployed in a way that is not compatible with how it is deployed. The fact that this may be I2RS model is not of the primary importance. > >> 1st - I2RS is focusing on models that are capable for the dynamic >> state and configuration state. These models have qualitative >> differences. The mechanisms of a model which does both dynamic state >> and configuration state is qualitative different that the basic TE models. This model >> extends the TE models toward this approach (see module >> ietf-dc-fabric-topology reference import of ietf-network-topology). >> >> 2nd - During the I2RS process we talked to the TE topology authors and >> the TE WG. We agreed that this model has differences. As a WG >> Co-chair, I spent time reviewing this interaction. >> >> 3rd - How many of the user community have implemented I2RS dynamic >> models or the RFC version of the TE models? > I am aware of 1 I2RS model family implementation. I am aware of 4 TE model implementations that I happen to use daily, and aware of several more that I do not deal with. And I am not certain what value such counting of implementations brings to this discussion. > >> See the comments from Chris Hopps and others on slow pace of the >> netconf work. If you are going to restrict to two deployed >> implementations, you will be joining the IDR camp of requirements and slowing the work further. >> The only reason we require 2 implementations for IDR is for the >> fragile BGP environment and that operators request it due to the >> global consequences. Network Management of these early yang models >> have a much more restricted case. > May I ask you to point to where I have said anything about two deployed implementations? > > > Ignas > >> Sue Hares >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ignas Bagdonas >> Sent: Wednesday, April 4, 2018 10:31 AM >> To: Susan Hares; 'The IESG' >> Cc: i2rs@ietf.org; >> draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; >> i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Ignas Bagdonas' Discuss on >> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and >> COMMENT) >> >> Hi Sue, >> >> >> On 03/04/2018 14:59, Susan Hares wrote: >>> Ignas: >>> >>> Yan will answer for the authors but I would like to share some >>> information related to the I2RS working group reviews. In your response, >>> please specify why each question is a "DISCUSS" quality question rather >>> than a "Comment" question. The authors and I (as the shepherd) will work >>> to resolve both DISCUSS and comment issues. >>> >>> Let me review only 5 of your many points because they are pointing in a >>> direction which is different from earlier QA reviews of this document >>> (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 timeframe. >>> 1st - Why TE topology model is not sufficient for modelling the >>> representation of DC fabric? Why is DC fabric network topology special >>> compared to any generic fabric based topology? >> Why DISCUSS? DC fabric is a type of network topology, yes, it has some >> specifics, but nothing radically different than any purpose built network >> topology. Developing a separate model for a specific use case at the same >> time when there is generic and extensible TE model is questionable. >> >>> This document was reviewed by authors with the TE topology models to make >>> sure there was no conflict or duplication. >>> >>> Your question implies that only one yang model is appropriate for each >>> type of fabric. >> That is exactly opposite. What is special about DC fabric that it has to >> have a separate model? What is special about fabric type of topology that >> it has to have a separate model? Why is TE model not suitable? >> >>> This theory of one yang mode per fabric does not apply to dynamic >>> (ephemeral) datastore versus configuration datastore models. It is also >>> not true of all models even within the configuration datastore. >>> Since there is a yang catalog and selection of yang models is specific to >>> a implemented, there has been no early winnowing of the yang models per >>> type. If you are insisting on this theory of "one yang model" per fabric >>> type, please provide an RFC reference so that I can help review this >>> DISCUSS criteria with the authors. >>> >>> This yang model has been implemented by 1 vendor, and there was interest >>> by other vendors. A deployment target has been identified for this >>> model, and feedback is expected from the users. >> Excellent. Please get feedback from user community - even if it is not yet >> implemented and operations groups will not be able to provide feedback, >> architecture and engineering groups look into upcoming things and will >> have what to say. >> >> Speaking of implementations, the ODL faas project (from where the majority >> of this model seems to be coming from) deals with an instance of overlay >> that is subsequently treated as an underlay, and that is different that >> the underlay on top of which that instance is being run. >> If the model focus is on the "fabric as a service" type of topologies then >> it explicitly needs to state that, and then justify why physical node >> properties exist together with logical instance properties in that case. >> >> >>> If you are asking this model to cover three-four layer datacenters, this >>> approach is opposite some of the initial feedback to the group to keep >>> the initial model - that is to keep it simple and restricted to 2 layers >>> in order to test the concepts. If you are asking to provide text (in >>> introduction or appendix) that indicates the initial focus, this can be >>> added. >> The document as it is written now tries to cover every possible fabric. >> If the scope is intended to be narrower - it needs to be stated. >> Starting from bounded scope is certainly a right thing to do but that is >> not how the document reads now. >> >> >>> 2nd - Multiple layers and multiple roles. >> Why DISCUSS? Two stage fabrics and fabrics with a perfectly clean node >> role separation do indeed exist, but that is not necessary a common >> deployment model. The document assumes that those are the only possible >> options. >> >>> The authors provide slides in several meetings I2RS meeting repository >>> regarding this point. >>> The initial feedback suggested reducing the "why" text within the draft. >>> Again, the initial feedback was to reduce the initial model's text to 2 >>> layers and simple "whys". See proceedings from IETF 95 forward on I2RS >>> on fabric data model for discussions. >> Would users of this model also be required to lookup proceedings of past >> IETF meetings in order to understand whether it may fit their use cases? >> >> >>> 3rd - The authors will comment on the port restrictions. Early feedback >>> during the I2RS meetings from vendors may have taken the authors down >>> this path. In my review, I expect major issues in this area - but I will >>> let the authors comment. >> Why DISCUSS? The way how the model specifies port speeds is conflicting >> with common deployment practices. >> >>> 4 - policy is simple. >>> >>> Again, the initial feedback was to keep initial policies simple and gain >>> feedback from the deployments. >> Why DISCUSS? What kind of policy is being discussed here? The assumption >> of one single universal policy fitting all deployments and use cases >> contradicts to operational reality. >> >> "Policy is simple" does not clarify what kind of policy it is. >> >>> 5 - You indicate that the document requires a "major" rewrite clarifying >>> the logic. >> Why DISCUSS? Model tries to prescribe a way how all DC networks should >> be built. It intermixes concepts of underlay and overlay. There are >> nodes in the model with unclear purpose and no documented details on >> what and how they are doing. >> >>> Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested >>> taking out the lengthy descriptions regarding logic and history. If we >>> are switching the rules for the YANG models, would you please update the >>> requirements for the YANG models so that shepherds, rtg-dir, ops-dir, and >>> yang-doctors can have rules for review clearly spelled out. >> YANG models, and any other deliverables of the IETF, are targetted to >> the users of those deliverables and not necessary to the IETF itself. >> The situation with YANG models is that the main consumer of IETF YANG >> model for a noticeable period was IETF itself - it was required to >> build the sufficient coverage of models for them to be practically >> useful. We as an industry start to see more practical use of YANG >> modules, and so far the main obstacle for YANG acceptance is the >> difficulty in trying to use it. It is incorrect to assume that outside >> of the IETF WGs that deal with developing the models there is enough of >> understanding of the reasoning behind modelling decisions made. It is >> incorrect to assume that potential users of such models would try to >> lookup proceedings of past IETF meeting trying to get answers - they >> will chose other manageability technologies instead. YANG models need to >> be self-contained from the practical usability perspective - the models >> themselves should contain enough and meaningful descriptions of the >> nodes that it would not raise questions for users trying to deploy those >> models. Descriptions equivalent to those found in command line >> interfaces - if YANG is expected to become a new command line interface, >> it should be no worse than the command line interface. The reasoning >> behind modelling decisions made also need to be documented - at least >> for allowing model users to see whether the model is suitable for >> deployment in the particular environment. As YANG is maturing and >> starting to be deployed, naturally the focus of reviews will change to >> reflect what is required for successful deployment of the technology. >> >>> Summary on Shepherd's comment: >>> >>> The authors will respond to others specifics, but in order to guide these >>> diligent authors - I need to know what rules you are setting for the 2018 >>> IESG approval of YANG models. If you are placing a DISCUSS on a YANG >>> model based on a set criteria, the criteria needs to be published on a >>> web page or in an RFC. If I've missed this criteria that the OPS Area has >>> specified, >> RFC6087 and draft-ietf-netmod-rfc6087bis. >> >> There are two parts that are important for reviews - the model itself, >> and how the model applies to the managed entities. And there is nothing >> new in the review criteria. The former is rather not that complex, and >> typically can be done within IETF itself. The latter is more complex and >> generally would require feedback from the target users of the model. >> There is a balance between a model being too generic to be practically >> usable and model being too prescriptive to be practically usable. If the >> model puts requirements and restrictions on the managed entities in a >> way that requires to build those managed entities in a specific way, >> predefined by the model authors, the value of such model is >> questionable. Speaking specifically about DC fabric model, it puts >> network design prescriptions that are significantly misaligned with how >> fabric based networks have been and are built. Yes, it is possible to >> find environments where the model would apply directly and with no >> impact, but one would need to look for such deployments quite hard, and >> with a high probability that would be proof of concept or technology >> demonstration type of environments. >> >> IETF is good at developing technology components and fragments, IETF >> typically is not good at dealing with network design and how those >> fragments need to be bound together - that is the reality, and that is >> not necessarily wrong. IETF should be focusing on what it can do best - >> the fragments, and align with users of the fragments on how to improve >> the fragments but not try to direct how users should be building their >> networks. It is important for the reputation of IETF as a credible SDO - >> if IETF manageability mechanisms propose and enforce not necessarily >> right - or just plain broken - network designs, that is a reputation >> problem. This document tends to be proposed standard, and that sets a >> strong message. >> >> Ignas >> >> >>> Thank you for your review, >>> Susan Hares >>> >>> -----Original Message----- >>> From: Ignas Bagdonas [mailto:ibagdona@gmail.com] >>> Sent: Tuesday, April 3, 2018 7:40 AM >>> To: The IESG >>> Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan >>> Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >>> Subject: Ignas Bagdonas' Discuss on >>> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and >>> COMMENT) >>> >>> Ignas Bagdonas has entered the following ballot position for >>> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-topology/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I have concerns about the practical usability of this proposed model as >>> it is specified now. >>> >>> The intended decoupling of fabric implementation properties (what is >>> termed as "underlay network infrastructure" in the document) and its >>> topology seems to be contradicting to general operational practices of >>> fabric based networks. It is generally true for the context of the >>> overlay but that is not what the document seems to be focusing on. Fabric >>> defines and implements the underlay, not the other way around. >>> >>> The document does not contain a sufficient description of the logic of >>> the model itself, the reasons for choices made for representation of >>> types and attributes, and at the same time descriptions in modules are >>> single lines that do not add clarification beyond being copies of leaf >>> names. Either there needs to be a section that describes the logic of the >>> model and how it relates to other models, also including examples, or >>> module description fields need to have enough content to be able to have >>> equivalent understanding of model intent and operation. Both are strongly >>> encouraged, as descriptions have value of itself for being a reference >>> for use, and model description is needed for understanding how this >>> particular model fits into the larger hierarchy. Network management does >>> not end at the boundary of the single domain-specific model, it is >>> important to build it into a whole system. >>> >>> Why TE topology model is not sufficient for modelling the representation >>> of DC fabric? Why is DC fabric network topology special compared to any >>> generic fabric based topology? >>> >>> How this model could be used for representing more than two stage fabrics >>> that are in wide deployment? >>> >>> Limiting port bandwidth to a fixed rate is too restrictive. The model as >>> specified already does not cover a set of port speeds that are in >>> deployment. >>> >>> How would a device that has more than a single role in the fabric be >>> represented? >>> >>> Service capabilities as they are described belong to the overlay context >>> while they are called device capabilities. Are those the only possible >>> service capabilities? What is the effect of configuring those >>> capabilities? >>> >>> What is compose-fabric RPC? The document does not define any RPCs. >>> >>> What is policy driven traffic behavior? Is there the only one policy that >>> fits all possible deployment scenarios? >>> >>> Looking at the history of the document from the individual submission >>> time and the comments received, it seems that the point fixes to the text >>> went in to cover the specific comments but not to address the broader >>> scope of comments. >>> The document would definitely benefit from a major rewrite clarifying the >>> logic behind the decisions made, aligning more with the operational >>> practice of fabric based network design and deployment, and bringing the >>> content in YANG modules to be self-describing. >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Fabric and POD are not equivalent terms. >>> >>> I2RS use case requirements document has expired 11 months ago. Use cases >>> documents are good for tracking the work progress of specification >>> documents, it is questionable whether standalone use cases documents >>> provide value beyond historic record. Is the reference to I2RS use cases >>> document really needed? >>> >>> What is atomic network? >>> >>> VLAN is not a fabric building technology as such, while Ethernet is. >>> >>> What is the need for VNI capacity leaves? What is their effect if >>> configured? >>> >>> The document intermixes ietf-fabric-* and ietf-dc-fabric-* namespaces. >>> >>> Serial port-type is present while Infiniband is not - Infiniband based >>> fabrics are widely deployed. What is the extensibility mechanism for >>> adding in new port types? >>> >>> Is there any deployment experience with this model? The ODL faas project >>> hasn't got much activity over last two years. Are you aware of any other >>> implementations or deployments? >>> >>> >>> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Thu Apr 5 13:58:30 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950B612D7E8; Thu, 5 Apr 2018 13:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 c3cuFuBf4VnW; Thu, 5 Apr 2018 13:58:25 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 045DB12D7E4; Thu, 5 Apr 2018 13:58:24 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89; From: "Susan Hares" To: "'Ignas Bagdonas'" , , Cc: , , , "'The IESG'" References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <006401d3cb53$f17c36d0$d474a470$@ndzh.com> <01c701d3cc26$09865b20$1c931160$@ndzh.com> <02d001d3cc61$768db9d0$63a92d70$@ndzh.com> <04bb01d3ccf0$8a9e64d0$9fdb2e70$@ndzh.com> <6c1cdaa1-a0ab-701b-0f7e-cd47ed486359@gmail.com> In-Reply-To: <6c1cdaa1-a0ab-701b-0f7e-cd47ed486359@gmail.com> Date: Thu, 5 Apr 2018 16:58:15 -0400 Message-ID: <068e01d3cd20$d20a1500$761e3f00$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrfpTnkeJxdov8ELnNq0f+qOuaSgCz2sVuAohvGooB77/MfwGGdu5JAhwv8qgB2fU06gGKFI6bo2Gr8+A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 20:58:29 -0000 Ignas:=20 Thank you for the clarifying email. I just wanted to understand the = type of discuss. This statement clarifies the discuss:=20 DISCUSS is based on the impact of proposed mechanism to operations This matches the following category from DISCUSS: "It would present = serious operational issues in widespread deployment, by for example = neglecting network management or configuration entirely."=20 =20 May I suggest if the TE is a minor issue, you move the TE comparison to = comments so we can focus on the others? You can always raise it to the = DISCUSS level later after we solve the main issue. =20 Do the suggestions that Yan start to address the problem? Is she heading = in the right direction? If not, we may need to open up the discussion to = a wider audience in the WG and the I2RS AD.=20 Cheerily, Susan Hares=20 =3D=3D=3D=3D=3D=3D=3D=3D When you say "not of primary importance", does this mean the I2RS/TE = models are in the DISCUSS or out of it?=20 -----Original Message----- From: Ignas Bagdonas [mailto:ibagdona@gmail.com]=20 Sent: Thursday, April 5, 2018 4:36 PM To: Susan Hares; warren@kumari.net; martin.vigoureux@nokia.com Cc: i2rs@ietf.org; = draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; = i2rs-chairs@ietf.org; 'The IESG' Subject: Re: [i2rs] Ignas Bagdonas' Discuss on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = COMMENT) Hi Sue, I am responding as a DISCUSS holder. Warren may have different ABSTAIN = views. On 05/04/2018 16:12, Susan Hares wrote: > Ignas and Warren: > > Your comments on the IESG telechat (4/5/2018) have two components: > 1) a DISCUSS based on direct comparison of the I2RS models (dynamic=20 > and configuration) with the TE models (configuration only), This is incorrect. DISCUSS is based on very different background. I2RS = and TE models are a small fragment in that background, and as I have = mentioned in previous mails, it is not of primary importance. > 2) "This will not work". This is incorrect. DISCUSS is based on the impact of proposed mechanism = to operations. Please take a look at my DISCUSS notes again. And let's analyse them in = detail then. Network management mechanisms do not exist in vacuum, they are applied = onto the entities being managed. Management mechanisms need to fit with = the entities (in a broad sense of the word, including network elements = and how those elements bind together - the network design) that they are = trying to manage. Network design prescribes how the management mechanism = will look and operate. DC fabric topology document appears to try to do = the opposite - it provides assumptions and restrictions on how the = network design that would be suitable for this model to be applied to = has to look like. And that design appears to be substantially different = than majority of practical deployments in DC network space. Given that = this document is on standards track, it sends a strong message to the = community saying that if one wants to use IETF approved DC network = management mechanism, one needs to design a network based on the = assumptions in this document. This is the core of my DISCUSS - the = document as it is worded now prescribes network designs and = manageability approaches that are disconnected from operational reality. = If this was an informational document - likely I would not have much = concerns on the same basis, but STD track document has a different = impact. Now onto the detailed parts of the DISCUSS. The scope of this model - = where is it intended to be applied? Underlay? Overlay? Both at the same = time? The text intermixes underlay and overlay scope, there are parts = that seem to target one, the other, and both of them. The scope of ODL = FAAS project does not help either - it intermixes the concepts even more = freely. What might have been authors' intention - and I am not = prescribing that, just guessing - was to take a single overlay instance = and present it as an underlay, a "fabric as a service" in marketing = terms, and to provide a model for managing the elements of that specific = instance _ONLY_. I do not see problems with such approach, but the = document needs to be very clear on the scope and the proposed = mechanisms. If authors' scope intentions were different then it needs to = be clarified in detail - the document, at least to me, does not provide = clarity on the scope. This is a major part of DISCUSS. The clarity of the model's logic. Model based network management is the = new command line interface. It needs to be no worse than the industry = norms for CLI. Having in a model leaf-this with a description of "this = is leaf-this" does not seem to be sufficient. This is a minor part of = DISCUSS. TE topology - I fail to see anything resembling suggestions in the text = of the DISCUSS. That is a question. It is a minor part of DISCUSS. Stages, ports, roles, policies - those all are questions. All are minor = parts of DISCUSS. RPC - again, that was a question. I fail to see anything resembling a = suggestion. That is a minor part of DISCUSS. > I need clarity to guide the WG/authors to a successful resolution of = your DISCUSS/Abstain. > > 1) a DISCUSS based on direct comparison of the I2RS models (dynamic = and configuration) with the TE models (configuration only). The DISCUSS problem is above the specific details of specific models. > The I2RS models are both available for the dynamic and configuration = datastore. The dynamic configuration models are for models that do not = exactly align with perceptions of the configuration model. These set = of models are for situations that do not align with the configuration = store only. > > As Martin indicated, trying these alternate management Yang models in = dynamic/configuration model configuration needs feedback based on = deployment and interoperability issues. > > This does not align with RFC8342 (NMDA) or and I2RS requirement = documents (RFC8242). If this is your DISCUSS Criteria, then I have a = strong objection to your DISCUSS based on these RFCs. > > If the Discuss/Abstain is based on one of the following discuss = criteria, please state this clear in your emails so I can guide the = authors and the WG. > 1) The protocol has technical flaws that will prevent it from working = properly, or the description is unclear in such a way that the reader = cannot understand it without ambiguity. Yes. Model is not a protocol as such, and the flaws in model would=20 impact not the model directly but the entities being managed by that=20 model - it is a specifics of models vs protocols. > 2) Widespread deployment would be damaging to the Internet or an = enterprise network for reasons of congestion control, scalability, or = the like. Yes. Or the like - manageability practices. > These are objections I take seriously as a shepherd/WG chair. = However, I need you both to disambiguate between these two components. = I have been trying to get clarity on which DISCUSS criteria Ignas' = comments indicate. > > I expect an IESG members to be able to inform a WG chair which the = discuss criteria you are specifying. Please let me know if you have = additional questions. Your comments on the telechat did not indicate = you understood my concerns. What are your concerns? Ignas > Cheerily, Susan Hares > > > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Wednesday, April 4, 2018 6:08 PM > To: 'Ignas Bagdonas'; 'The IESG' > Cc: i2rs@ietf.org; = draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; = i2rs-chairs@ietf.org > Subject: RE: [i2rs] Ignas Bagdonas' Discuss on = draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and = COMMENT) > > Ignas: > > I'm not saying yes/no to change this model. I've forwarded Yan's = comments regarding changes to your specific issues. Yan is very = proactive. It is likely that she will change most of the details if you = respond to her. > > I am acting as a shepherd/WG chair. I'm trying to determine Discuss = Criteria are you using from the following document are you using to = restrict I2RS models (dynamic + configuration capable) because there are = TE specific models in the same area: > https://www.ietf.org/blog/discuss-criteria-iesg-review/ > > This goes against the design criteria I2RS has used. > > You asked for text sequences that lead me to this conclusion: > (1st thread): > [Ignas] > Excellent. Please get feedback from user community - even = if it is not yet implemented and operations groups will not be able to = provide feedback, architecture and engineering groups look into upcoming = things and will have what to say. > > [Sue]: (Repeating earlier comments from email and shepherd's ) We = obtain a vendor (Huawei) and a target deployment situation (Data = Centers) with two potential data centers in China who wanted to work = with this type of logical > deployment. To this shepherd's eyes, this is the operational = information. > > [Sue] (new clarifying comments): If you are still objecting, what else = do you want as proof that the WG did due diligence on obtaining the = operational feedback for deployment of a model which has I2RS = capabilities (dynamic and > configuration) must be judged against any TE (configuration only ) = data models. > > (2) Further indication that you are comparing I2RS data models against = the 4 TE models without a consideration to dynamic datastore design = issues: > > [Sue's comment]: 3rd - How many of the user community have = implemented I2RS dynamic models or the RFC version of the TE models? > > [Ignas] I am aware of 1 I2RS model family implementation. I am aware = of 4 TE model implementations that I happen to use daily, and aware of = several more that I do not deal with. And I am not certain what value = such counting of implementations brings to this discussion. > > Summary of my question: > I2RS models (configuration and dynamic) are different than regular TE = models and you are lumping the I2RS models in with the configuration = datastore TE models. Please provide me with the DISCUSS criteria or = RFCs you are using to make categorization. > > After we settle on these issues, we can go on to the other comments. > > Sue Hares > > -----Original Message----- > From: Ignas Bagdonas [mailto:ibagdona@gmail.com] > Sent: Wednesday, April 4, 2018 2:40 PM > To: Susan Hares; 'The IESG' > Cc: i2rs@ietf.org; = draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; > i2rs-chairs@ietf.org > Subject: Re: [i2rs] Ignas Bagdonas' Discuss on > draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and > COMMENT) > > > > On 04/04/2018 16:03, Susan Hares wrote: >> Ignas: >> >> I am not trying to clarify the specifics. This response (as I >> mentioned), will come from the authors. As a shepherd/WG chair, I am >> asking for information regarding the basis of your DISCUSS models for >> specific points. >> >> The 2014 document on the IESG discuss criteria is at: >> https://www.ietf.org/blog/discuss-criteria-iesg-review/ >> >> What on this list does the following comment refer to: >> "Why DISCUSS? DC fabric is a type of network topology, yes, it has >> some specifics, but nothing radically different than any purpose = built >> network topology. Developing a separate model for a specific use case >> at the same time when there is generic and extensible TE model is = questionable." > The fact that for managing similar functionality there appears to be a = need for different models that would as a result require different model = lifecycle management clearly falls into the category of operational = issues. > > >> Perhaps you are not considering the fact this is an I2RS model. Let >> me provide 3 comments regaring that point: > I am considering the fact that this model defines configuration of = something that is widely deployed in a way that is not compatible with = how it is deployed. The fact that this may be I2RS model is not of the = primary importance. > >> 1st - I2RS is focusing on models that are capable for the dynamic >> state and configuration state. These models have qualitative >> differences. The mechanisms of a model which does both dynamic state >> and configuration state is qualitative different that the basic TE = models. This model >> extends the TE models toward this approach (see module >> ietf-dc-fabric-topology reference import of ietf-network-topology). >> >> 2nd - During the I2RS process we talked to the TE topology authors = and >> the TE WG. We agreed that this model has differences. As a WG >> Co-chair, I spent time reviewing this interaction. >> >> 3rd - How many of the user community have implemented I2RS dynamic >> models or the RFC version of the TE models? > I am aware of 1 I2RS model family implementation. I am aware of 4 TE = model implementations that I happen to use daily, and aware of several = more that I do not deal with. And I am not certain what value such = counting of implementations brings to this discussion. > >> See the comments from Chris Hopps and others on slow pace of the >> netconf work. If you are going to restrict to two deployed >> implementations, you will be joining the IDR camp of requirements and = slowing the work further. >> The only reason we require 2 implementations for IDR is for the >> fragile BGP environment and that operators request it due to the >> global consequences. Network Management of these early yang models >> have a much more restricted case. > May I ask you to point to where I have said anything about two = deployed implementations? > > > Ignas > >> Sue Hares >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ignas Bagdonas >> Sent: Wednesday, April 4, 2018 10:31 AM >> To: Susan Hares; 'The IESG' >> Cc: i2rs@ietf.org; >> draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; >> i2rs-chairs@ietf.org >> Subject: Re: [i2rs] Ignas Bagdonas' Discuss on >> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and >> COMMENT) >> >> Hi Sue, >> >> >> On 03/04/2018 14:59, Susan Hares wrote: >>> Ignas: >>> >>> Yan will answer for the authors but I would like to share some >>> information related to the I2RS working group reviews. In your = response, >>> please specify why each question is a "DISCUSS" quality question = rather >>> than a "Comment" question. The authors and I (as the shepherd) will = work >>> to resolve both DISCUSS and comment issues. >>> >>> Let me review only 5 of your many points because they are pointing = in a >>> direction which is different from earlier QA reviews of this = document >>> (rtg-dir, ops-dir, yang-doctors) in the 2017-2018 timeframe. >>> 1st - Why TE topology model is not sufficient for modelling the >>> representation of DC fabric? Why is DC fabric network topology = special >>> compared to any generic fabric based topology? >> Why DISCUSS? DC fabric is a type of network topology, yes, it has = some >> specifics, but nothing radically different than any purpose built = network >> topology. Developing a separate model for a specific use case at the = same >> time when there is generic and extensible TE model is questionable. >> >>> This document was reviewed by authors with the TE topology models to = make >>> sure there was no conflict or duplication. >>> >>> Your question implies that only one yang model is appropriate for = each >>> type of fabric. >> That is exactly opposite. What is special about DC fabric that it has = to >> have a separate model? What is special about fabric type of topology = that >> it has to have a separate model? Why is TE model not suitable? >> >>> This theory of one yang mode per fabric does not apply to = dynamic >>> (ephemeral) datastore versus configuration datastore models. It is = also >>> not true of all models even within the configuration datastore. >>> Since there is a yang catalog and selection of yang models is = specific to >>> a implemented, there has been no early winnowing of the yang models = per >>> type. If you are insisting on this theory of "one yang model" per = fabric >>> type, please provide an RFC reference so that I can help review this >>> DISCUSS criteria with the authors. >>> >>> This yang model has been implemented by 1 vendor, and there was = interest >>> by other vendors. A deployment target has been identified for this >>> model, and feedback is expected from the users. >> Excellent. Please get feedback from user community - even if it is = not yet >> implemented and operations groups will not be able to provide = feedback, >> architecture and engineering groups look into upcoming things and = will >> have what to say. >> >> Speaking of implementations, the ODL faas project (from where the = majority >> of this model seems to be coming from) deals with an instance of = overlay >> that is subsequently treated as an underlay, and that is different = that >> the underlay on top of which that instance is being run. >> If the model focus is on the "fabric as a service" type of topologies = then >> it explicitly needs to state that, and then justify why physical node >> properties exist together with logical instance properties in that = case. >> >> >>> If you are asking this model to cover three-four layer datacenters, = this >>> approach is opposite some of the initial feedback to the group to = keep >>> the initial model - that is to keep it simple and restricted to 2 = layers >>> in order to test the concepts. If you are asking to provide text = (in >>> introduction or appendix) that indicates the initial focus, this can = be >>> added. >> The document as it is written now tries to cover every possible = fabric. >> If the scope is intended to be narrower - it needs to be stated. >> Starting from bounded scope is certainly a right thing to do but that = is >> not how the document reads now. >> >> >>> 2nd - Multiple layers and multiple roles. >> Why DISCUSS? Two stage fabrics and fabrics with a perfectly clean = node >> role separation do indeed exist, but that is not necessary a common >> deployment model. The document assumes that those are the only = possible >> options. >> >>> The authors provide slides in several meetings I2RS meeting = repository >>> regarding this point. >>> The initial feedback suggested reducing the "why" text within the = draft. >>> Again, the initial feedback was to reduce the initial model's text = to 2 >>> layers and simple "whys". See proceedings from IETF 95 forward on = I2RS >>> on fabric data model for discussions. >> Would users of this model also be required to lookup proceedings of = past >> IETF meetings in order to understand whether it may fit their use = cases? >> >> >>> 3rd - The authors will comment on the port restrictions. Early = feedback >>> during the I2RS meetings from vendors may have taken the authors = down >>> this path. In my review, I expect major issues in this area - but I = will >>> let the authors comment. >> Why DISCUSS? The way how the model specifies port speeds is = conflicting >> with common deployment practices. >> >>> 4 - policy is simple. >>> >>> Again, the initial feedback was to keep initial policies simple and = gain >>> feedback from the deployments. >> Why DISCUSS? What kind of policy is being discussed here? The = assumption >> of one single universal policy fitting all deployments and use cases >> contradicts to operational reality. >> >> "Policy is simple" does not clarify what kind of policy it is. >> >>> 5 - You indicate that the document requires a "major" rewrite = clarifying >>> the logic. >> Why DISCUSS? Model tries to prescribe a way how all DC networks = should >> be built. It intermixes concepts of underlay and overlay. There are >> nodes in the model with unclear purpose and no documented details on >> what and how they are doing. >> >>> Earlier feedback (rtg-dir, ops-dir, yang-doctors) on YANG suggested >>> taking out the lengthy descriptions regarding logic and history. If = we >>> are switching the rules for the YANG models, would you please update = the >>> requirements for the YANG models so that shepherds, rtg-dir, = ops-dir, and >>> yang-doctors can have rules for review clearly spelled out. >> YANG models, and any other deliverables of the IETF, are targetted to >> the users of those deliverables and not necessary to the IETF itself. >> The situation with YANG models is that the main consumer of IETF YANG >> model for a noticeable period was IETF itself - it was required to >> build the sufficient coverage of models for them to be practically >> useful. We as an industry start to see more practical use of YANG >> modules, and so far the main obstacle for YANG acceptance is the >> difficulty in trying to use it. It is incorrect to assume that = outside >> of the IETF WGs that deal with developing the models there is enough = of >> understanding of the reasoning behind modelling decisions made. It is >> incorrect to assume that potential users of such models would try to >> lookup proceedings of past IETF meeting trying to get answers - they >> will chose other manageability technologies instead. YANG models need = to >> be self-contained from the practical usability perspective - the = models >> themselves should contain enough and meaningful descriptions of the >> nodes that it would not raise questions for users trying to deploy = those >> models. Descriptions equivalent to those found in command line >> interfaces - if YANG is expected to become a new command line = interface, >> it should be no worse than the command line interface. The reasoning >> behind modelling decisions made also need to be documented - at least >> for allowing model users to see whether the model is suitable for >> deployment in the particular environment. As YANG is maturing and >> starting to be deployed, naturally the focus of reviews will change = to >> reflect what is required for successful deployment of the technology. >> >>> Summary on Shepherd's comment: >>> >>> The authors will respond to others specifics, but in order to guide = these >>> diligent authors - I need to know what rules you are setting for the = 2018 >>> IESG approval of YANG models. If you are placing a DISCUSS on a = YANG >>> model based on a set criteria, the criteria needs to be published on = a >>> web page or in an RFC. If I've missed this criteria that the OPS = Area has >>> specified, >> RFC6087 and draft-ietf-netmod-rfc6087bis. >> >> There are two parts that are important for reviews - the model = itself, >> and how the model applies to the managed entities. And there is = nothing >> new in the review criteria. The former is rather not that complex, = and >> typically can be done within IETF itself. The latter is more complex = and >> generally would require feedback from the target users of the model. >> There is a balance between a model being too generic to be = practically >> usable and model being too prescriptive to be practically usable. If = the >> model puts requirements and restrictions on the managed entities in a >> way that requires to build those managed entities in a specific way, >> predefined by the model authors, the value of such model is >> questionable. Speaking specifically about DC fabric model, it puts >> network design prescriptions that are significantly misaligned with = how >> fabric based networks have been and are built. Yes, it is possible to >> find environments where the model would apply directly and with no >> impact, but one would need to look for such deployments quite hard, = and >> with a high probability that would be proof of concept or technology >> demonstration type of environments. >> >> IETF is good at developing technology components and fragments, IETF >> typically is not good at dealing with network design and how those >> fragments need to be bound together - that is the reality, and that = is >> not necessarily wrong. IETF should be focusing on what it can do best = - >> the fragments, and align with users of the fragments on how to = improve >> the fragments but not try to direct how users should be building = their >> networks. It is important for the reputation of IETF as a credible = SDO - >> if IETF manageability mechanisms propose and enforce not necessarily >> right - or just plain broken - network designs, that is a reputation >> problem. This document tends to be proposed standard, and that sets a >> strong message. >> >> Ignas >> >> >>> Thank you for your review, >>> Susan Hares >>> >>> -----Original Message----- >>> From: Ignas Bagdonas [mailto:ibagdona@gmail.com] >>> Sent: Tuesday, April 3, 2018 7:40 AM >>> To: The IESG >>> Cc: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org; Susan >>> Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org >>> Subject: Ignas Bagdonas' Discuss on >>> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS = and >>> COMMENT) >>> >>> Ignas Bagdonas has entered the following ballot position for >>> draft-ietf-i2rs-yang-dc-fabric-network-topology-08: 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-i2rs-yang-dc-fabric-network-t= opology/ >>> >>> >>> >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>> >>> I have concerns about the practical usability of this proposed model = as >>> it is specified now. >>> >>> The intended decoupling of fabric implementation properties (what is >>> termed as "underlay network infrastructure" in the document) and its >>> topology seems to be contradicting to general operational practices = of >>> fabric based networks. It is generally true for the context of the >>> overlay but that is not what the document seems to be focusing on. = Fabric >>> defines and implements the underlay, not the other way around. >>> >>> The document does not contain a sufficient description of the logic = of >>> the model itself, the reasons for choices made for representation of >>> types and attributes, and at the same time descriptions in modules = are >>> single lines that do not add clarification beyond being copies of = leaf >>> names. Either there needs to be a section that describes the logic = of the >>> model and how it relates to other models, also including examples, = or >>> module description fields need to have enough content to be able to = have >>> equivalent understanding of model intent and operation. Both are = strongly >>> encouraged, as descriptions have value of itself for being a = reference >>> for use, and model description is needed for understanding how this >>> particular model fits into the larger hierarchy. Network management = does >>> not end at the boundary of the single domain-specific model, it is >>> important to build it into a whole system. >>> >>> Why TE topology model is not sufficient for modelling the = representation >>> of DC fabric? Why is DC fabric network topology special compared to = any >>> generic fabric based topology? >>> >>> How this model could be used for representing more than two stage = fabrics >>> that are in wide deployment? >>> >>> Limiting port bandwidth to a fixed rate is too restrictive. The = model as >>> specified already does not cover a set of port speeds that are in >>> deployment. >>> >>> How would a device that has more than a single role in the fabric be >>> represented? >>> >>> Service capabilities as they are described belong to the overlay = context >>> while they are called device capabilities. Are those the only = possible >>> service capabilities? What is the effect of configuring those >>> capabilities? >>> >>> What is compose-fabric RPC? The document does not define any RPCs. >>> >>> What is policy driven traffic behavior? Is there the only one policy = that >>> fits all possible deployment scenarios? >>> >>> Looking at the history of the document from the individual = submission >>> time and the comments received, it seems that the point fixes to the = text >>> went in to cover the specific comments but not to address the = broader >>> scope of comments. >>> The document would definitely benefit from a major rewrite = clarifying the >>> logic behind the decisions made, aligning more with the operational >>> practice of fabric based network design and deployment, and bringing = the >>> content in YANG modules to be self-describing. >>> >>> >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>> >>> Fabric and POD are not equivalent terms. >>> >>> I2RS use case requirements document has expired 11 months ago. Use = cases >>> documents are good for tracking the work progress of specification >>> documents, it is questionable whether standalone use cases documents >>> provide value beyond historic record. Is the reference to I2RS use = cases >>> document really needed? >>> >>> What is atomic network? >>> >>> VLAN is not a fabric building technology as such, while Ethernet is. >>> >>> What is the need for VNI capacity leaves? What is their effect if >>> configured? >>> >>> The document intermixes ietf-fabric-* and ietf-dc-fabric-* = namespaces. >>> >>> Serial port-type is present while Infiniband is not - Infiniband = based >>> fabrics are widely deployed. What is the extensibility mechanism for >>> adding in new port types? >>> >>> Is there any deployment experience with this model? The ODL faas = project >>> hasn't got much activity over last two years. Are you aware of any = other >>> implementations or deployments? >>> >>> >>> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Thu Apr 5 17:21:48 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134A612E04B for ; Thu, 5 Apr 2018 17:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 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_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=1.164, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 T-6UEhSbovMA for ; Thu, 5 Apr 2018 17:21:38 -0700 (PDT) Received: from sonic310-23.consmr.mail.ne1.yahoo.com (sonic310-23.consmr.mail.ne1.yahoo.com [66.163.186.204]) (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 DB02B12E3AE for ; Thu, 5 Apr 2018 17:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1522974097; bh=z/bNwANOxRo1ggNYqM0goVCFCeBDetpfZSvVllgxl3A=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=fURs5gMWhUmM/WX5cdGEVRrovBF1cq+WQZXdI1DRfKnrw4hNIt/ttLpk+cCD41U70UE7V7IkaUecd3ewVVCvIEbZwFbCPjTgLIJc4cC8Akx+5o335XTdobWdQDsYnDYN1F/2vkZk08wSEYF6yYjfuYk05yrHkWBaIUXs1qwu2fYkF9ixzG8vdGjpP7sKGRTfWnZ6gWX04eECStOJOhP4peV6aayubX1cZhgjYZCAzBDErIlrXZE9LnqilHcy01IL4ISYoWXIYsuDuQxpyqHDZqflJMey56Q1ZA3jwYsfcAd37p+X0tFoh7fTXToy+Y0/5pTmHMxP2VLjL17Y2QBChQ== X-YMail-OSG: 7PoWeKIVM1krKTo_u6adXImjjGgyO6pEIopdBorrD5qPv0e3pkKzd8ofQoKKmTQ lwAIFzpQ0H4uql0lRSKFE4lycRrQlB2s3SXC_QoUpkZiVinVb4C3CdDcQG5gOCrpbAjAJtlw3Ys4 3sHwWrNvILhsz9xk5EPd3pZEbg76sni1ZenBXx8I2bfeB71ySeKbdI52Cg0EAXKKSKlu_3F1mHqH fLI6FGLwVAcx_4VihD.Bxe7nn1KO5oaP1X3XU6kVLjsZ8N.qvbiaMO4ZCKZupQw2.C9RNsz_Co0D Eo6X5FXFEOlT3jIog.OqN_wZ2tbwTAbXbwFWAnaaJbCGo_3TuVIXuJaHzb4mo7vuelPRM2To3le1 jmLRq6c8bNiHcMm7VaczuEQh9UF0vjwhBvv2cCkWX3audc5GLQ8lzO24hDx9zeXA88M.g3reXEsu lVGrlCz3.OviQsDJ8tn8mO4jQ7caVjBr_S3VPAiB0QgbHrH7AIuEli468uDxAmXjPf3fZ5YJg_Gj aWlEcsbRBTGwl Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Fri, 6 Apr 2018 00:21:37 +0000 Received: from 67.136.82.65 (EHLO [172.26.17.164]) ([67.136.82.65]) by smtp431.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 59b4ebe514fe3fd1a09f5d4efa0cb7d3; Fri, 06 Apr 2018 00:11:33 +0000 (UTC) User-Agent: Microsoft-MacOutlook/10.9.0.180116 Date: Thu, 05 Apr 2018 17:11:31 -0700 From: Nitin Bahadur To: Susan Hares , 'Alissa Cooper' , 'Peter Yee' CC: , , 'The IESG' , Message-ID: Thread-Topic: [i2rs] [Gen-art] Genart last call review of draft-ietf-i2rs-rib-info-model-14 References: <691C7A84-6590-4823-9979-4EC48FC64B2C@yahoo.com> <042701d3cce5$592af180$0b80d480$@ndzh.com> In-Reply-To: <042701d3cce5$592af180$0b80d480$@ndzh.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3605793093_1121321158" Archived-At: Subject: Re: [i2rs] [Gen-art] Genart last call review of draft-ietf-i2rs-rib-info-model-14 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 00:21:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3605793093_1121321158 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Alissa & Peter, =20 The issues were addressed in version 15 of the draft. =20 Nitin =20 From: Susan Hares Date: Thursday, April 5, 2018 at 6:52 AM To: 'Alissa Cooper' , 'Peter Yee' Cc: , , 'The IESG' , Subject: FW: [i2rs] [Gen-art] Genart last call review of draft-ietf-i2rs-ri= b-info-model-14 Resent-From: Resent-To: , , , , , , <= db3546@att.com>, , Susan Hares Resent-Date: Thu, 5 Apr 2018 06:52:41 -0700 (PDT) =20 Alissa: =20 Here=E2=80=99s Nitin=E2=80=99s response to Peter.=20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur Sent: Friday, March 23, 2018 2:55 AM To: peter@akayla.com Cc: i2rs@ietf.org Subject: Re: [i2rs] [Gen-art] Genart last call review of draft-ietf-i2rs-ri= b-info-model-14 =20 Hi Peter, =20 Thanks for the Gen-art review. Sorry it missed my attention back when= you sent it. Please see NB> below for comments. =20 =20 Reviewer: Peter Yee Review result: Ready with Issues =20 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. =20 For more information, please see the FAQ at ;. =20 Document: draft-ietf-i2rs-rib-info-model-14 Reviewer: Peter Yee Review Date: 2018-02-22 IETF LC End Date: 2018-02-23 IESG Telechat date: 2018-03-08 =20 Summary: This Informational draft specifies an information model for routin= g information bases, providing modeling of the internal information of a rout= er or similar network device. The draft is mostly ready, but has some issues = that should be considered. [Ready with issues] =20 Major issues: None =20 Minor issues: =20 Page 4, 3rd full paragraph, 1st sentence: the draft introduces the concept = of "RIB clients" in Figure 1, notes that they are generally routing protocols,= and then never uses the term again. All other references to the what must be t= he users of the northbound interface are then called "external entities" for t= he most part. This is confusing because the term "external entity" is not def= ined nor fully equated with "RIB client". The term also seems to indicate that = the "external entity" is not necessarily running on the network device. While = that might be one way of looking at the feeding of data into the RIB via NETCONF= or RESTCONF, that doesn't seem to be the case for a routing protocol. A fulle= r explanation of the users of the northbound interface and a revision to Figu= re 1 might help clarify this situation. =20 NB> You are right. I=E2=80=99m updating the draft to replace =E2=80=9Cexternal entities= =E2=80=9D to =E2=80=9CRIB client=E2=80=9D. =20 Page 7, 1st paragraph after bullet list, last sentence: Routing instances a= re identified by ROUTER_IDs anyhow, so this sentence seems superfluous.=20 Perhaps you are trying to get across the point that the ROUTER_ID (which is= definitely present for the router) is not *used* by this routing instance. =20 NB> That sentence was requested by some folks to ensure that ROUTER_ID base= d conflicts do not occur. =20 The term "ethernet" is used in several places in the document. Except in t= he grammar of section 6, change these to the capitalized "Ethernet".=20 =20 NB> Done =20 This brings up a larger point, however. Not all IEEE MAC addresses are ass= ociated with Ethernet interfaces and I believe this document is expected to be applicabl= e to other IEEE 802 MACs such as IEEE 802.11 (WLAN) and IEEE 802.15 (WPAN). IEE= E 802.15 has long and short forms of MAC addresses, so you may want to give s= ome additional thought to what you want to say with this term and pick somethin= g more appropriate. =20 NB> In Section 2.4.1, when talking about the IEEE MAC we say that =E2=80=9CThe eg= ress interface=20 must be an Ethernet interface.=E2=80=9D So the MAC is to be used only in the cont= ext of Ethernet interfaces. =20 NB> With regards to short and long form of MAC addresses, these should get = specified in the data-model,=20 since the data-model will need to validate things. =20 I think there's a discussion missing that may or may not be within scope of this document. RIBs appear to be typically divided according to the protoc= ol for which they are providing routing (IPv4, MPLS, etc.) Section 7.1 discus= ses routing preferences, with an example of OSPF route and a route from some ot= her protocol. When the OSPF route is withdrawn, the other route is installed i= n the FIB. What's not clear is what makes the decision to do this and cause = a specific RIB to push its route into the FIB. Is that the routing instance = or the RIB manager?=20 =20 NB> It should be the RIB manager. =20 A routing instance is described as a set of interfaces, RIBs, and routing parameters. It's description does not make it clear that it arbitrates among the RIBs or the routing protocols which are using the northbound interface to talk to the RIB manager. Figure 1 makes it seem li= ke there is a RIB manger per RIB, in which case how can the RIB manager make decisions between multiple RIBs? =20 NB> Good point. I=E2=80=99ll change the figure to indicate that the RIB manager h= andles 1 or more RIBs. =20 Page 14, Section 3, 2nd paragraph, 2nd sentence: a "connection" is mentione= d here. This document purports to deal with an API (and one that would mostl= y be used by local routing protocols if the figures are to be believed) and hasn= 't otherwise made any mention of a connection, let alone what constitutes a connection and defines its lifetime. More discussion is needed of this con= cept instead of just (possibly) resting the whole thing on brief mentions of NET= CONF and RESTCONF (which aren't even brought into the picture until the Security Considerations section later on in the document). =20 NB> Removed the sentence related to =E2=80=9Cconnection=E2=80=9D. You are right that th= is sentence causes more confusion and little value. =20 Page 15, 1st partial paragraph: there are unstated assumptions about needin= g a subscription mechanism for subscribing to notifications, particularly notifications from RIBs that were not created by the entity. (This goes ba= ck to the concept on the previous page that entities may possibly read to or w= rite from RIBs they did not create.) The discussion of notifications could use = some fleshing out here. =20 NB> How notifications are sent, whether using a subscription model or somet= hing else is left to the Data Model. And it=E2=80=99s left un-fleshed to allow the= data-model writers to decide what to do here. =20 Nits/editorial comments: =20 NB> I=E2=80=99m addressing all your nits in version 15. For nits not being addres= sed, see NB> below. =20 General: =20 Append a comma after "i.e." and "e.g." Make all uses of "e.g." lower case.= =20 Some uses of "e.g." have double spaces after them and those double spaces should be replaced with single spaces. =20 Change "use-cases" to "use cases" throughout the document. Or use the othe= r way around. Just be consistent in the usage. Non-hyphenate usage appears = to be preferred.. =20 Insert a blank line before and after bullet lists for readability. Conside= r adding a blank line between entries to aid readability as well. =20 Specific: =20 Page 1, Abstract, 2nd sentence: delete the semicolon. =20 Page 1, Abstract, 4th sentence: replace the space between "higher" and "lev= el" with a hyphen. =20 Page 3, Section 1, 2nd sentence: change "config" to "configuration informat= ion" (or something similar). =20 Page 3, Section 1, 3rd sentence: change "north-bound" to "northbound". App= end a comma after each of "clients", "i.e.", and "protocols". =20 Page 3, Figure 1 caption: append a comma after "clients". =20 Page 4, 1st partial paragraph, 1st complete sentence: change "which" to "th= at". Append a comma after "policies". =20 Page 4, 1st partial paragraph, 4th complete sentence: replace the space bet= ween "publicly" and "documented" with a hyphen and then append a comma after "publicly-documented". =20 Page 4, 2nd full paragraph, 1st sentence: I'm not sure what "show output sc= reen scraping" is. I'm familiar with screen scraping, but could not find a good source for your term. Perhaps you could explain or modify it? =20 NB> Modified it to =E2=80=9Cscreen scraping=E2=80=9D =20 Page 5, Section 1.1: you may wish to reference RFC 8174, which updates RFC = 2119 and makes it applicable across more than Standards Track documents. =20 NB> Done =20 Page 5, Section 2, 4th sentence: delete the comma after "single". =20 Page 5, Section 2, 5th sentence: make "Section" lower case. =20 Page 5, Section 2, 6th sentence: change the space between "high" and "level= " to a hyphen. =20 Page 5, Figure 2: remove the space between "routing-instance" and "(s)". =20 Page 5, Section 2.1, 3rd sentence: change "intance" to "instance". Also fi= x the sentence or Figure 2: the sentence says 1 or more RIBs, the diagram sho= ws 0 or more. I'm not sure how a zero RIB routing instance is useful, but make = the two ranges consistent. =20 NB> Updated =20 Page 6, 1st paragraph, 1st sentence: delete this sentence as it is redundan= t with information given in the previous paragraph on Page 5. =20 NB> While it is redundant, it adds clarity where the item is being defined. =20 Page 6, 2nd paragraph, 1st sentence: Change "a" to "an" before "ENABLE_IP_RPF_CHECK". Capitalize each word in "Reverse path forwarding". =20 Page 6, 2nd paragraph, 2nd sentence: delete "Reverse path forwarding", inse= rt the word "The" at the beginning of the sentence and remove the parentheses around "RPF". =20 Page 6, 2nd paragraph, 3rd and 4th sentences: change "rpf" to "RPF". =20 Page 6, Section 2.2, 1st paragraph, 3rd sentence: delete both semicolons. =20 Page 6, "interface-list" bullet item, 3rd sentence: I think it reads better with "in" inserted before "on". =20 Page 7, "ROUTER_ID" bullet item: change "router-id" to "ROUTER_ID". Or if = you want a descriptive term, change it to "router identification". =20 Page 8, MPLS bullet item: "change "a" to "an". =20 Page 8, paragraph after "route-vendor-attributes" bullet item, 1st sentence= : change "Nexthop" to "nexthop". =20 Page 9, 1st partial paragraph, 4th full sentence: change "a" to "an" before "MPLS". =20 Page 9, 1st partial paragraph, 7th full sentence: append a comma after "Conversely". Insert "the" before "case". =20 Page 10, 1st paragraph, 1st sentence: put a comma after "extensible". =20 Page 10, 1st paragraph, 5th sentence: change "it's" to "its". =20 Page 11, "EGRESS_INTERFACE" sub-bullet item: append a comma after "logical"= . =20 Page 11, "EGRESS_INTERFACE and IP address" sub-bullet item: append a comma after "cases". =20 Page 11, "Tunnel nexthops" bullet item: change "Various" to "The". =20 Page 11, "tunnel encap" sub-bullet item: change "tunnel encap" to "tunnel-encap" in the sub-bullet title to match Figure 4. Change "encap" t= o "encapsulation" in the first sentence. Change "tunnel encap" in the 2nd sentence to "tunnel-encap". =20 Page 11, "tunnel decap" sub-bullet item: change "tunnel decap" to "tunnel-decap" in the sub-bullet title to match Figure 4. Change "decap" t= o "decapsulation" in the second sentence. Change the "a" before "EGRESS_INTERFACE" to "an" in the third sentence. =20 Page 11, "logical tunnel" sub-bullet item: change "logical tunnel" to "logical-tunnel" in the sub-bullet title to match Figure 4. Change the "a" before "MPLS" to "an". =20 Page 11, last (partial) paragraph, 2nd partial sentence: change "end-point"= to "endpoint". =20 Page 12, Section 2.4.1.1, 1st sentence: change "drop" to "discard" to match= the following discussion. =20 Page 12, Section 2.4.2, 1st paragraph after bullet items, 1st sentence: del= ete the comma.. =20 Page 12, Section 2.4.2, 1st paragraph after bullet items, 3rd sentence: del= ete the comma. =20 Page 12, Section 2.4.2, 1st paragraph after bullet items, 6th sentence: cha= nge "and" to "or". Make "header" plural. =20 Page 13, Section 2.4.2.1, "NEXTHOP_PREFERENCE" bullet item, 4th sentence: insert "the" before "two". =20 Page 13, Section 2.4.2.1, "NEXTHOP_PREFERENCE" bullet item, last sentence: delete the asterisk and join "(Section 6)" with the rest of the sentence. =20 Page 14, Section 3, 1st paragraph, 1st sentence: delete the comma. =20 Page 14, Section 3, 2nd paragraph, 2nd sentence: change "agent" to "entity"= to at least be consistent with prior usage in the document. But also refer ba= ck to the issue listed above about use of the term "external entity". =20 Page 14, Section 4, 1st paragraph, 1st sentence: delete the comma. =20 Page 18, Section 6.1, 2nd sentence: append a comma after "preference". Cha= nge "multicasted" to "multicast" (the preferred form of the word). =20 Page 18, Section 7.2.1, last sentence: change "encap" to "encapsulation".=20 Change "decap" to "decapsulation". =20 Page 21, Section 7.2.6, 2nd sentence: delete the comma. =20 Page 21, Section 7.2.6, 5th sentence: change "Lets" to "Let's". =20 Page 23, Section 8, 2nd sentence: delete the comma. =20 Page 24, Section 11, 1st sentence: append a comma after "co-chair". Change= the first occurrence of "on" to "for". =20 Page 24, Section 11, 2nd sentence: append a comma after "Hares". Yeah, yea= h, I know, no one is going to require the Oxford comma here to figure out what t= he sentence means. ;-) =20 Thanks Nitin --B_3605793093_1121321158 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Alissa &= amp; Peter,

 

The issues were addressed in version 15 of the draft.

 <= /span>

Nitin=

 

From: Susan Hares <shares@ndzh.com>
= Date: Thursday, April 5, 2018 at 6:52 AM
To: 'Alissa Cooper' &= lt;alissa@cooperw.in>, 'Peter Yee' <peter@akayla.com>
Cc: <i2rs@ietf.org>, <gen-art@ietf.org>, 'The IESG' <iesg@ietf.o= rg>, <draft-ietf-i2rs-rib-info-model.all@ietf.org>
Subject: <= /b>FW: [i2rs] [Gen-art] Genart last call review of draft-ietf-i2rs-rib-info-= model-14
Resent-From: <alias-bounces@ietf.org>
Resent-= To: <nitin_bahadur@yahoo.com>, <sriganeshkini@gmail.com>, &l= t;jmedved@cisco.com>, <russ@riw.us>, <shares@ndzh.com>, <m= artin.vigoureux@nokia.com>, <db3546@att.com>, <aretana.ietf@gmai= l.com>, Susan Hares <shares@ndzh.com>
Resent-Date: Thu, 5= Apr 2018 06:52:41 -0700 (PDT)

 

Alissa:

 

Here=E2=80=99= s Nitin=E2=80=99s response to Peter.

 

Sue Hares

 

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahad= ur
Sent: Friday, March 23, 2018 2:55 AM
To: peter@akayla= .com
Cc: i2rs@ietf.org
Subject: Re: [i2rs] [Gen-art] Gen= art last call review of draft-ietf-i2rs-rib-info-model-14<= /span>

 

Hi Peter,

 

      Thanks for the Gen-art review= . Sorry it missed my attention back when you sent it. Please see NB> belo= w for comments.

 =

 

= 
Reviewer: P=
eter Yee
Review result: Ready with Issues
 
I am the assigned Gen-ART reviewer for this dr=
aft. The General Area
Review Team (Gen-ART) reviews all I=
ETF documents being processed
by the IESG for the IETF Ch=
air.  Please treat these comments just
like any othe= r last call comments.
 
For more =
information, please see the FAQ at
<https=
://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
&=
nbsp;
Document: draft-ietf-i2rs-rib-info-model-14<=
o:p>
Reviewer: Peter Yee
Review Date: 2018-02-22
IETF LC End Date: 2018-02-23
IESG Telec=
hat date: 2018-03-08
 
Summary: T=
his Informational draft specifies an information model for routing
information bases, providing modeling of the internal information =
of a router
or similar network device.  The draft is=
 mostly ready, but has some issues that
should be conside=
red. [Ready with issues]
 <=
/pre>
Major =
issues: None
 
Minor issues:
=
 
Page 4, 3rd full paragraph, 1st sen=
tence: the draft introduces the concept of
"RIB clie=
nts" in Figure 1, notes that they are generally routing protocols, and<=
/span>
then never uses the term again.  All other reference=
s to the what must be the
<=
span style=3D'font-family:Menlo;color:#333333'>users of the northbound interfa=
ce are then called "external entities" for the
=
most part.  This is confusing because the term "external entity&qu=
ot; is not defined
nor fully equated with "RIB clien=
t".  The term also seems to indicate that the
&=
quot;external entity" is not necessarily running on the network device.=
  While that
might be one way of looking at the feed=
ing of data into the RIB via NETCONF or
RESTCONF, that do=
esn't seem to be the case for a routing protocol.  A fuller=

explanation of the users of the northbound interface and a revision =
to Figure 1
might help clarify this situation.
 
NB> You are right. I=E2=80=99m updating the =
draft to replace =E2=80=9Cexternal entities=E2=80=9D to =E2=80=9CRIB client=E2=80=9D.
 
Page 7, 1st paragraph after bullet list, last=
 sentence: Routing instances are
identified by ROUTER_IDs=
 anyhow, so this sentence seems superfluous. 
=

Perhaps you=
 are trying to get across the point that the ROUTER_ID (which is definitely<=
/span>
present for the router) is not *used* by this routing ins=
tance.
 
NB> That sentence was=
 requested by some folks to ensure that ROUTER_ID based conflicts do not occ=
ur.
 
The term "ethernet&quo=
t; is used in several places in the document.  Except in the
grammar of section 6, change these to the capitalized "Etherne=
t". 
 
NB> Done
 
This brings up a larger point, however.=
  Not all IEEE MAC addresses are associated with
Eth=
ernet interfaces and I believe this document is expected to be applicable to=

other IEEE 802 MACs such as IEEE 802.11 (WLAN) and IEEE =
802.15 (WPAN).  IEEE
<=
span style=3D'font-family:Menlo;color:#333333'>802.15 has long and short forms=
 of MAC addresses, so you may want to give some
additiona=
l thought to what you want to say with this term and pick something
more appropriate.
 
NB=
> In Section 2.4.1, when talking about the IEEE MAC we say that =E2=80=9CThe eg=
ress interface 
must be an Ethernet interface.=E2=80=9D So the =
MAC is to be used only in the context of Ethernet interfaces.
 
NB> With regards to short and long form of=
 MAC addresses, these should get specified in the data-model, 
since the data-model will need to validate things.
=
 
I think there's a discussion missing that may or m=
ay not be within scope of
<=
span style=3D'font-family:Menlo;color:#333333'>this document.  RIBs appea=
r to be typically divided according to the protocol=

for w=
hich they are providing routing (IPv4, MPLS, etc.)  Section 7.1 discuss=
es
routing preferences, with an example of OSPF route and=
 a route from some other
protocol.  When the OSPF ro=
ute is withdrawn, the other route is installed in
the FIB=
.  What's not clear is what makes the decision to do this and cause a
specific RIB to push its route into the FIB.  Is that=
 the routing instance or
the RIB manager? 
 
NB> It should be the RIB manager.
 
 A routing instance is described as a s=
et of interfaces, RIBs,
and routing parameters.  It'=
s description does not make it clear that it
<=
pre style=3D'margin-bottom:7.5pt;background:white'>arbitrates a=
mong the RIBs or the routing protocols which are using the=

northbound interface to talk to the RIB manager.  Figure 1 makes it s=
eem like
there is a RIB manger per RIB, in which case how=
 can the RIB manager make
<=
span style=3D'font-family:Menlo;color:#333333'>decisions between multiple RIBs=
?
 
NB> Good point. I=E2=80=99ll cha=
nge the figure to indicate that the RIB manager handles 1 or more RIBs.
=
 
Page 14, Section 3, 2nd paragraph,=
 2nd sentence: a "connection" is mentioned
here=
.  This document purports to deal with an API (and one that would mostl=
y be
used by local routing protocols if the figures are t=
o be believed) and hasn't
<=
span style=3D'font-family:Menlo;color:#333333'>otherwise made any mention of a=
 connection, let alone what constitutes a
connection and =
defines its lifetime.  More discussion is needed of this concept=

instead of just (possibly) resting the whole thing on brief men=
tions of NETCONF
and RESTCONF (which aren't even brought =
into the picture until the Security
Considerations sectio=
n later on in the document).
 
NB=
> Removed the sentence related to =E2=80=9Cconnection=E2=80=9D. You are right that th=
is sentence causes more confusion and little value.=

 =
;
Page 15, 1st partial paragraph: there are unstated assu=
mptions about needing a
subscription mechanism for subscr=
ibing to notifications, particularly
notifications from R=
IBs that were not created by the entity.  (This goes back
to the concept on the previous page that entities may possibly read to=
 or write
from RIBs they did not create.)  The discu=
ssion of notifications could use some
fleshing out here.<=
/span>
 
<=
span style=3D'font-family:Menlo;color:#333333'>NB> How notifications are se=
nt, whether using a subscription model or something else is left to the Data=
 Model. And it=E2=80=99s left un-fleshed to allow the data-model writers to decide=
 what to do here.
 
Nits/editoria=
l comments:
 
NB> I=E2=80=99m addres=
sing all your nits in version 15. For nits not being addressed, see NB> b=
elow.
 
General:
 
Append a comma after "i.e."=
 and "e.g."  Make all uses of "e.g." lower case. 
Some uses of "e.g." have double spaces af=
ter them and those double spaces
should be replace=
d with single spaces.
<=
span style=3D'font-family:Menlo;color:#333333'> =

Ch=
ange "use-cases" to "use cases" throughout the document.=
  Or use the other
way around.  Just be =
consistent in the usage.  Non-hyphenate usage appears to
be preferred..
 
Insert a blank line before and after bullet lists for readability.  =
Consider
adding a blank line between entries to ai=
d readability as well.
=
 
S=
pecific:
 
Page 1, Abstrac=
t, 2nd sentence: delete the semicolon.
 <=
o:p>
Page 1, Abstract, 4th sentence: replace the space between &qu=
ot;higher" and "level"
with a hyphe=
n.
 
Page 3, Section 1, 2n=
d sentence: change "config" to "configuration information&quo=
t;
(or something similar).
=
 
Page 3, Section 1, 3rd sentence: change "n=
orth-bound" to "northbound".  Append
a comma after each of "clients", "i.e.", and &quo=
t;protocols".
 
Page =
3, Figure 1 caption: append a comma after "clients".
 
Page 4, 1st partial paragraph, 1st co=
mplete sentence: change "which" to "that".
 Append a comma after "policies".
 
Page 4, 1st partial paragraph, 4th complete=
 sentence: replace the space between
"publicl=
y" and "documented" with a hyphen and then append a comma aft=
er
"publicly-documented".
 
Page 4, 2nd full paragraph, 1st sentence:=
 I'm not sure what "show output screen
scraping"=
; is.  I'm familiar with screen scraping, but could not find a good
source for your term.  Perhaps you could explain or mod=
ify it?
 
NB> Modified it to =E2=
=80=9Cscreen scraping=E2=80=9D
 
Page 5, Se=
ction 1.1: you may wish to reference RFC 8174, which updates RFC 2119=

and makes it applicable across more than Standards Track docume=
nts.
 
NB> Done
 
Page 5, Section 2, 4th sentence: delete th=
e comma after "single".
 <=
/o:p>
Page 5, Section 2, 5th sentence: make "Section" lower ca=
se.
 
Page 5, Section 2, 6=
th sentence: change the space between "high" and "level"=
 to
a hyphen.
 =

Page 5, Figure 2: remove the space between "routing-ins=
tance" and "(s)".
 
Page 5, Section 2.1, 3rd sentence: change "intance" to &q=
uot;instance".  Also fix
the sentence or Figure 2: the sentence says 1 or more RIBs, the d=
iagram shows 0
or more.  I'm not sure how a zero RIB=
 routing instance is useful, but make the
two ranges cons= istent.
 
NB> Updated
 
Page 6, 1st paragraph, 1st sentence: de=
lete this sentence as it is redundant
with information gi=
ven in the previous paragraph on Page 5.
 
NB> While it is redundant, it adds clarity where the item is be=
ing defined.
 
Page 6, 2nd par=
agraph, 1st sentence: Change "a" to "an" before
=
"ENABLE_IP_RPF_CHECK".  Capitalize each wor=
d in "Reverse path forwarding".
= 
 
Page 6, 2nd paragraph, 2nd sentence: delete "Reverse=
 path forwarding", insert
the word "The&=
quot; at the beginning of the sentence and remove the parentheses=

around "RPF".
 = 
Page 6, 2nd paragraph, 3rd and 4th sentences: change "r=
pf" to "RPF".
 =

Page 6, Section 2.2, 1st paragraph, 3rd sentence: delete both semicolon=
s.
 
Page 6, "interfa=
ce-list" bullet item, 3rd sentence: I think it reads better<=
o:p>
with "in" inserted before "on".
<=
span style=3D'mso-bookmark:_MailOriginalBody'> 
Page 7, "ROUTER_ID" bul=
let item: change "router-id" to "ROUTER_ID".  Or if=
 you
want a descriptive term, change it to "r=
outer identification".
 <=
/span>
Page 8, MPLS bullet item: "change "a" to "an".<=
/span>
 
Page 8, paragraph after =
"route-vendor-attributes" bullet item, 1st sentence:
change "Nexthop" to "nexthop".
 
Page 9, 1st partial paragraph, 4th f=
ull sentence: change "a" to "an" before<=
/o:p>
"MPLS".
 <=
/span>
Page 9, 1st partial paragraph, 7th full sentence: append a comma after
"Conversely".  Insert "the"=
; before "case".
 
Page 10, 1st paragraph, 1st sentence: put a comma after "extensible&=
quot;.
 
Page 10, 1st para=
graph, 5th sentence: change "it's" to "its".<=
o:p>
 
Page 11, "EGRESS_INTERFACE&quo=
t; sub-bullet item: append a comma after "logical".
 
Page 11, "EGRESS_INTERFACE and IP=
 address" sub-bullet item: append a comma<=
/pre>
aft=
er "cases".
<=
span style=3D'font-family:Menlo;color:#333333'> =

Pa=
ge 11, "Tunnel nexthops" bullet item: change "Various" t=
o "The".
 
Page =
11, "tunnel encap" sub-bullet item: change "tunnel encap"=
; to
"tunnel-encap" in the sub-bullet ti=
tle to match Figure 4.  Change "encap" to
"encapsulation" in the first sentence.  Change "t=
unnel encap" in the 2nd
sentence to "tun=
nel-encap".
 
Page 11=
, "tunnel decap" sub-bullet item: change "tunnel decap" =
to
"tunnel-decap" in the sub-bullet titl=
e to match Figure 4.  Change "decap" to=

"decapsulation" in the second sentence.  Change the &quo=
t;a" before
"EGRESS_INTERFACE" to &=
quot;an" in the third sentence.
 
Page 11, "logical tunnel" sub-bullet item: change &qu=
ot;logical tunnel" to
"logical-tunnel&qu=
ot; in the sub-bullet title to match Figure 4.  Change the "a"=
;
before "MPLS" to "an".
 
Page 11, last (partial) parag=
raph, 2nd partial sentence: change "end-point" to<=
/o:p>
"endpoint".
 
Page 12, Section 2.4.1.1, 1st sentence: change "drop" to &=
quot;discard" to match the
following discussi=
on.
 
Page 12, Section 2.4=
.2, 1st paragraph after bullet items, 1st sentence: delete
the comma..
 <=
/pre>
Pag=
e 12, Section 2.4.2, 1st paragraph after bullet items, 3rd sentence: delete<=
/span>
the comma.
 
Page 12, Section 2.4.2, 1st paragraph after bullet items, 6th s=
entence: change
"and" to "or".=
  Make "header" plural.
 <=
o:p>
Page 13, Section 2.4.2.1, "NEXTHOP_PREFERENCE" bull=
et item, 4th sentence:
=
insert "the" befo=
re "two".
 
Page=
 13, Section 2.4.2.1, "NEXTHOP_PREFERENCE" bullet item, last sente=
nce:
delete the asterisk and join "(Section 6=
)" with the rest of the sentence.
 <=
o:p>
Page 14, Section 3, 1st paragraph, 1st sentence: delete the c=
omma.
 
Page 14, Section 3, 2=
nd paragraph, 2nd sentence: change "agent" to "entity" t=
o
at least be consistent with prior usage in the document=
.  But also refer back
to the issue listed above abo=
ut use of the term "external entity".
 
Page 14, Section 4, 1st paragraph, 1st sentence: delete =
the comma.
 
Page 18, Sect=
ion 6.1, 2nd sentence: append a comma after "preference".  Ch=
ange
"multicasted" to "multicast&qu=
ot; (the preferred form of the word).
 
Page 18, Section 7.2.1, last sentence: change "encap"=
; to "encapsulation". 
Change "deca=
p" to "decapsulation".
 
Page 21, Section 7.2.6, 2nd sentence: delete the comma.=

 
=
Page 21, Section 7.2.6, 5th se=
ntence: change "Lets" to "Let's".<=
/span>
 
Page 23, Section 8, 2nd sentence: delete the =
comma.
 
Page 24, Section =
11, 1st sentence: append a comma after "co-chair".  Change th=
e
first occurrence of "on" to "for&=
quot;.
 
Page 24, Section =
11, 2nd sentence: append a comma after "Hares".  Yeah, yeah, =
I
know, no one is going to require the Oxford comm=
a here to figure out what the
sentence means. ;-)<=
/span>
 
Thanks
=
Nitin
--B_3605793093_1121321158-- From nobody Sun Apr 8 00:43:31 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF24A127698; Sun, 8 Apr 2018 00:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 DepDaFImqChQ; Sun, 8 Apr 2018 00:43:28 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 CC44E127419; Sun, 8 Apr 2018 00:43:27 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E54CD4387C4F3; Sun, 8 Apr 2018 08:43:23 +0100 (IST) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 8 Apr 2018 08:43:25 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.73]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0361.001; Sun, 8 Apr 2018 15:43:21 +0800 From: Mach Chen To: Alvaro Retana , The IESG CC: "draft-ietf-i2rs-rib-data-model@ietf.org" , Susan Hares , "i2rs-chairs@ietf.org" , "shares@ndzh.com" , "i2rs@ietf.org" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) Thread-Index: AQHTyxuCrivRjxOHykODuFQsjcoqmaP2gnAg Date: Sun, 8 Apr 2018 07:43:21 +0000 Message-ID: References: <152273970691.14068.10044402717032917231.idtracker@ietfa.amsl.com> In-Reply-To: <152273970691.14068.10044402717032917231.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 07:43:30 -0000 SGkgQWx2YXJvLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cywgcGxlYXNlIHNlZSBteSByZXBs aWVzIGlubGluZS4uLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFs dmFybyBSZXRhbmEgW21haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tXQ0KPiBTZW50OiBUdWVz ZGF5LCBBcHJpbCAwMywgMjAxOCAzOjE1IFBNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y Zz4NCj4gQ2M6IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbEBpZXRmLm9yZzsgU3VzYW4g SGFyZXMgPHNoYXJlc0BuZHpoLmNvbT47DQo+IGkycnMtY2hhaXJzQGlldGYub3JnOyBzaGFyZXNA bmR6aC5jb207IGkycnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogQWx2YXJvIFJldGFuYSdzIE5vIE9i amVjdGlvbiBvbiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMTA6DQo+ICh3aXRoIENP TU1FTlQpDQo+IA0KPiBBbHZhcm8gUmV0YW5hIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFs bG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMTA6IE5v IE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVj dCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVj dG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBo dHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwN Cj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv c2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90 IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC8NCj4gDQo+IA0KPiANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAoMSkgIlRo aXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBmb3IgUm91dGluZyBJbmZvcm1h dGlvbiBCYXNlDQo+IChSSUIpIHRoYXQgYWxpZ25zIHdpdGggdGhlIEkyUlMgUklCIGluZm9ybWF0 aW9uIG1vZGVsLiIgIFRoYXQgYW5kIHRoZSBtdWx0aXBsZQ0KPiByZWZlcmVuY2VzIHRvIHRoZSBp bmZvcm1hdGlvbiBtb2RlbCAoaW4gdGhlIHRleHQgYW5kIG9uIHRoZSBlLW1haWwgYXJjaGl2ZSkN Cj4gbWFrZSBpdCBhIHJlcXVpcmVkIGRvY3VtZW50IHRvIHVuZGVyc3RhbmQgZm9yIHRoZSBpbXBs ZW1lbnRhdGlvbiBvZiB0aGUgZGF0YQ0KPiBtb2RlbC4gIGRyYWZ0LWlldGYtaTJycy1yaWItaW5m by1tb2RlbCBzaG91bGQgdGhlbiBiZSBhIE5vcm1hdGl2ZSByZWZlcmVuY2UuDQoNCkkgYW0gT0sg d2l0aCBpdC4NCg0KPiANCj4gSSBhbSBub3QgbWFraW5nIHRoaXMgcG9pbnQgYSBESVNDVVNTIGJl Y2F1c2UgSSB0aGluayBpdCBpcyBlYXN5IHRvIHNvbHZlOiBqdXN0DQo+IG1vdmUgdGhlIHJlZmVy ZW5jZS4NCj4gDQo+ICgyKSBJbiBGaWd1cmUgMTogcy9yb3V0ZS1yZWFzb24tZGVmaW5pdGlvbi9y b3V0ZS1jaGFuZ2UtcmVhc29uLWRlZmluaXRpb24NCg0KRG9uZS4NCg0KPiANCj4gKDMpIEZvciBj b21wbGV0ZW5lc3M6IGluIFMyLjMsIHRoZSBSZWFzb24gYXR0cmlidXRlIGlzIG1pc3NpbmcgKGZy b20gUzQgaW4gZHJhZnQtDQo+IGlldGYtaTJycy1yaWItaW5mby1tb2RlbCkuDQpBZGQgdGhlIGZv bGxvd2luZyBpdGVtOg0KDQoiUkVBU09OIC0gSW5kaWNhdGVzIHRoZSBzcGVjaWZpYyByZWFzb24g dGhhdCBjYXVzZXMgdGhlIGZhaWx1cmUsIEUuZy4gIE5vdCBhdXRob3JpemVkLiINCg0KSG9wZSB0 aGlzIGFkZHJlc3MgeW91ciBjb21tZW50cyENCg0KVGhhbmtzLA0KTWFjaA0KPiANCg0K From nobody Sun Apr 8 01:23:26 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7319A127775; Sun, 8 Apr 2018 01:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 UcsFW9Ak00io; Sun, 8 Apr 2018 01:23:16 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 4D64B126CE8; Sun, 8 Apr 2018 01:23:16 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 63127C6CCA45; Sun, 8 Apr 2018 09:23:12 +0100 (IST) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 8 Apr 2018 09:23:14 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.73]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0361.001; Sun, 8 Apr 2018 16:23:07 +0800 From: Mach Chen To: Alissa Cooper , The IESG CC: "i2rs@ietf.org" , "draft-ietf-i2rs-rib-data-model@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Thread-Topic: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) Thread-Index: AQHTy13moi2oBFWZPEShrejzOgw/4qP2htDA Date: Sun, 8 Apr 2018 08:23:07 +0000 Message-ID: References: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com> In-Reply-To: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 08:23:18 -0000 Hi Alissa, Thanks for your comments! Please see my responses inline... > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: Tuesday, April 03, 2018 11:10 PM > To: The IESG > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i2rs-chairs@i= etf.org; > shares@ndzh.com > Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-= model-10: > (with COMMENT) >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-i2rs-rib-data-model-10: No Objection >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > 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-i2rs-rib-data-model/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Sec 1.2: >=20 > "YANG tree diagrams provide a concise representation of a YANG module, > and SHOULD be included to help readers understand YANG module > structure." >=20 > This document does not seem like an appropriate place to have normative > guidance about this. And if this sentence is removed, I don't see the poi= nt of > including Section 1.2 otherwise. This would also imply deleting the refer= ence to > I-D.ietf-netmod-yang-tree-diagrams. This results from a YANG doctor review. I saw it also occurs in other publ= ished documents. I personally think it's no harm to keep it, how do you thi= nk? >=20 > Sec 2.1: Again here I'm confused about the use of normative language. Why= do > you need to specify normative requirements for what this very document is > specifying? Or are these supposed to be requirements on implementations? OK, how about this: "...a RIB data model needs to specify a way for an external entity to learn= about the functional capabilities of a network device." And=20 " The RIB data model needs a way to expose the nexthop chaining capability = supported by a given network device." >=20 > Sec 2.5: s/causes/caused/ Done The above updates will be reelected in version-11. Thanks, Mach >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Apr 8 01:27:30 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9221912785F; Sun, 8 Apr 2018 01:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 S_8XYkFXy03k; Sun, 8 Apr 2018 01:27:20 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 72454126CE8; Sun, 8 Apr 2018 01:27:20 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id BB67F854918D9; Sun, 8 Apr 2018 09:27:16 +0100 (IST) Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 8 Apr 2018 09:27:17 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.73]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0361.001; Sun, 8 Apr 2018 16:27:15 +0800 From: Mach Chen To: Susan Hares , 'Martin Bjorklund' CC: "suresh@kaloom.com" , "iesg@ietf.org" , "i2rs@ietf.org" , "draft-ietf-i2rs-rib-data-model@ietf.org" , "i2rs-chairs@ietf.org" Thread-Topic: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) Thread-Index: AQHTy87h6hOVGtpkHEuSuyT2shq+AKPxq9GAgAAE0YCAAACOAIAE3ZoQ Date: Sun, 8 Apr 2018 08:27:15 +0000 Message-ID: References: <152281674476.24011.1275548255371559292.idtracker@ietfa.amsl.com> <041501d3cce4$c7e59cc0$57b0d640$@ndzh.com> <20180405.160541.2135154939537620152.mbj@tail-f.com> <045901d3cce7$75cf54f0$616dfed0$@ndzh.com> In-Reply-To: <045901d3cce7$75cf54f0$616dfed0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 08:27:24 -0000 Thanks Suresh, Martin and Sue, The issues will be addressed in verion-11. Best regards, Mach > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Thursday, April 05, 2018 10:08 PM > To: 'Martin Bjorklund' > Cc: suresh@kaloom.com; iesg@ietf.org; i2rs@ietf.org; draft-ietf-i2rs-rib-= data- > model@ietf.org; i2rs-chairs@ietf.org > Subject: RE: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data= -model-10: > (with DISCUSS and COMMENT) >=20 > Martin: >=20 > Thank you for the proactive response on the types. I'll work with the > authors to change to these standard types. >=20 > Sue >=20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Thursday, April 5, 2018 10:06 AM > To: shares@ndzh.com > Cc: suresh@kaloom.com; iesg@ietf.org; i2rs@ietf.org; draft-ietf-i2rs-rib-= data- > model@ietf.org; i2rs-chairs@ietf.org > Subject: Re: [i2rs] Suresh Krishnan's Discuss on > draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) >=20 > Hi, >=20 > There are standard types for IPv6 flow label and for MAC addresses define= d in > RFC 6991: >=20 > inet:ipv6-flow-label > yang:mac-address >=20 >=20 > /martin >=20 >=20 > "Susan Hares" wrote: > > Suresh: > > > > Thank you for catching these issues. I missed these as a Shepherd (as > did > > the other reviewers) and AD. See my answers below. > > > > Would you or Martin hold a discuss until these critical issues are > > resolved and checked with the YANG doctors? I will work with the > > authors > to resolve > > these issues. This revision will take some time as we seek advice fro= m > the > > YANG doctors and from the community on the IEEE MAC Address being an > > index or a full MAC Address. > > > > Susan Hares > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Suresh Krishnan > > Sent: Wednesday, April 4, 2018 12:39 AM > > To: The IESG > > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; > > i2rs-chairs@ietf.org; shares@ndzh.com > > Subject: [i2rs] Suresh Krishnan's Discuss on > > draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT) > > > > Suresh Krishnan has entered the following ballot position for > > draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This model tries to squeeze the 20 bit IPv6 flow label into a 16 bit > field. > > This will result in a loss of data and needs to be fixed before the > > document is published. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > * Section 3 > > > > =3D> Under > > > > identity ipv6-decapsulation { > > > > it looks like the description is wrong ("IPv4 tunnel decapsulation.") > > ---- > > You are correct. It will be replaced with the following =3D=3D=3D=3D= =3D=3D=3D=3D=3D > > identity ipv6-decapsulation { > > base "tunnel-decapsulation-action"; > > description > > "IPv6 tunnel decapsulation."; > > } > > > > =3D> What use case is the ttl-action decrease-and-copy-to-inner used f= or? > > ---- > > Good catch! > > This feature may be used for tunnels (7.2.1 of > > draft-ietf-i2rs-rib-info-model) or nexthops chains (section 7.2.5 of > > draft-ietf-i2rs-rib-info-model). Good catch in that it does not provi= de > > enough detail in this version. > > > > We've had comments over the last years to put this level of detail in > > or out of the YANG model. I believe the latest wisdom from > > NETMOD/NETCONF is to put the level of detail back in > > > > =3D> Under case egress-interface-mac-nexthop { > > > > It is not clear to me how you fit a MAC address into a 32 bit space > > ,or am > I > > misreading this somehow and this is some form of index? > > > > Good Catch. > > > > Early on it was a holding place for a the official IEEE:MAC table, and > > should have been transferred to either the IEEE:MAC-ADDRESS (see page > > 17 RIB-INFO draft). However, this definitely needs to get fixed. I > > need to check with the YANG Doctors to determine which is the > > preferred fix for this reference at this time. I'm sure implementers > > have been using a fully qualified IEEE_MAC_ADDRESS or a reference to > > the > Table. > > > > High level - case points to an outgoing interface, ieee-mac address - > > > > case egress-interface-mac-nexthop { > > container egress-interface-mac-address { > > leaf outgoing-interface { > > type if:interface-ref; > > mandatory true; > > description > > "Name of the outgoing interface."; > > } > > leaf ieee-mac-address { > > type uint32; > > mandatory true; > > description > > "The nexthop points to an interface with > > a specific mac-address."; > > } > > description > > "The egress interface must be an Ethernet > > interface. Address resolution is not required > > for this nexthop."; > > } > > } > > > > It is not clear to me how you fit a MAC address into a 32 bit space > > ,or am I misreading this somehow and this is some form of index? > > > > " leaf ieee-mac-address { > > type uint32;" > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Sun Apr 8 02:18:03 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FC4126D05; Sun, 8 Apr 2018 02:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fQa2xS0QUVg7; Sun, 8 Apr 2018 02:18:01 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 D6F5D126BF6; Sun, 8 Apr 2018 02:18:00 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 75B4CAD55AE32; Sun, 8 Apr 2018 10:17:56 +0100 (IST) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 8 Apr 2018 10:17:58 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.73]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0361.001; Sun, 8 Apr 2018 17:17:52 +0800 From: Mach Chen To: Ignas Bagdonas , The IESG CC: "draft-ietf-i2rs-rib-data-model@ietf.org" , Susan Hares , "i2rs-chairs@ietf.org" , "shares@ndzh.com" , "i2rs@ietf.org" Thread-Topic: Ignas Bagdonas' No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) Thread-Index: AQHTzM9Gi70u1hx3oU2AojeJh2E5CqP2liuQ Date: Sun, 8 Apr 2018 09:17:51 +0000 Message-ID: References: <152292686099.25960.16142711099135250050.idtracker@ietfa.amsl.com> In-Reply-To: <152292686099.25960.16142711099135250050.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [i2rs] Ignas Bagdonas' No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 09:18:02 -0000 SGkgSWduYXMsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyENCg0KUGxlYXNlIHNlZSBteSBy ZXBsaWVzIGlubGluZS4uLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IElnbmFzIEJhZ2RvbmFzIFttYWlsdG86aWJhZ2RvbmFAZ21haWwuY29tXQ0KPiBTZW50OiBUaHVy c2RheSwgQXByaWwgMDUsIDIwMTggNzoxNCBQTQ0KPiBUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5v cmc+DQo+IENjOiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWxAaWV0Zi5vcmc7IFN1c2Fu IEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+Ow0KPiBpMnJzLWNoYWlyc0BpZXRmLm9yZzsgc2hhcmVz QG5kemguY29tOyBpMnJzQGlldGYub3JnDQo+IFN1YmplY3Q6IElnbmFzIEJhZ2RvbmFzJyBObyBP YmplY3Rpb24gb24gZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTEwOg0KPiAod2l0aCBD T01NRU5UKQ0KPiANCj4gSWduYXMgQmFnZG9uYXMgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBi YWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0xMDog Tm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJq ZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1 ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9k dWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRv IGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRt bA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQg cG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxs b3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLw0KPiANCj4gDQo+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEkyUlMg dXNlIGNhc2VzIGRvY3VtZW50IHNlZW1zIHRvIGJlIGFiYW5kb25lZCwgYW5kIGdlbmVyYWxseSB1 c2UgY2FzZQ0KPiBkb2N1bWVudHMgYmVzdCBmaXQgdGhlIHB1cnBvc2Ugb2YgdHJhY2tpbmcgdGhl IHdvcmsgb24gc3BlY2lmaWNhdGlvbiBkb2N1bWVudHMuDQo+IElzIHRoZSByZWZlcmVuY2UgcmVh bGx5IG5lZWRlZD8NCg0KSSBhbSBPSyB0byByZW1vdmUgaXQuDQoNCj4gDQo+IFBsZWFzZSBhZGRy ZXNzIFJURy1ESVIgY29tbWVudHMgb24gUklCL1JpYi9yaWIgY29uc2lzdGVuY3ksDQo+IGVuY2Fw L2VuY2Fwc3VsYXRpb24sIGRlY2FwL2RlY2Fwc3VsYXRpb24gY29uc2lzdGVueS4NCg0KT0ssIGRv bmUuDQoNCj4gDQo+IHMvbmV4dGhvcC1yZXBsaWNhdGVzL25leHRob3AtcmVwbGljYXRlLCBvciBj aGFuZ2UgdGhlIGRlc2NyaXB0aW9uIG9mIGJhc2UNCj4gbmV4dGhvcC4NCg0KT0ssIHMvbmV4dGhv cC1yZXBsaWNhdGVzL25leHRob3AtcmVwbGljYXRlLg0KDQoNCj4gDQo+IHMvYmxvdy9iZWxvdw0K DQpGaXhlZC4NCg0KPiANCj4gcy9WeExBTi9WWExBTiB0aHJvdWdob3V0IHRoZSBkb2N1bWVudC4N Cg0KRml4ZWQuDQoNCj4gDQo+IG5leHRob3AtbGItd2VpZ2h0LWRlZmluaXRpb246IGRpdmlkZWQg YnkgdGhlIHN1bSBvZiB3ZWlnaHRzLiBPciwgdG8gc2ltcGxpZnkgdGhlDQo+IHRleHQsIHJlcHJl c2VudGluZyBhIHByb3BvcnRpb24uIFZhbHVlIG9mIDAgaXMgbm90IGluIHRoZSByYW5nZS4NCg0K VGhpcyBpcyBhbGlnbiB3aXRoIHRoZSBjdXJyZW50IGluZm8gbW9kZWwgZGVzY3JpcHRpb24sIHdp bGwgZGlzY3VzcyB3aXRoIHRoZSBpbmZvIG1vZGVsIGF1dGhvcnMgdG8gYWRkcmVzcyBpdC4gDQoN ClRoYW5rcywNCk1hY2ggDQo+IA0KDQo= From nobody Sun Apr 8 02:37:24 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C985912785F; Sun, 8 Apr 2018 02:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-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 Ud1QZcuD8NYy; Sun, 8 Apr 2018 02:37:18 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 8E52F126BF6; Sun, 8 Apr 2018 02:37:17 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 045959AB77A8C; Sun, 8 Apr 2018 10:37:14 +0100 (IST) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 8 Apr 2018 10:37:15 +0100 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Sun, 8 Apr 2018 17:37:10 +0800 From: "Zhuangyan (Yan)" To: Ignas Bagdonas , Susan Hares , "'The IESG'" CC: "i2rs@ietf.org" , "draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org" , "i2rs-chairs@ietf.org" Thread-Topic: FW: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) Thread-Index: AQHTy0CXrYtKx6W5YEyUq6ube+k3t6Pv+e9ggABe60D//9vygIAANqcAgAW1kRA= Date: Sun, 8 Apr 2018 09:37:09 +0000 Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785A96BA222@nkgeml513-mbs.china.huawei.com> References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <9B4BC45FDEDDD84F813E9E4A5BAF8785A96B7310@nkgeml513-mbs.china.huawei.com> <01d801d3cc28$b5e18410$21a48c30$@ndzh.com> <9d743d24-e4b5-0bcc-eb7e-cdce3f464888@gmail.com> In-Reply-To: <9d743d24-e4b5-0bcc-eb7e-cdce3f464888@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.170.230] Content-Type: multipart/alternative; boundary="_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96BA222nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [i2rs] FW: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 09:37:22 -0000 --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96BA222nkgeml513mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSWduYXMsDQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZXMgYW5kIHNvcnJ5IGZvciB0aGUg ZGVsYXkgZHVlIHRvIGEgbG9jYWwgaG9saWRheS4gUGxlYXNlIHNlZSByZXBsaWVzIGlubGluZS4N Cg0KRnJvbTogSWduYXMgQmFnZG9uYXMgW21haWx0bzppYmFnZG9uYUBnbWFpbC5jb21dDQpTZW50 OiBUaHVyc2RheSwgQXByaWwgMDUsIDIwMTggMjozOCBBTQ0KVG86IFN1c2FuIEhhcmVzIDxzaGFy ZXNAbmR6aC5jb20+OyAnVGhlIElFU0cnIDxpZXNnQGlldGYub3JnPg0KQ2M6IGkycnNAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5QGlldGYu b3JnOyBpMnJzLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IEZXOiBJZ25hcyBCYWdkb25h cycgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29yay10b3Bv bG9neS0wODogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KDQoNCg0KT24gMDQvMDQvMjAx OCAxNjoyMiwgU3VzYW4gSGFyZXMgd3JvdGU6DQoNCklnbmFzOg0KDQoNCg0KSeKAmW0gZm9yd2Fy ZGluZyBZYW7igJlzIHNwZWNpZmljIGFuc3dlcnMgdG8gZWFjaCBvZiB5b3VyIHF1ZXN0aW9ucy4g SSBoYWQgaGVsZCB0aGlzIHJlc3BvbnNlIGJhY2sgdW50aWwgSSB0cmllZCB0byBsZWFybiBtb3Jl IGFib3V0IHdoYXQgc3BlY2lmaWMgcXVlc3Rpb25zIHdlcmUgdGFnIHdpdGggc3BlY2lmaWMgRElT Q1VTUyBxdWFsaXR5IGNvbW1lbnRzDQoNCnBlciB0aGUgSUVTRyAyMDE0IERJU0NVU1MgY3JpdGVy aWEgY29tbWVudHM6DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cvZGlzY3Vzcy1jcml0ZXJp YS1pZXNnLXJldmlldy8NCg0KDQoNCknigJltIHN1cmUgWWFuIHdpbGwgYmUgZ2xhZCB0byBtYWtl IGFkanVzdG1lbnRzIGluIHRoZSBkcmFmdCAoc2VlIGJlbG93KS4NCg0KVGhhbmsgeW91IFlhbiwg dGhpcyBzZWVtcyB0byBiZSBhIHByYWN0aWNhbCB3YXkgZm9yd2FyZCBpbiBicmluZ2luZyBjbGFy aXR5IHRvIHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQuDQoNCg0KDQoNCg0KWW91IHdpbGwgbm90 ZSB0aGF0IHlvdSBhcmUgYXNraW5nIHVzIHRvIHB1dCBiYWNrIGluIFJQQ3MgdGhhdCBvdGhlcnMg aGFkIHVzIHRha2Ugb3V0Lg0KDQpJIHdpbGwgbm90ZSB0aGF0IEkgYW0gbm90IGFza2luZyBmb3Ig YW55dGhpbmcgbGlrZSB0aGF0LiBQbGVhc2UgcmUtcmVhZCBteSBESVNDVVNTIG5vdGVzLg0KDQoN Cg0KDQoNClRoaXMgbGVhZHMgbWUgdG8gYmFjayB0byBteSBxdWVzdGlvbnMgYXMgYSBTaGVwaGVy ZC4gTXkgY29uY2VybiBpcyB0aGF0IG1hbnkgb2YgeW91ciByZXF1ZXN0ZWQgY2hhbmdlcw0KDQpJ IHJlY2FsbCByYWlzaW5nIHF1ZXN0aW9ucywgbm90IHJlcXVlc3RpbmcgY2hhbmdlcy4NCg0KDQoN CmFyZSBjb3VudGVyIHRvIGFncmVlbWVudHMgaW4gZGlzY3Vzc2lvbnMgd2l0aCBXRywgVEUgV0cs IE5FVENPTkYvTkVUTU9ELCBhbmQgcHJldmlvdXMgQURTIChPUFMsIFJURykgcmVnYXJkaW5nIEky UlMgZHJhZnRzLiAgIFNpbmNlIHRoZXNlIGRyYWZ0cyB3ZXJlIGRlbGF5ZWQgZHVlIHRvIHRoZSBy ZWFkaW5nIGxvYWQgb2YgdGhlIElFU0csIGl0IHNlZW1zIHdlIGFyZSB3b3JraW5nIHVuZGVyIGRp ZmZlcmVudCBydWxlcy4gIFNvLCBwbGVhc2Ugc3BlY2lmeSBob3cgeW91ciBjb21tZW50cyBtYXRj aCB0aGUgRElTQ1VTUyBjcml0ZXJpYS4gIElmIHlvdSBhcmUgc2V0dGluZyBuZXcgcnVsZXMgZm9y IEkyUlMgZG9jdW1lbnRzLCBwbGVhc2UgZGV0YWlsIHRoZSBuZXcgcnVsZXMgb2YgcmV2aWV3Lg0K DQoNCg0KSXQgaXMgdG9vIGJhZCB0aGF0IHdlIGNvdWxkIG5vdCBoYXZlIHJldmlld2VkIHRoZXNl IGRvY3VtZW50cyBkdXJpbmcgdGhlaXIgb3JpZ2luYWxseSBzY2hlZHVsZWQgdGVsZWNoYXQgd2l0 aCBwcmV2aW91cyAgQURzLg0KDQoNCg0KU3VzYW4gSGFyZXMNCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBJZ25hcyBCYWdkb25hcyBbbWFpbHRvOmliYWdkb25hQGdtYWls LmNvbV0NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDAzLCAyMDE4IDc6NDAgUE0NClRvOiBUaGUgSUVT RyA8aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+DQpDYzogZHJhZnQtaWV0Zi1p MnJzLXlhbmctZGMtZmFicmljLW5ldHdvcmstdG9wb2xvZ3lAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5QGlldGYub3JnPjsgU3Vz YW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj47IGkycnMt Y2hhaXJzQGlldGYub3JnPG1haWx0bzppMnJzLWNoYWlyc0BpZXRmLm9yZz47IHNoYXJlc0BuZHpo LmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPjsgaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0Bp ZXRmLm9yZz4NClN1YmplY3Q6IElnbmFzIEJhZ2RvbmFzJyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt aTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5LTA4OiAod2l0aCBESVNDVVNTIGFu ZCBDT01NRU5UKQ0KDQoNCg0KSWduYXMgQmFnZG9uYXMgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2lu ZyBiYWxsb3QgcG9zaXRpb24gZm9yDQoNCmRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1u ZXR3b3JrLXRvcG9sb2d5LTA4OiBEaXNjdXNzDQoNCg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRk cmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0 IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KDQoNCg0KUGxlYXNl IHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3Jp dGVyaWEuaHRtbA0KDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5k IENPTU1FTlQgcG9zaXRpb25zLg0KDQoNCg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBv dGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctZGMtZmFicmljLW5ldHdv cmstdG9wb2xvZ3kvDQoNCg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KRElTQ1VTUzoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCg0KSSBoYXZlIGNvbmNlcm5zIGFib3V0IHRoZSBwcmFjdGljYWwg dXNhYmlsaXR5IG9mIHRoaXMgcHJvcG9zZWQgbW9kZWwgYXMgaXQgaXMgc3BlY2lmaWVkIG5vdy4N Cg0KDQoNClRoZSBpbnRlbmRlZCBkZWNvdXBsaW5nIG9mIGZhYnJpYyBpbXBsZW1lbnRhdGlvbiBw cm9wZXJ0aWVzICh3aGF0IGlzIHRlcm1lZCBhcyAidW5kZXJsYXkgbmV0d29yayBpbmZyYXN0cnVj dHVyZSIgaW4gdGhlIGRvY3VtZW50KSBhbmQgaXRzIHRvcG9sb2d5IHNlZW1zIHRvIGJlIGNvbnRy YWRpY3RpbmcgdG8gZ2VuZXJhbCBvcGVyYXRpb25hbCBwcmFjdGljZXMgb2YgZmFicmljIGJhc2Vk IG5ldHdvcmtzLiBJdCBpcyBnZW5lcmFsbHkgdHJ1ZSBmb3IgdGhlIGNvbnRleHQgb2YgdGhlIG92 ZXJsYXkgYnV0IHRoYXQgaXMgbm90IHdoYXQgdGhlIGRvY3VtZW50IHNlZW1zIHRvIGJlIGZvY3Vz aW5nIG9uLiBGYWJyaWMgZGVmaW5lcyBhbmQgaW1wbGVtZW50cyB0aGUgdW5kZXJsYXksIG5vdCB0 aGUgb3RoZXIgd2F5IGFyb3VuZC4NCg0KW1ldIFRoZSBpbnRlbnRpb24gb2YgdGhpcyBtb2RlbCBp cyB0byByZXByZXNlbnQgdGhlIGVudGlyZSB0b3BvbG9neSBvZiBhIGRhdGEgY2VudGVyIGZhYnJp YyBuZXR3b3JrLg0KDQpZYW4sIGNhbiB5b3UgYmUgc3BlY2lmaWMgaGVyZSAtIHRoZSB0b3BvbG9n eSBvZiB3aGF0PyBBcmUgd2UgdGFsa2luZyBhYm91dCB0aGUgdW5kZXJsYXkgdG9wb2xvZ3ksIG9y IGFuIG92ZXJsYXkgaW5zdGFuY2UgdG9wb2xvZ3k/IFRoYXQgaXMgYSBtYWpvciBkaWZmZXJlbmNl IGFuZCBtYW55IG90aGVyIGNvbW1lbnRzIHdpbGwgZGVwZW5kIG9uIHRoaXMgYW5zd2VyLiBUaGUg dGVybWlub2xvZ3kgZG9lcyBub3QgaGVscCBoZXJlIHRvbyBtdWNoIC0gZGF0YSBjZW50ZXIgZmFi cmljIG5ldHdvcmsgbWF5IG1lYW4gbWFueSBkaWZmZXJlbnQgdGhpbmdzIGlmIHZpZXdlZCBmcm9t IGRpZmZlcmVudCBjb250ZXh0cy4NCg0KDQpbWV0gV2UgcHJvdmlkZSBhbiBlbnRpcmUgdG9wb2xv Z3kgZm9yIGEgZGMgZmFicmljLiBUaGlzIGZhYnJpYyBjb250YWlucyBzZXZlcmFsIFBPRHMgYXMg aXRzIOKAnG5vZGXigJ0sIGVhY2ggb2Ygd2hpY2ggaXMgY29tcG9zZWQgb2YgYSBzZXQgb2YgdW5k ZXJsYXkgbm9kZXMgKHdoaWNoIGFyZSBkZXZpY2Ugbm9kZXMpIGFuZCB0aGVpciBpbnRlcmNvbm5l Y3Rpb24gbGlua3MsIGFuZCBtYXkgaW1wbGVtZW50IGRpZmZlcmVudCBvdmVybGF5cy4gVGhlIGxp bmtzIG9mIHRoaXMgZmFicmljIGNhbiBiZSBjb25uZWN0aW9ucyBiZXR3ZWVuIFBPRHMsIGludGVy Y29ubmVjdGlvbnMgd2l0aGluIGEgUE9EIG9yIGNvbm5lY3Rpb25zIHRvIFdBTnMuDQoNCg0KVGhl IHdob2xlIG5ldHdvcmsgY2FuIGJlIGNvbnNpZGVyZWQgYXMgYSBzaW5nbGUgZmFicmljIG5ldHdv cmsgd2hpY2ggaXMgY29tcG9zZWQgYnkgc2V2ZXJhbCBQT0RzIGRlZmluZWQgYXMg4oCcbm9kZeKA nSBpbiB0aGlzIG1vZHVsZS4gVW5kZXIgdGhlc2Ug4oCcbm9kZXPigJ0sIHRoZXJlIGFyZSBzdXBw b3J0aW5nLW5vZGVzIChyZWZlcmVuY2UgdG8gZGV2aWNlLW5vZGVzIGJlbG9uZ2VkIHRvIHRoZSBQ T0QpIGFuZCBjb25uZWN0aW9ucy4NCg0KDQoNClRoZSB0ZXJtIG9mIFBPRC9mYWJyaWMgaXMgYSBi aXQgY29uZnVzaW5nIGluIHRoZSBkcmFmdC4gSG93IGFib3V0IHdlIHVwZGF0aW5nIHRoZSBUZXJt aW5vbG9neSBzZWN0aW9uIGFzIGJlbG93Pw0KDQpQT0Q6IGEgbW9kdWxlIG9mIG5ldHdvcmssIGNv bXB1dGUsIHN0b3JhZ2UsIGFuZCBhcHBsaWNhdGlvbiBjb21wb25lbnRzIHRoYXQgd29yayB0b2dl dGhlciB0byBkZWxpdmVyIG5ldHdvcmtpbmcgc2VydmljZXMuIEl0IHJlcHJlc2VudHMgYSByZXBl YXRhYmxlIGRlc2lnbiBwYXR0ZXJuLiBJdHMgY29tcG9uZW50cyBtYXhpbWl6ZSB0aGUgbW9kdWxh cml0eSwgc2NhbGFiaWxpdHksIGFuZCBtYW5hZ2VhYmlsaXR5IG9mIGRhdGEgY2VudGVycy4NCg0K RmFicmljOiBjb21wb3NlZCBvZiBzZXZlcmFsIFBPRHMgdG8gZm9ybSBhIGRhdGEgY2VudGVyIG5l dHdvcmsuDQoNCg0KDQpEb2VzIGl0IG1ha2Ugc2Vuc2U/DQoNCg0KSXQgaXMgY2xvc2VyIHRvIGJv dGggdGhlIHRlcm1pbm9sb2d5IGFuZCBkZXNpZ24gdXNlZCBpbiBhY3R1YWwgZGVwbG95bWVudHMu DQpbWV0gVGhhbmtzLiBXZSB3aWxsIGFkZCB0aGVzZSB0byB0aGUgdGVybWlub2xvZ3kgcGFydC4N Cg0KDQoNClRoZSBkb2N1bWVudCBkb2VzIG5vdCBjb250YWluIGEgc3VmZmljaWVudCBkZXNjcmlw dGlvbiBvZiB0aGUgbG9naWMgb2YgdGhlIG1vZGVsIGl0c2VsZiwgdGhlIHJlYXNvbnMgZm9yIGNo b2ljZXMgbWFkZSBmb3IgcmVwcmVzZW50YXRpb24gb2YgdHlwZXMgYW5kIGF0dHJpYnV0ZXMsIGFu ZCBhdCB0aGUgc2FtZSB0aW1lIGRlc2NyaXB0aW9ucyBpbiBtb2R1bGVzIGFyZSBzaW5nbGUgbGlu ZXMgdGhhdCBkbyBub3QgYWRkIGNsYXJpZmljYXRpb24gYmV5b25kIGJlaW5nIGNvcGllcyBvZiBs ZWFmIG5hbWVzLiBFaXRoZXIgdGhlcmUgbmVlZHMgdG8gYmUgYSBzZWN0aW9uIHRoYXQgZGVzY3Jp YmVzIHRoZSBsb2dpYyBvZiB0aGUgbW9kZWwgYW5kIGhvdyBpdCByZWxhdGVzIHRvIG90aGVyIG1v ZGVscywgYWxzbyBpbmNsdWRpbmcgZXhhbXBsZXMsIG9yIG1vZHVsZSBkZXNjcmlwdGlvbiBmaWVs ZHMgbmVlZCB0byBoYXZlIGVub3VnaCBjb250ZW50IHRvIGJlIGFibGUgdG8gaGF2ZSBlcXVpdmFs ZW50IHVuZGVyc3RhbmRpbmcgb2YgbW9kZWwgaW50ZW50IGFuZCBvcGVyYXRpb24uIEJvdGggYXJl IHN0cm9uZ2x5IGVuY291cmFnZWQsIGFzIGRlc2NyaXB0aW9ucyBoYXZlIHZhbHVlIG9mIGl0c2Vs ZiBmb3IgYmVpbmcgYSByZWZlcmVuY2UgZm9yIHVzZSwgYW5kIG1vZGVsIGRlc2NyaXB0aW9uIGlz IG5lZWRlZCBmb3IgdW5kZXJzdGFuZGluZyBob3cgdGhpcyBwYXJ0aWN1bGFyIG1vZGVsIGZpdHMg aW50byB0aGUgbGFyZ2VyIGhpZXJhcmNoeS4gTmV0d29yayBtYW5hZ2VtZW50IGRvZXMgbm90IGVu ZCBhdCB0aGUgYm91bmRhcnkgb2YgdGhlIHNpbmdsZSBkb21haW4tc3BlY2lmaWMgbW9kZWwsIGl0 IGlzIGltcG9ydGFudCB0byBidWlsZCBpdCBpbnRvIGEgd2hvbGUgc3lzdGVtLg0KDQoNCg0KV2h5 IFRFIHRvcG9sb2d5IG1vZGVsIGlzIG5vdCBzdWZmaWNpZW50IGZvciBtb2RlbGxpbmcgdGhlIHJl cHJlc2VudGF0aW9uIG9mIERDIGZhYnJpYz8gV2h5IGlzIERDIGZhYnJpYyBuZXR3b3JrIHRvcG9s b2d5IHNwZWNpYWwgY29tcGFyZWQgdG8gYW55IGdlbmVyaWMgZmFicmljIGJhc2VkIHRvcG9sb2d5 Pw0KDQpbWV0gV2UgZGlzY3Vzc2VkIHdpdGggVEUgdG9wb2xvZ3kgbW9kZWwgYXV0aG9ycyBhYm91 dCB0aGlzIHF1ZXN0aW9uLiBGb3IgVEUsIGl0IGlzIG1vcmUgZm9jdXNlZCBvbiBjb25uZWN0aW9u cyBmb3IgVEUgYW5kIHN0YXRpY3MgZm9yIHRoZWlyIHBlcmZvcm1hbmNlLCB3aGlsZSB0aGlzIG1v ZGVsIGlzIHRvIHByZXNlbnQgaG93IGEgZGF0YSBjZW50ZXIgbmV0d29yayBsb29rIGxpa2Ugd2l0 aCBpdHMgc3BlY2lmaWMgbm9kZXMobGVhZi9zcGluZSkuDQoNCkxlYWYvc3BpbmUgaXMgYSBub2Rl LCBub2RlcyBhcmUgaW50ZXJjb25uZWN0ZWQgYnkgbGlua3MuIERlcGVuZHMgb24gdGhlIGNvbnRl eHQgb2YgdGhlIGVhcmxpZXIgcXVlc3Rpb24gYWJvdXQgdGhlIHVuZGVybGF5IGFuZCBvdmVybGF5 LiBMaW5rcyBhbmQgbm9kZXMgY2FuIGRlZmluaXRlbHkgYmUgcmVwcmVzZW50ZWQgYnkgVEUgbW9k ZWwuIFdoYXQgaXMgYSBsZWFmL3NwaW5lIG5vZGUgaW4gdGhlIG92ZXJsYXkgY29udGV4dD8NCltZ XSBMZWFmL3NwaW5lIGlzIHRoZSByb2xlIG9mIGEgZGV2aWNlIG5vZGUgd2l0aGluIGEgcG9kLiBJ dCBpbmRpY2F0ZXMgaXRzIGZ1bmN0aW9ucy4gU3VjaCBhcywgZm9yIGRpc3RyaWJ1dGVkIEdXLCBp dCB3aWxsIGJlIGRlcGxveWVkIG9uIExFQUYgbm9kZS4NCg0KDQoNCg0KSG93IHRoaXMgbW9kZWwg Y291bGQgYmUgdXNlZCBmb3IgcmVwcmVzZW50aW5nIG1vcmUgdGhhbiB0d28gc3RhZ2UgZmFicmlj cyB0aGF0IGFyZSBpbiB3aWRlIGRlcGxveW1lbnQ/DQoNCltZXSBJbiB0aGF0IGNhc2UsIG1vcmUg cm9sZXMgZm9yIGludGVybGF5ZXIgZGV2aWNlcyBjYW4gYmUgYWRkZWQuIFRoZSDigJxyb2xl4oCd IGZvciBkZXZpY2UgaXMgZGVmaW5lZCBhcyBpZGVudGl0eS1yZWYuIE5ldyByb2xlcyBjYW4gYmUg YWRkZWQgYnkgZGVmaW5pbmcgbmV3IGlkZW50aXRpZXMuDQpUaGlzIG5lZWRzIHRvIGJlIGRvY3Vt ZW50ZWQuIE9yLCBpZiB5b3UgaW50ZW5kIHRvIGxpbWl0IHRoZSBzY29wZSB0byB0d28gc3RhZ2Vz IChhcyBpdCBpcyBpbXBsaWVkIGF0IHRoZSBtb21lbnQpIC0gdGhpcyBhbHNvIG5lZWRzIHRvIGJl IGV4cGxpY2l0bHkgc3RhdGVkIGluIHRoZSBkb2N1bWVudC4gV2hhdCBpcyBhbiBpbnRlcmxheWVy IGRldmljZT8NCltZXSBPaywgaXQgd2lsbCBiZSBhZGRlZCB0byB0aGUgZGVmaW5pdGlvbiBvZiBy b2xlLiBFcnLigKZhbiBpbnRlcmxheWVyIGRldmljZSBpcyBmb3Igb3RoZXIgbGF5ZXJzIGJlc2lk ZXMgU1BJTkUvTEVBRi4NCg0KDQoNCg0KTGltaXRpbmcgcG9ydCBiYW5kd2lkdGggdG8gYSBmaXhl ZCByYXRlIGlzIHRvbyByZXN0cmljdGl2ZS4gVGhlIG1vZGVsIGFzIHNwZWNpZmllZCBhbHJlYWR5 IGRvZXMgbm90IGNvdmVyIGEgc2V0IG9mIHBvcnQgc3BlZWRzIHRoYXQgYXJlIGluIGRlcGxveW1l bnQuDQoNCltZXSBiYW5kd2lkdGggaXMgZGVmaW5lZCBhcyBpZGVudGl0eS1yZWYuIE90aGVyIHNw ZWVkcyBjYW4gYmUgYWRkZWQgYnkgZGVmaW5pbmcgbmV3IGlkZW50aXRpZXMuDQoNCg0KTmVlZHMg dG8gYmUgZG9jdW1lbnRlZC4NCltZXSBPaywgaXQgd2lsbCBiZSBhZGRlZCB0byB0aGUgZGVmaW5p dGlvbiBvZiBiYW5kd2lkdGguDQoNCg0KDQpIb3cgd291bGQgYSBkZXZpY2UgdGhhdCBoYXMgbW9y ZSB0aGFuIGEgc2luZ2xlIHJvbGUgaW4gdGhlIGZhYnJpYyBiZSByZXByZXNlbnRlZD8NCg0KW1ld IFRoZSByb2xlIGZvciBhIGRldmljZS1ub2RlIGlzIGRlZmluZWQgYXMgbGVhZi1saXN0IHRvIHN1 cHBvcnQgYSBkZXZpY2Ugd2l0aCBtb3JlIHRoYW4gb25lIHJvbGVzLg0KDQoNCg0KU2VydmljZSBj YXBhYmlsaXRpZXMgYXMgdGhleSBhcmUgZGVzY3JpYmVkIGJlbG9uZyB0byB0aGUgb3ZlcmxheSBj b250ZXh0IHdoaWxlIHRoZXkgYXJlIGNhbGxlZCBkZXZpY2UgY2FwYWJpbGl0aWVzLiBBcmUgdGhv c2UgdGhlIG9ubHkgcG9zc2libGUgc2VydmljZSBjYXBhYmlsaXRpZXM/IFdoYXQgaXMgdGhlIGVm ZmVjdCBvZiBjb25maWd1cmluZyB0aG9zZSBjYXBhYmlsaXRpZXM/DQoNCltZXSBTZXJ2aWNlIGNh cGFiaWxpdGllcyBpcyBmb3IgYSBmYWJyaWMgbm90IGEgZGV2aWNlLiBUaGUgZGVzY3JpcHRpb24g Zm9yIHRoZSBzZXJ2aWNlIGNhcGFiaWxpdGllcyB3aWxsIGJlIGNvcnJlY3RlZC4gRm9yIGJldHRl ciBleHRlbnNpb24gZm9yIG90aGVyIHNlcnZpY2VzLCB3ZSB3aWxsIGNoYW5nZSBjdXJyZW50IGVu dW1lcmF0aW9uIHR5cGUgdG8gaWRlbnRpdHktcmVmLiBNb3JlIHNlcnZpY2UgaWRlbnRpdGllcyBj YW4gYmUgZGVmaW5lZCBpbiB0aGUgZnV0dXJlIGJ5IHZlbmRvcnMuDQpUaGUgZXh0ZW5zaWJpbGl0 eSBtZWNoYW5pc20gbmVlZHMgdG8gYmUgZG9jdW1lbnRlZC4NCltZXSBPaywgaXQgd2lsbCBiZSBh ZGRlZCB0byB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgc2VydmljZSBjYXBhYmlsaXR5Lg0KDQoNCg0K DQpXaGF0IGlzIGNvbXBvc2UtZmFicmljIFJQQz8gVGhlIGRvY3VtZW50IGRvZXMgbm90IGRlZmlu ZSBhbnkgUlBDcy4NCg0KW1ldIHJwY3Mgd2VyZSByZW1vdmVkIGluIHByZXZpb3VzIHZlcnNpb24g c2luY2UgcGVvcGxlIHNheSBpdCB3b3VsZCBsZWF2ZSBmb3IgdmVuZG9yLXNwZWNpZmljIGltcGxl bWVudGF0aW9uLg0KDQpUaGUgcnBjcyB0byBjb21wb3NlIGEgZmFicmljIGlzIGFzOg0KDQogICAg cnBjIGNvbXBvc2UtZmFicmljIHsNCg0KICAgICAgICBpbnB1dCB7DQoNCiAgICAgICAgICAgIHVz ZXMgZmFicmljLWF0dHJpYnV0ZXM7DQoNCiAgICAgICAgfQ0KDQogICAgICAgIG91dHB1dCB7DQoN CiAgICAgICAgICAgIGxlYWYgZmFicmljLWlkIHsNCg0KICAgICAgICAgICAgICAgIHR5cGUgZmFi cmljLWlkOw0KDQogICAgICAgICAgICB9DQoNCiAgICAgICAgfQ0KDQp9DQoNClRvIGFkZCBhIG5v ZGUgdG8gZmFicmljOg0KDQoNCg0KICAgIHJwYyBhZGQtbm9kZS10by1mYWJyaWMgew0KDQogICAg ICAgIGlucHV0IHsNCg0KICAgICAgICAgICAgbGVhZiBmYWJyaWMtaWQgew0KDQogICAgICAgICAg ICAgICAgdHlwZSBmYWJyaWMtaWQ7DQoNCiAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgdXNl cyBkZXZpY2UtYXR0cmlidXRlczsNCg0KICAgICAgICB9DQoNCiAgICB9DQoNCkRvIHlvdSBzdWdn ZXN0IHdlIGJyaW5nIGl0IGJhY2sgdG8gdGhlIGRyYWZ0Pw0KSSBhbSBub3Qgc3VnZ2VzdGluZyBh bnl0aGluZywgSSB3YXMgYXNraW5nIGFib3V0IHRoZSBjb21wb3NlLWZhYnJpYyBSUEMgdGhhdCB3 YXMgbWVudGlvbmVkIGluIHRoZSBkb2N1bWVudC4NCltZXSBXZSB3aWxsIGNsYXJpZnkgaXQgaW4g di0wOS4NCg0KDQoNCg0KDQoNCldoYXQgaXMgcG9saWN5IGRyaXZlbiB0cmFmZmljIGJlaGF2aW9y PyBJcyB0aGVyZSB0aGUgb25seSBvbmUgcG9saWN5IHRoYXQgZml0cyBhbGwgcG9zc2libGUgZGVw bG95bWVudCBzY2VuYXJpb3M/DQoNCltZXSBQb2xpY3kgaXMgbmVlZGVkIGZvciB0aGUgdHJhZmZp YyBvdGhlcndpc2UgdGhlIHRyYWZmaWMgd2lsbCBiZSBkaXNjYXJkLiBUaGVyZSBjYW4gYWxzbyBi ZSBub3JtYWwsIHdoaWNoIG1lYW5zIG5vIHBvbGljeSBpcyBuZWVkZWQgZm9yIGFsbCB0cmFmZmlj Lg0KDQoNCkl0IG5lZWRzIHRvIGJlIGRvY3VtZW50ZWQgb24gd2hhdCBpcyBtZWFudCBieSBwb2xp Y3kgLSB3aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoYXQgcG9saWN5LCB3aGVyZSBhbmQgaG93IGl0 IHNob3VsZCBiZSBpbnN0YW50aWF0ZWQuDQpbWV1JdCB3aWxsIGJlIGNsYXJpZmllZCBpbiB2LTA5 Lg0KDQoNCkxvb2tpbmcgYXQgdGhlIGhpc3Rvcnkgb2YgdGhlIGRvY3VtZW50IGZyb20gdGhlIGlu ZGl2aWR1YWwgc3VibWlzc2lvbiB0aW1lIGFuZCB0aGUgY29tbWVudHMgcmVjZWl2ZWQsIGl0IHNl ZW1zIHRoYXQgdGhlIHBvaW50IGZpeGVzIHRvIHRoZSB0ZXh0IHdlbnQgaW4gdG8gY292ZXIgdGhl IHNwZWNpZmljIGNvbW1lbnRzIGJ1dCBub3QgdG8gYWRkcmVzcyB0aGUgYnJvYWRlciBzY29wZSBv ZiBjb21tZW50cy4NCg0KVGhlIGRvY3VtZW50IHdvdWxkIGRlZmluaXRlbHkgYmVuZWZpdCBmcm9t IGEgbWFqb3IgcmV3cml0ZSBjbGFyaWZ5aW5nIHRoZSBsb2dpYyBiZWhpbmQgdGhlIGRlY2lzaW9u cyBtYWRlLCBhbGlnbmluZyBtb3JlIHdpdGggdGhlIG9wZXJhdGlvbmFsIHByYWN0aWNlIG9mIGZh YnJpYyBiYXNlZCBuZXR3b3JrIGRlc2lnbiBhbmQgZGVwbG95bWVudCwgYW5kIGJyaW5naW5nIHRo ZSBjb250ZW50IGluIFlBTkcgbW9kdWxlcyB0byBiZSBzZWxmLWRlc2NyaWJpbmcuDQoNCg0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpDT01NRU5UOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpGYWJy aWMgYW5kIFBPRCBhcmUgbm90IGVxdWl2YWxlbnQgdGVybXMuDQoNCg0KDQpJMlJTIHVzZSBjYXNl IHJlcXVpcmVtZW50cyBkb2N1bWVudCBoYXMgZXhwaXJlZCAxMSBtb250aHMgYWdvLiBVc2UgY2Fz ZXMgZG9jdW1lbnRzIGFyZSBnb29kIGZvciB0cmFja2luZyB0aGUgd29yayBwcm9ncmVzcyBvZiBz cGVjaWZpY2F0aW9uIGRvY3VtZW50cywgaXQgaXMgcXVlc3Rpb25hYmxlIHdoZXRoZXIgc3RhbmRh bG9uZSB1c2UgY2FzZXMgZG9jdW1lbnRzIHByb3ZpZGUgdmFsdWUgYmV5b25kIGhpc3RvcmljIHJl Y29yZC4gSXMgdGhlIHJlZmVyZW5jZSB0byBJMlJTIHVzZSBjYXNlcyBkb2N1bWVudCByZWFsbHkg bmVlZGVkPw0KDQpbWV0gVGhlIHJlZmVyZW5jZSB3aWxsIGJlIHJlbW92ZWQgaW4gdjA5Lg0KDQoN Cg0KV2hhdCBpcyBhdG9taWMgbmV0d29yaz8NCg0KW1ldIFRoZSBvcmlnaW5hbCBzZW50ZW5jZSBt aWdodCBiZSBjb25mdXNpbmcuIEhvdyBhYm91dCB3ZSBjaGFuZ2luZyBpdCB0byDigJxhIFBPRCBj YW4gYmUgY29uc2lkZXJlZCBhcyBhIGJhc2ljIHN0cnVjdHVyZSBmb3IgbWFuYWdlbWVudCBwdXJw b3Nlcy7igJ0/DQoNCg0KV2hhdCBpcyBhIGJhc2ljIHN0cnVjdHVyZSB0aGVuPyBJZiB0aGlzIGlz IGluIG92ZXJsYXkgY29udGV4dCB0aGVuIGl0IGlzIG5vdCBvYnZpb3VzIHdoYXQgUE9EIG1lYW5z IHRoZXJlLiBJZiB0aGlzIGlzIGluIHVuZGVybGF5IGNvbnRleHQgdGhlbiBjb25jZXB0dWFsbHkg aXQgaXMgY2xlYXIgYnV0IHF1aXRlIGZhciBhd2F5IGZyb20gb3BlcmF0aW9uYWwgcmVhbGl0eS4N CltZXSBJdCBpcyBhIHNldCBvZiBub2RlcyBhbmQgbGlua3Mgd2hpY2ggY29tcG9zZXMgYSBQT0Qg YW5kIGFsc28gc3VwcG9ydHMgYW4gb3ZlcmxheSBpbnN0YW5jZS4NCg0KDQpWTEFOIGlzIG5vdCBh IGZhYnJpYyBidWlsZGluZyB0ZWNobm9sb2d5IGFzIHN1Y2gsIHdoaWxlIEV0aGVybmV0IGlzLg0K DQoNCg0KV2hhdCBpcyB0aGUgbmVlZCBmb3IgVk5JIGNhcGFjaXR5IGxlYXZlcz8gV2hhdCBpcyB0 aGVpciBlZmZlY3QgaWYgY29uZmlndXJlZD8NCg0KW1ldIEl0IGlzIHVzZWQgdG8gc2F5IHRoZSBy YW5nZSBvZiB0aGUgVk5JcyBmb3IgYSBQT0QuIFdlIHdpbGwgdXBkYXRlIHRoZSBkZXNjcmlwdGlv biB0byBjbGFyaWZ5IGl0Lg0KDQoNCg0KVGhlIGRvY3VtZW50IGludGVybWl4ZXMgaWV0Zi1mYWJy aWMtKiBhbmQgaWV0Zi1kYy1mYWJyaWMtKiBuYW1lc3BhY2VzLg0KDQpbWV0gQXBvbG9naXplIGZv ciB0aGUgaW5jb25zaXN0ZW50LiBJdCB3aWxsIGJlIGNoYW5nZWQgdG8gaWV0Zi1kYy1mYWJyaWMt KiBpbiB2MDkuDQoNCg0KDQpTZXJpYWwgcG9ydC10eXBlIGlzIHByZXNlbnQgd2hpbGUgSW5maW5p YmFuZCBpcyBub3QgLSBJbmZpbmliYW5kIGJhc2VkIGZhYnJpY3MgYXJlIHdpZGVseSBkZXBsb3ll ZC4gV2hhdCBpcyB0aGUgZXh0ZW5zaWJpbGl0eSBtZWNoYW5pc20gZm9yIGFkZGluZyBpbiBuZXcg cG9ydCB0eXBlcz8NCg0KW1ldIFNpbmNlIHRoZSBwb3J0LXR5cGUgaXMgaWRlbnRpdHlyZWYsIG5l dyBwb3J0IHR5cGVzIGNhbiBiZSBhZGRlZCBieSBkZWZpbmluZyBuZXcgaWRlbnRpdGllcy4NClBs ZWFzZSBkb2N1bWVudCB0aGUgZXh0ZW5zaWJpbGl0eS4NCltZXSBPaywgd2Ugd2lsbCBkb2N1bWVu dCBpdCBpbiB0aGUgZGVmaW5pdGlvbiBvZiBwb3J0LXR5cGUuDQoNCg0KDQoNCklzIHRoZXJlIGFu eSBkZXBsb3ltZW50IGV4cGVyaWVuY2Ugd2l0aCB0aGlzIG1vZGVsPyBUaGUgT0RMIGZhYXMgcHJv amVjdCBoYXNuJ3QgZ290IG11Y2ggYWN0aXZpdHkgb3ZlciBsYXN0IHR3byB5ZWFycy4gQXJlIHlv dSBhd2FyZSBvZiBhbnkgb3RoZXIgaW1wbGVtZW50YXRpb25zIG9yIGRlcGxveW1lbnRzPw0KDQpb WV0gWWVzLCB0aGUgaW1wbGVtZW50YXRpb24gaXMgaW4gT0RMIEZBQVMuIEN1cnJlbnQgbW9kdWxl IGlzIGEgcGFydCBvZiBmYXNzIHByb2plY3QuIEl0IGhhcyBiZWVuIGRvbmUgb3ZlciB0d28geWVh cnMgYW5kIG9ubHkgbWFpbnRlbmFuY2UgaXMgbmVlZGVkLiBBbmQgd2UgdGhpbmsgaXQgaXMgc3Rh YmxlLg0KDQpHb29kLiBTbyB0aGlzIGluIGZhY3QgaXMgY2xvc2VyIHRvIEZBQVMgYW5kIHRoZXJl Zm9yZSB0aGUgY29udGV4dCBvZiB0aGUgZG9jdW1lbnQgaXMgdGhlIG92ZXJsYXkuIFRoZSBkb2N1 bWVudCBuZWVkcyB0byBzdGF0ZSB0aGF0IGNsZWFybHkuDQoNCk92ZXJhbGwgaXQgc2VlbXMgdGhh dCB3aGF0IGlzIG1pc3NpbmcgaW4gdGhlIGRvY3VtZW50IGlzIHRoZSBjb250ZXh0IGNsYXJpZmlj YXRpb24uIE9uY2UgdGhlIGNvbnRleHQgb2YgdGhpcyBtb2RlbCBpcyBjbGVhcmx5IGRlZmluZWQg dGhlIHJlc3Qgb2YgY29tbWVudHMgd2lsbCBiZSBlYXNpZXIgdG8gYWRkcmVzcy4NCg0KVGhhbmsg eW91Lg0KDQpJZ25hcw0KDQo= --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96BA222nkgeml513mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgWWFI ZWkgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9z ZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBN aWNyb3NvZnQgWWFIZWkgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6Ymxh Y2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5U ZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLnuq/mlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpwDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwg Q2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7 fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkNoYXIwDQoJe21zby1zdHlsZS1uYW1lOiLm ibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseToiTWljcm9zb2Z0IFlhSGVpIFVJ IixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnAuUGxhaW5UZXh0LCBsaS5QbGFpblRleHQs IGRpdi5QbGFpblRleHQNCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQiOw0KCW1zby1zdHls ZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxs b29uVGV4dCwgZGl2LkJhbGxvb25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQi Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkhpIElnbmFzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlcyBhbmQgc29ycnkgZm9yIHRoZSBkZWxheSBkdWUgdG8g YSBsb2NhbCBob2xpZGF5LiBQbGVhc2Ugc2VlIHJlcGxpZXMgaW5saW5lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IEln bmFzIEJhZ2RvbmFzIFttYWlsdG86aWJhZ2RvbmFAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBBcHJpbCAwNSwgMjAxOCAyOjM4IEFNPGJyPg0KPGI+VG86PC9iPiBTdXNh biBIYXJlcyAmbHQ7c2hhcmVzQG5kemguY29tJmd0OzsgJ1RoZSBJRVNHJyAmbHQ7aWVzZ0BpZXRm Lm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IGkycnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaTJycy15 YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5QGlldGYub3JnOyBpMnJzLWNoYWlyc0BpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogRlc6IElnbmFzIEJhZ2RvbmFzJyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5LTA4OiAo d2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiAwNC8wNC8yMDE4IDE2OjIyLCBTdXNhbiBIYXJlcyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+SWduYXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5J4oCZbSBmb3J3YXJkaW5nIFlhbuKAmXMgc3BlY2lmaWMgYW5zd2VycyB0 byBlYWNoIG9mIHlvdXIgcXVlc3Rpb25zLiBJIGhhZCBoZWxkIHRoaXMgcmVzcG9uc2UgYmFjayB1 bnRpbCBJIHRyaWVkIHRvIGxlYXJuIG1vcmUgYWJvdXQgd2hhdCBzcGVjaWZpYyBxdWVzdGlvbnMg d2VyZSB0YWcgd2l0aCBzcGVjaWZpYyBESVNDVVNTIHF1YWxpdHkgY29tbWVudHMNCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5wZXIgdGhlIElFU0cgMjAxNCBESVNDVVNTIGNyaXRlcmlhIGNvbW1lbnRzOg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cvZGlz Y3Vzcy1jcml0ZXJpYS1pZXNnLXJldmlldy8iPmh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cvZGlz Y3Vzcy1jcml0ZXJpYS1pZXNnLXJldmlldy88L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5J4oCZbSBzdXJlIFlhbiB3aWxsIGJlIGdsYWQgdG8gbWFrZSBhZGp1 c3RtZW50cyBpbiB0aGUgZHJhZnQgKHNlZSBiZWxvdykuJm5ic3A7DQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiPjxicj4NClRoYW5rIHlvdSBZYW4sIHRoaXMgc2VlbXMgdG8gYmUgYSBwcmFjdGljYWwg d2F5IGZvcndhcmQgaW4gYnJpbmdpbmcgY2xhcml0eSB0byB0aGUgc2NvcGUgb2YgdGhlIGRvY3Vt ZW50Lg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ WW91IHdpbGwgbm90ZSB0aGF0IHlvdSBhcmUgYXNraW5nIHVzIHRvIHB1dCBiYWNrIGluIFJQQ3Mg dGhhdCBvdGhlcnMgaGFkIHVzIHRha2Ugb3V0LiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi Pjxicj4NCkkgd2lsbCBub3RlIHRoYXQgSSBhbSBub3QgYXNraW5nIGZvciBhbnl0aGluZyBsaWtl IHRoYXQuIFBsZWFzZSByZS1yZWFkIG15IERJU0NVU1Mgbm90ZXMuDQo8YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhpcyBsZWFk cyBtZSB0byBiYWNrIHRvIG15IHF1ZXN0aW9ucyBhcyBhIFNoZXBoZXJkLiBNeSBjb25jZXJuIGlz IHRoYXQgbWFueSBvZiB5b3VyIHJlcXVlc3RlZCBjaGFuZ2VzDQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPjxicj4NCkkgcmVjYWxsIHJhaXNpbmcgcXVlc3Rpb25zLCBub3QgcmVxdWVzdGluZyBjaGFu Z2VzLiA8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5hcmUgY291bnRlciB0 byBhZ3JlZW1lbnRzIGluIGRpc2N1c3Npb25zIHdpdGggV0csIFRFIFdHLCBORVRDT05GL05FVE1P RCwgYW5kIHByZXZpb3VzIEFEUyAoT1BTLCBSVEcpIHJlZ2FyZGluZyBJMlJTIGRyYWZ0cy4mbmJz cDsgJm5ic3A7U2luY2UgdGhlc2UgZHJhZnRzIHdlcmUgZGVsYXllZCBkdWUgdG8gdGhlIHJlYWRp bmcgbG9hZCBvZiB0aGUgSUVTRywgaXQgc2VlbXMgd2UNCiBhcmUgd29ya2luZyB1bmRlciBkaWZm ZXJlbnQgcnVsZXMuICZuYnNwO1NvLCBwbGVhc2Ugc3BlY2lmeSBob3cgeW91ciBjb21tZW50cyBt YXRjaCB0aGUgRElTQ1VTUyBjcml0ZXJpYS4mbmJzcDsgSWYgeW91IGFyZSBzZXR0aW5nIG5ldyBy dWxlcyBmb3IgSTJSUyBkb2N1bWVudHMsIHBsZWFzZSBkZXRhaWwgdGhlIG5ldyBydWxlcyBvZiBy ZXZpZXcuICZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+SXQgaXMgdG9vIGJhZCB0aGF0IHdlIGNvdWxkIG5vdCBoYXZlIHJldmlld2VkIHRoZXNl IGRvY3VtZW50cyBkdXJpbmcgdGhlaXIgb3JpZ2luYWxseSBzY2hlZHVsZWQgdGVsZWNoYXQgd2l0 aCBwcmV2aW91cyAmbmJzcDtBRHMuJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlN1c2FuIEhhcmVzIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IElnbmFzIEJhZ2RvbmFzIFs8YSBocmVmPSJtYWlsdG86 aWJhZ2RvbmFAZ21haWwuY29tIj5tYWlsdG86aWJhZ2RvbmFAZ21haWwuY29tPC9hPl0NCjxicj4N ClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDAzLCAyMDE4IDc6NDAgUE08YnI+DQpUbzogVGhlIElFU0cg Jmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPiZndDs8 YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1u ZXR3b3JrLXRvcG9sb2d5QGlldGYub3JnIj5kcmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJyaWMt bmV0d29yay10b3BvbG9neUBpZXRmLm9yZzwvYT47IFN1c2FuIEhhcmVzICZsdDs8YSBocmVmPSJt YWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9 Im1haWx0bzppMnJzLWNoYWlyc0BpZXRmLm9yZyI+aTJycy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8 YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj4NCnNoYXJlc0BuZHpoLmNvbTwvYT47IDxh IGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPjxicj4NClN1Ympl Y3Q6IElnbmFzIEJhZ2RvbmFzJyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZh YnJpYy1uZXR3b3JrLXRvcG9sb2d5LTA4OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JZ25hcyBCYWdkb25hcyBoYXMgZW50ZXJlZCB0aGUg Zm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPmRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9s b2d5LTA4OiBEaXNjdXNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldoZW4gcmVzcG9u ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFs bCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwg ZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5QbGVhc2UgcmVmZXIgdG8gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIj4NCjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9y Zy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJl IGZvdW5kIGhlcmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFu Zy1kYy1mYWJyaWMtbmV0d29yay10b3BvbG9neS8iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29yay10b3BvbG9neS88L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+RElTQ1VTUzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBoYXZlIGNv bmNlcm5zIGFib3V0IHRoZSBwcmFjdGljYWwgdXNhYmlsaXR5IG9mIHRoaXMgcHJvcG9zZWQgbW9k ZWwgYXMgaXQgaXMgc3BlY2lmaWVkIG5vdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ VGhlIGludGVuZGVkIGRlY291cGxpbmcgb2YgZmFicmljIGltcGxlbWVudGF0aW9uIHByb3BlcnRp ZXMgKHdoYXQgaXMgdGVybWVkIGFzICZxdW90O3VuZGVybGF5IG5ldHdvcmsgaW5mcmFzdHJ1Y3R1 cmUmcXVvdDsgaW4gdGhlIGRvY3VtZW50KSBhbmQgaXRzIHRvcG9sb2d5IHNlZW1zIHRvIGJlIGNv bnRyYWRpY3RpbmcgdG8gZ2VuZXJhbCBvcGVyYXRpb25hbCBwcmFjdGljZXMgb2YgZmFicmljIGJh c2VkIG5ldHdvcmtzLiBJdA0KIGlzIGdlbmVyYWxseSB0cnVlIGZvciB0aGUgY29udGV4dCBvZiB0 aGUgb3ZlcmxheSBidXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgZG9jdW1lbnQgc2VlbXMgdG8gYmUg Zm9jdXNpbmcgb24uIEZhYnJpYyBkZWZpbmVzIGFuZCBpbXBsZW1lbnRzIHRoZSB1bmRlcmxheSwg bm90IHRoZSBvdGhlciB3YXkgYXJvdW5kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+W1ldIFRoZSBpbnRlbnRpb24gb2YgdGhp cyBtb2RlbCBpcyB0byByZXByZXNlbnQgdGhlIGVudGlyZSB0b3BvbG9neSBvZiBhIGRhdGEgY2Vu dGVyIGZhYnJpYyBuZXR3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KWWFuLCBjYW4g eW91IGJlIHNwZWNpZmljIGhlcmUgLSB0aGUgdG9wb2xvZ3kgb2Ygd2hhdD8gQXJlIHdlIHRhbGtp bmcgYWJvdXQgdGhlIHVuZGVybGF5IHRvcG9sb2d5LCBvciBhbiBvdmVybGF5IGluc3RhbmNlIHRv cG9sb2d5PyBUaGF0IGlzIGEgbWFqb3IgZGlmZmVyZW5jZSBhbmQgbWFueSBvdGhlciBjb21tZW50 cyB3aWxsIGRlcGVuZCBvbiB0aGlzIGFuc3dlci4gVGhlIHRlcm1pbm9sb2d5IGRvZXMgbm90IGhl bHAgaGVyZSB0b28gbXVjaCAtIGRhdGENCiBjZW50ZXIgZmFicmljIG5ldHdvcmsgbWF5IG1lYW4g bWFueSBkaWZmZXJlbnQgdGhpbmdzIGlmIHZpZXdlZCBmcm9tIGRpZmZlcmVudCBjb250ZXh0cy4N Cjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEIj5bWV0gV2UgcHJvdmlkZSBh biBlbnRpcmUgdG9wb2xvZ3kgZm9yIGEgZGMgZmFicmljLiBUaGlzIGZhYnJpYyBjb250YWlucyBz ZXZlcmFsIFBPRHMgYXMgaXRzIOKAnG5vZGXigJ0sIGVhY2ggb2Ygd2hpY2ggaXMgY29tcG9zZWQg b2YgYSBzZXQgb2YgdW5kZXJsYXkgbm9kZXMgKHdoaWNoDQogYXJlIGRldmljZSBub2RlcykgYW5k IHRoZWlyIGludGVyY29ubmVjdGlvbiBsaW5rcywgYW5kIG1heSBpbXBsZW1lbnQgZGlmZmVyZW50 IG92ZXJsYXlzLiBUaGUgbGlua3Mgb2YgdGhpcyBmYWJyaWMgY2FuIGJlIGNvbm5lY3Rpb25zIGJl dHdlZW4gUE9EcywgaW50ZXJjb25uZWN0aW9ucyB3aXRoaW4gYSBQT0Qgb3IgY29ubmVjdGlvbnMg dG8gV0FOcy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpyZWQiPlRoZSB3aG9sZSBuZXR3b3JrIGNhbiBiZSBjb25zaWRlcmVkIGFzIGEgc2luZ2xlIGZh YnJpYyBuZXR3b3JrIHdoaWNoIGlzIGNvbXBvc2VkIGJ5IHNldmVyYWwgUE9EcyBkZWZpbmVkIGFz IOKAnG5vZGXigJ0gaW4gdGhpcyBtb2R1bGUuIFVuZGVyIHRoZXNlIOKAnG5vZGVz4oCdLCB0aGVy ZSBhcmUgc3VwcG9ydGluZy1ub2RlcyAocmVmZXJlbmNlIHRvIGRldmljZS1ub2RlcyBiZWxvbmdl ZA0KIHRvIHRoZSBQT0QpIGFuZCBjb25uZWN0aW9ucy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5UaGUgdGVybSBvZiBQT0QvZmFicmljIGlzIGEg Yml0IGNvbmZ1c2luZyBpbiB0aGUgZHJhZnQuIEhvdyBhYm91dCB3ZSB1cGRhdGluZyB0aGUgVGVy bWlub2xvZ3kgc2VjdGlvbiBhcyBiZWxvdz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5QT0Q6IGEgbW9kdWxlIG9m IG5ldHdvcmssIGNvbXB1dGUsIHN0b3JhZ2UsIGFuZCBhcHBsaWNhdGlvbiBjb21wb25lbnRzIHRo YXQgd29yayB0b2dldGhlciB0byBkZWxpdmVyIG5ldHdvcmtpbmcgc2VydmljZXMuIEl0IHJlcHJl c2VudHMgYSByZXBlYXRhYmxlIGRlc2lnbiBwYXR0ZXJuLiBJdHMgY29tcG9uZW50cyBtYXhpbWl6 ZSB0aGUgbW9kdWxhcml0eSwgc2NhbGFiaWxpdHksDQogYW5kIG1hbmFnZWFiaWxpdHkgb2YgZGF0 YSBjZW50ZXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZhYnJpYzogY29tcG9zZWQgb2Ygc2V2ZXJhbCBQT0Rz IHRvIGZvcm0gYSBkYXRhIGNlbnRlciBuZXR3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpyZWQiPkRvZXMgaXQgbWFrZSBzZW5zZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SXQgaXMgY2xvc2VyIHRv IGJvdGggdGhlIHRlcm1pbm9sb2d5IGFuZCBkZXNpZ24gdXNlZCBpbiBhY3R1YWwgZGVwbG95bWVu dHMuDQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPltZXSBU aGFua3MuIFdlIHdpbGwgYWRkIHRoZXNlIHRvIHRoZSB0ZXJtaW5vbG9neSBwYXJ0Ljwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGRvY3VtZW50IGRvZXMgbm90IGNvbnRh aW4gYSBzdWZmaWNpZW50IGRlc2NyaXB0aW9uIG9mIHRoZSBsb2dpYyBvZiB0aGUgbW9kZWwgaXRz ZWxmLCB0aGUgcmVhc29ucyBmb3IgY2hvaWNlcyBtYWRlIGZvciByZXByZXNlbnRhdGlvbiBvZiB0 eXBlcyBhbmQgYXR0cmlidXRlcywgYW5kIGF0IHRoZSBzYW1lIHRpbWUgZGVzY3JpcHRpb25zIGlu IG1vZHVsZXMgYXJlIHNpbmdsZSBsaW5lcyB0aGF0IGRvIG5vdA0KIGFkZCBjbGFyaWZpY2F0aW9u IGJleW9uZCBiZWluZyBjb3BpZXMgb2YgbGVhZiBuYW1lcy4gRWl0aGVyIHRoZXJlIG5lZWRzIHRv IGJlIGEgc2VjdGlvbiB0aGF0IGRlc2NyaWJlcyB0aGUgbG9naWMgb2YgdGhlIG1vZGVsIGFuZCBo b3cgaXQgcmVsYXRlcyB0byBvdGhlciBtb2RlbHMsIGFsc28gaW5jbHVkaW5nIGV4YW1wbGVzLCBv ciBtb2R1bGUgZGVzY3JpcHRpb24gZmllbGRzIG5lZWQgdG8gaGF2ZSBlbm91Z2ggY29udGVudCB0 byBiZSBhYmxlIHRvDQogaGF2ZSBlcXVpdmFsZW50IHVuZGVyc3RhbmRpbmcgb2YgbW9kZWwgaW50 ZW50IGFuZCBvcGVyYXRpb24uIEJvdGggYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQsIGFzIGRlc2Ny aXB0aW9ucyBoYXZlIHZhbHVlIG9mIGl0c2VsZiBmb3IgYmVpbmcgYSByZWZlcmVuY2UgZm9yIHVz ZSwgYW5kIG1vZGVsIGRlc2NyaXB0aW9uIGlzIG5lZWRlZCBmb3IgdW5kZXJzdGFuZGluZyBob3cg dGhpcyBwYXJ0aWN1bGFyIG1vZGVsIGZpdHMgaW50byB0aGUgbGFyZ2VyDQogaGllcmFyY2h5LiBO ZXR3b3JrIG1hbmFnZW1lbnQgZG9lcyBub3QgZW5kIGF0IHRoZSBib3VuZGFyeSBvZiB0aGUgc2lu Z2xlIGRvbWFpbi1zcGVjaWZpYyBtb2RlbCwgaXQgaXMgaW1wb3J0YW50IHRvIGJ1aWxkIGl0IGlu dG8gYSB3aG9sZSBzeXN0ZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldoeSBURSB0 b3BvbG9neSBtb2RlbCBpcyBub3Qgc3VmZmljaWVudCBmb3IgbW9kZWxsaW5nIHRoZSByZXByZXNl bnRhdGlvbiBvZiBEQyBmYWJyaWM/IFdoeSBpcyBEQyBmYWJyaWMgbmV0d29yayB0b3BvbG9neSBz cGVjaWFsIGNvbXBhcmVkIHRvIGFueSBnZW5lcmljIGZhYnJpYyBiYXNlZCB0b3BvbG9neT88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpy ZWQiPltZXSBXZSBkaXNjdXNzZWQgd2l0aCBURSB0b3BvbG9neSBtb2RlbCBhdXRob3JzIGFib3V0 IHRoaXMgcXVlc3Rpb24uIEZvciBURSwgaXQgaXMgbW9yZSBmb2N1c2VkIG9uIGNvbm5lY3Rpb25z IGZvciBURSBhbmQgc3RhdGljcyBmb3IgdGhlaXIgcGVyZm9ybWFuY2UsIHdoaWxlIHRoaXMgbW9k ZWwgaXMgdG8gcHJlc2VudCBob3cgYSBkYXRhIGNlbnRlciBuZXR3b3JrDQogbG9vayBsaWtlIHdp dGggaXRzIHNwZWNpZmljIG5vZGVzKGxlYWYvc3BpbmUpLiA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi Pjxicj4NCkxlYWYvc3BpbmUgaXMgYSBub2RlLCBub2RlcyBhcmUgaW50ZXJjb25uZWN0ZWQgYnkg bGlua3MuIERlcGVuZHMgb24gdGhlIGNvbnRleHQgb2YgdGhlIGVhcmxpZXIgcXVlc3Rpb24gYWJv dXQgdGhlIHVuZGVybGF5IGFuZCBvdmVybGF5LiBMaW5rcyBhbmQgbm9kZXMgY2FuIGRlZmluaXRl bHkgYmUgcmVwcmVzZW50ZWQgYnkgVEUgbW9kZWwuIFdoYXQgaXMgYSBsZWFmL3NwaW5lIG5vZGUg aW4gdGhlIG92ZXJsYXkgY29udGV4dD8NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7 Y29sb3I6IzFGNDk3RCI+W1ldIExlYWYvc3BpbmUgaXMgdGhlIHJvbGUgb2YgYSBkZXZpY2Ugbm9k ZSB3aXRoaW4gYSBwb2QuIEl0IGluZGljYXRlcyBpdHMgZnVuY3Rpb25zLiBTdWNoIGFzLCBmb3Ig ZGlzdHJpYnV0ZWQgR1csIGl0IHdpbGwgYmUgZGVwbG95ZWQgb24gTEVBRiBub2RlLjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5Ib3cgdGhpcyBtb2RlbCBjb3VsZCBiZSB1c2VkIGZvciByZXByZXNlbnRp bmcgbW9yZSB0aGFuIHR3byBzdGFnZSBmYWJyaWNzIHRoYXQgYXJlIGluIHdpZGUgZGVwbG95bWVu dD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpyZWQiPltZXSBJbiB0aGF0IGNhc2UsIG1vcmUgcm9sZXMgZm9yIGludGVybGF5ZXIgZGV2 aWNlcyBjYW4gYmUgYWRkZWQuIFRoZSDigJxyb2xl4oCdIGZvciBkZXZpY2UgaXMgZGVmaW5lZCBh cyBpZGVudGl0eS1yZWYuIE5ldyByb2xlcyBjYW4gYmUgYWRkZWQgYnkgZGVmaW5pbmcgbmV3IGlk ZW50aXRpZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5UaGlzIG5lZWRzIHRvIGJlIGRvY3VtZW50 ZWQuIE9yLCBpZiB5b3UgaW50ZW5kIHRvIGxpbWl0IHRoZSBzY29wZSB0byB0d28gc3RhZ2VzIChh cyBpdCBpcyBpbXBsaWVkIGF0IHRoZSBtb21lbnQpIC0gdGhpcyBhbHNvIG5lZWRzIHRvIGJlIGV4 cGxpY2l0bHkgc3RhdGVkIGluIHRoZSBkb2N1bWVudC4NCiBXaGF0IGlzIGFuIGludGVybGF5ZXIg ZGV2aWNlPyA8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPltZ XSBPaywgaXQgd2lsbCBiZSBhZGRlZCB0byB0aGUgZGVmaW5pdGlvbiBvZiByb2xlLiBFcnLigKZh biBpbnRlcmxheWVyIGRldmljZSBpcyBmb3Igb3RoZXIgbGF5ZXJzIGJlc2lkZXMgU1BJTkUvTEVB Ri48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TGltaXRpbmcgcG9ydCBiYW5kd2lkdGggdG8gYSBmaXhl ZCByYXRlIGlzIHRvbyByZXN0cmljdGl2ZS4gVGhlIG1vZGVsIGFzIHNwZWNpZmllZCBhbHJlYWR5 IGRvZXMgbm90IGNvdmVyIGEgc2V0IG9mIHBvcnQgc3BlZWRzIHRoYXQgYXJlIGluIGRlcGxveW1l bnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6cmVkIj5bWV0gYmFuZHdpZHRoIGlzIGRlZmluZWQgYXMgaWRlbnRpdHktcmVmLiBPdGhl ciBzcGVlZHMgY2FuIGJlIGFkZGVkIGJ5IGRlZmluaW5nIG5ldyBpZGVudGl0aWVzLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj5OZWVkcyB0byBiZSBkb2N1bWVudGVkLjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWY7Y29sb3I6IzFGNDk3RCI+W1ldIE9rLCBpdCB3aWxsIGJlIGFkZGVkIHRvIHRoZSBkZWZpbml0 aW9uIG9mIGJhbmR3aWR0aC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhv dyB3b3VsZCBhIGRldmljZSB0aGF0IGhhcyBtb3JlIHRoYW4gYSBzaW5nbGUgcm9sZSBpbiB0aGUg ZmFicmljIGJlIHJlcHJlc2VudGVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+W1ldIFRoZSByb2xlIGZvciBhIGRldmljZS1u b2RlIGlzIGRlZmluZWQgYXMgbGVhZi1saXN0IHRvIHN1cHBvcnQgYSBkZXZpY2Ugd2l0aCBtb3Jl IHRoYW4gb25lIHJvbGVzLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlNlcnZpY2UgY2FwYWJpbGl0aWVzIGFzIHRoZXkgYXJlIGRlc2NyaWJl ZCBiZWxvbmcgdG8gdGhlIG92ZXJsYXkgY29udGV4dCB3aGlsZSB0aGV5IGFyZSBjYWxsZWQgZGV2 aWNlIGNhcGFiaWxpdGllcy4gQXJlIHRob3NlIHRoZSBvbmx5IHBvc3NpYmxlIHNlcnZpY2UgY2Fw YWJpbGl0aWVzPyBXaGF0IGlzIHRoZSBlZmZlY3Qgb2YgY29uZmlndXJpbmcgdGhvc2UgY2FwYWJp bGl0aWVzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+W1ldIFNlcnZpY2UgY2FwYWJpbGl0aWVzIGlzIGZvciBhIGZhYnJpYyBu b3QgYSBkZXZpY2UuIFRoZSBkZXNjcmlwdGlvbiBmb3IgdGhlIHNlcnZpY2UgY2FwYWJpbGl0aWVz IHdpbGwgYmUgY29ycmVjdGVkLiBGb3IgYmV0dGVyIGV4dGVuc2lvbiBmb3Igb3RoZXIgc2Vydmlj ZXMsIHdlIHdpbGwgY2hhbmdlIGN1cnJlbnQgZW51bWVyYXRpb24gdHlwZSB0byBpZGVudGl0eS1y ZWYuDQogTW9yZSBzZXJ2aWNlIGlkZW50aXRpZXMgY2FuIGJlIGRlZmluZWQgaW4gdGhlIGZ1dHVy ZSBieSB2ZW5kb3JzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+VGhlIGV4dGVuc2liaWxpdHkgbWVj aGFuaXNtIG5lZWRzIHRvIGJlIGRvY3VtZW50ZWQuDQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPltZXSBPaywgaXQgd2lsbCBiZSBhZGRlZCB0byB0aGUgZGVm aW5pdGlvbiBvZiB0aGUgc2VydmljZSBjYXBhYmlsaXR5Lg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PldoYXQgaXMgY29tcG9zZS1mYWJyaWMgUlBDPyBUaGUgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5l IGFueSBSUENzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOnJlZCI+W1ldIHJwY3Mgd2VyZSByZW1vdmVkIGluIHByZXZpb3VzIHZlcnNp b24gc2luY2UgcGVvcGxlIHNheSBpdCB3b3VsZCBsZWF2ZSBmb3IgdmVuZG9yLXNwZWNpZmljIGlt cGxlbWVudGF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPlRoZSBycGNzIHRvIGNvbXBvc2UgYSBmYWJyaWMg aXMgYXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJwYyBjb21wb3NlLWZhYnJp YyB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGlucHV0IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXNlcyBmYWJyaWMtYXR0cmlidXRl czs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBvdXRwdXQgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIGZhYnJpYy1pZCB7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgZmFicmlj LWlkOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpyZWQiPn08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQi PlRvIGFkZCBhIG5vZGUgdG8gZmFicmljOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0LWluZGVudDo5LjBwdCI+PHNwYW4gc3R5bGU9ImNv bG9yOnJlZCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9InRleHQtaW5kZW50OjkuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4m bmJzcDsmbmJzcDsmbmJzcDsgcnBjIGFkZC1ub2RlLXRvLWZhYnJpYyB7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9InRleHQtaW5kZW50OjkuMHB0 Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgaW5wdXQgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJ0ZXh0LWluZGVudDo5LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJl ZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGxlYWYgZmFicmljLWlkIHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIGZhYnJp Yy1pZDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0idGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9InRl eHQtaW5kZW50OjkuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXNlcyBk ZXZpY2UtYXR0cmlidXRlczs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9InRleHQtaW5kZW50Ojku MHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpyZWQiPkRvIHlvdSBzdWdnZXN0IHdlIGJyaW5nIGl0IGJhY2sgdG8gdGhlIGRyYWZ0Pzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+SSBhbSBub3Qgc3VnZ2VzdGluZyBhbnl0aGluZywgSSB3YXMgYXNr aW5nIGFib3V0IHRoZSBjb21wb3NlLWZhYnJpYyBSUEMgdGhhdCB3YXMgbWVudGlvbmVkIGluIHRo ZSBkb2N1bWVudC4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPltZXSBXZSB3aWxsIGNsYXJpZnkgaXQgaW4gdi0wOS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XaGF0 IGlzIHBvbGljeSBkcml2ZW4gdHJhZmZpYyBiZWhhdmlvcj8gSXMgdGhlcmUgdGhlIG9ubHkgb25l IHBvbGljeSB0aGF0IGZpdHMgYWxsIHBvc3NpYmxlIGRlcGxveW1lbnQgc2NlbmFyaW9zPzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJl ZCI+W1ldIFBvbGljeSBpcyBuZWVkZWQgZm9yIHRoZSB0cmFmZmljIG90aGVyd2lzZSB0aGUgdHJh ZmZpYyB3aWxsIGJlIGRpc2NhcmQuIFRoZXJlIGNhbiBhbHNvIGJlIG5vcm1hbCwgd2hpY2ggbWVh bnMgbm8gcG9saWN5IGlzIG5lZWRlZCBmb3IgYWxsIHRyYWZmaWMuDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SXQg bmVlZHMgdG8gYmUgZG9jdW1lbnRlZCBvbiB3aGF0IGlzIG1lYW50IGJ5IHBvbGljeSAtIHdoYXQg aXMgdGhlIHB1cnBvc2Ugb2YgdGhhdCBwb2xpY3ksIHdoZXJlIGFuZCBob3cgaXQgc2hvdWxkIGJl IGluc3RhbnRpYXRlZC4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFG NDk3RCI+W1ldSXQgd2lsbCBiZSBjbGFyaWZpZWQgaW4gdi0wOS48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkxvb2tpbmcgYXQgdGhlIGhpc3Rvcnkgb2YgdGhlIGRvY3VtZW50IGZyb20g dGhlIGluZGl2aWR1YWwgc3VibWlzc2lvbiB0aW1lIGFuZCB0aGUgY29tbWVudHMgcmVjZWl2ZWQs IGl0IHNlZW1zIHRoYXQgdGhlIHBvaW50IGZpeGVzIHRvIHRoZSB0ZXh0IHdlbnQgaW4gdG8gY292 ZXIgdGhlIHNwZWNpZmljIGNvbW1lbnRzIGJ1dCBub3QgdG8gYWRkcmVzcyB0aGUgYnJvYWRlciBz Y29wZSBvZiBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlRoZSBkb2N1bWVudCB3b3VsZCBkZWZpbml0ZWx5IGJlbmVmaXQgZnJvbSBhIG1ham9yIHJld3Jp dGUgY2xhcmlmeWluZyB0aGUgbG9naWMgYmVoaW5kIHRoZSBkZWNpc2lvbnMgbWFkZSwgYWxpZ25p bmcgbW9yZSB3aXRoIHRoZSBvcGVyYXRpb25hbCBwcmFjdGljZSBvZiBmYWJyaWMgYmFzZWQgbmV0 d29yayBkZXNpZ24gYW5kIGRlcGxveW1lbnQsIGFuZCBicmluZ2luZyB0aGUgY29udGVudCBpbiBZ QU5HIG1vZHVsZXMNCiB0byBiZSBzZWxmLWRlc2NyaWJpbmcuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q09N TUVOVDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RmFicmljIGFuZCBQT0QgYXJlIG5vdCBl cXVpdmFsZW50IHRlcm1zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JMlJTIHVzZSBj YXNlIHJlcXVpcmVtZW50cyBkb2N1bWVudCBoYXMgZXhwaXJlZCAxMSBtb250aHMgYWdvLiBVc2Ug Y2FzZXMgZG9jdW1lbnRzIGFyZSBnb29kIGZvciB0cmFja2luZyB0aGUgd29yayBwcm9ncmVzcyBv ZiBzcGVjaWZpY2F0aW9uIGRvY3VtZW50cywgaXQgaXMgcXVlc3Rpb25hYmxlIHdoZXRoZXIgc3Rh bmRhbG9uZSB1c2UgY2FzZXMgZG9jdW1lbnRzIHByb3ZpZGUgdmFsdWUgYmV5b25kIGhpc3Rvcmlj DQogcmVjb3JkLiBJcyB0aGUgcmVmZXJlbmNlIHRvIEkyUlMgdXNlIGNhc2VzIGRvY3VtZW50IHJl YWxseSBuZWVkZWQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6cmVkIj5bWV0gVGhlIHJlZmVyZW5jZSB3aWxsIGJlIHJlbW92ZWQgaW4g djA5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2hhdCBpcyBhdG9taWMg bmV0d29yaz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpyZWQiPltZXSBUaGUgb3JpZ2luYWwgc2VudGVuY2UgbWlnaHQgYmUgY29uZnVz aW5nLiBIb3cgYWJvdXQgd2UgY2hhbmdpbmcgaXQgdG8g4oCcYSBQT0QgY2FuIGJlIGNvbnNpZGVy ZWQgYXMgYSBiYXNpYyBzdHJ1Y3R1cmUgZm9yIG1hbmFnZW1lbnQgcHVycG9zZXMu4oCdPzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj5XaGF0IGlzIGEgYmFzaWMgc3RydWN0dXJlIHRoZW4/IElmIHRoaXMgaXMgaW4gb3Zl cmxheSBjb250ZXh0IHRoZW4gaXQgaXMgbm90IG9idmlvdXMgd2hhdCBQT0QgbWVhbnMgdGhlcmUu IElmIHRoaXMgaXMgaW4gdW5kZXJsYXkgY29udGV4dCB0aGVuIGNvbmNlcHR1YWxseSBpdCBpcyBj bGVhciBidXQNCiBxdWl0ZSBmYXIgYXdheSBmcm9tIG9wZXJhdGlvbmFsIHJlYWxpdHkuIDxicj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1ldIEl0IGlzIGEgc2V0 IG9mIG5vZGVzIGFuZCBsaW5rcyB3aGljaCBjb21wb3NlcyBhIFBPRCBhbmQgYWxzbyBzdXBwb3J0 cyBhbiBvdmVybGF5IGluc3RhbmNlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCjxi cj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5WTEFOIGlzIG5vdCBhIGZhYnJp YyBidWlsZGluZyB0ZWNobm9sb2d5IGFzIHN1Y2gsIHdoaWxlIEV0aGVybmV0IGlzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XaGF0IGlzIHRoZSBuZWVkIGZvciBWTkkgY2FwYWNpdHkg bGVhdmVzPyBXaGF0IGlzIHRoZWlyIGVmZmVjdCBpZiBjb25maWd1cmVkPzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+W1ldIEl0 IGlzIHVzZWQgdG8gc2F5IHRoZSByYW5nZSBvZiB0aGUgVk5JcyBmb3IgYSBQT0QuIFdlIHdpbGwg dXBkYXRlIHRoZSBkZXNjcmlwdGlvbiB0byBjbGFyaWZ5IGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgZG9jdW1lbnQgaW50ZXJtaXhl cyBpZXRmLWZhYnJpYy0qIGFuZCBpZXRmLWRjLWZhYnJpYy0qIG5hbWVzcGFjZXMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5b WV0gQXBvbG9naXplIGZvciB0aGUgaW5jb25zaXN0ZW50LiBJdCB3aWxsIGJlIGNoYW5nZWQgdG8g aWV0Zi1kYy1mYWJyaWMtKiBpbiB2MDkuPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VyaWFsIHBvcnQtdHlwZSBpcyBwcmVzZW50IHdoaWxl IEluZmluaWJhbmQgaXMgbm90IC0gSW5maW5pYmFuZCBiYXNlZCBmYWJyaWNzIGFyZSB3aWRlbHkg ZGVwbG95ZWQuIFdoYXQgaXMgdGhlIGV4dGVuc2liaWxpdHkgbWVjaGFuaXNtIGZvciBhZGRpbmcg aW4gbmV3IHBvcnQgdHlwZXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bWV0gU2luY2UgdGhlIHBvcnQtdHlwZSBpcyBpZGVu dGl0eXJlZiwgbmV3IHBvcnQgdHlwZXMgY2FuIGJlIGFkZGVkIGJ5IGRlZmluaW5nIG5ldyBpZGVu dGl0aWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+UGxlYXNlIGRvY3VtZW50IHRoZSBleHRlbnNp YmlsaXR5Lg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEIj5b WV0gT2ssIHdlIHdpbGwgZG9jdW1lbnQgaXQgaW4gdGhlIGRlZmluaXRpb24gb2YgcG9ydC10eXBl Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JcyB0aGVyZSBhbnkgZGVwbG95bWVudCBleHBlcmllbmNl IHdpdGggdGhpcyBtb2RlbD8gVGhlIE9ETCBmYWFzIHByb2plY3QgaGFzbid0IGdvdCBtdWNoIGFj dGl2aXR5IG92ZXIgbGFzdCB0d28geWVhcnMuIEFyZSB5b3UgYXdhcmUgb2YgYW55IG90aGVyIGlt cGxlbWVudGF0aW9ucyBvciBkZXBsb3ltZW50cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPltZXSBZZXMsIHRoZSBpbXBsZW1l bnRhdGlvbiBpcyBpbiBPREwgRkFBUy4gQ3VycmVudCBtb2R1bGUgaXMgYSBwYXJ0IG9mIGZhc3Mg cHJvamVjdC4gSXQgaGFzIGJlZW4gZG9uZSBvdmVyIHR3byB5ZWFycyBhbmQgb25seSBtYWludGVu YW5jZSBpcyBuZWVkZWQuIEFuZCB3ZSB0aGluayBpdCBpcyBzdGFibGUuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KR29vZC4gU28gdGhp cyBpbiBmYWN0IGlzIGNsb3NlciB0byBGQUFTIGFuZCB0aGVyZWZvcmUgdGhlIGNvbnRleHQgb2Yg dGhlIGRvY3VtZW50IGlzIHRoZSBvdmVybGF5LiBUaGUgZG9jdW1lbnQgbmVlZHMgdG8gc3RhdGUg dGhhdCBjbGVhcmx5Lg0KPGJyPg0KPGJyPg0KT3ZlcmFsbCBpdCBzZWVtcyB0aGF0IHdoYXQgaXMg bWlzc2luZyBpbiB0aGUgZG9jdW1lbnQgaXMgdGhlIGNvbnRleHQgY2xhcmlmaWNhdGlvbi4gT25j ZSB0aGUgY29udGV4dCBvZiB0aGlzIG1vZGVsIGlzIGNsZWFybHkgZGVmaW5lZCB0aGUgcmVzdCBv ZiBjb21tZW50cyB3aWxsIGJlIGVhc2llciB0byBhZGRyZXNzLjxicj4NCjxicj4NClRoYW5rIHlv dS48YnI+DQo8YnI+DQpJZ25hczxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96BA222nkgeml513mbschi_-- From nobody Sun Apr 8 04:42:34 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E911200F1; Sun, 8 Apr 2018 04:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 xmQmr8boHd-7; Sun, 8 Apr 2018 04:42:23 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::70e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C446129C6B; Sun, 8 Apr 2018 04:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0zcUTg9Qhjr7k9qSBTlVSElN+rSJP1VwHfTiZ5nLfcU=; b=aUPqYd0bqgIjG8RsOfmvOkFz61aCPUh2w+3untzjWKbrXW5eAiK68hGC/P/UxVOHkcfvdTk28wTXZvT4KDr0zwgQu/eZfepPA3RSt96OfYk3Aegi7wdYLV+N07gCfLza0JvE/Qto/80M2+MSQBNGnDbHh/lrrzayK12eF1MkVsk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.165.129.75) by HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.6; Sun, 8 Apr 2018 11:42:19 +0000 Message-ID: <00d801d3cf2e$92becf20$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Mach Chen" , "Alissa Cooper" , "The IESG" Cc: , , , References: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com> Date: Sun, 8 Apr 2018 12:41:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.165.129.75] X-ClientProxiedBy: LO2P265CA0154.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9::22) To HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e5ea9e52-1e6f-46ca-4594-08d59d45c9a6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 3:71pQgDTy7vJEtVULAuU3Sw7mCaCDWGaq86HRryK7dMT5hIzBAeznAPfW0eXdRozP9gLGmX+rQk0UnxUYtXAhEOovk5jHAUfui4DrngyuQpx3dnBoF9GufQkmG27ShHiXbNWg0tmCQB62fkWZDoO5xfYdBac9nK8BXNWYPpDh6ds4ME3TZ8MT7MDpWV/dmMZE3A6T23eFW/F69bwjb8hDb3pp75bomKAhLMe3922Kx/fOChFERFAWYZ3x3Xa3Xskm; 25:tA6Q+/1iLCKRXzasYdiCJmELI4gDHAxvAfK+d4x4FRlNkbH0R99CwekphVxSptdRkCVitty3Uoh63D7JPCIaKw5YjIjkGpccHSmlR6+Fx36MjP/4SEsbpcCUbiB0ApoI+gIVCGaOgIIA4G6pEuN2Lgyw4ha+7gB7Eca+vXyFhiyYvcF/EwTz3LiQRfypH/9FKnxQZh9hAa1+cqBGlMFijm+pg44hxP0FJioLRZsAE/JFItPlfS97adAovjd1DqxkGLUzBR8vM5uF0SRVW7/RQbxye2xYOAPv0QafcFb3+LAQkkP17Aq9b5xEjMXkQbnJVO/00thzhoyfIWBRfEkYrg==; 31:r+wZwrC6s4R6NnGCvDT9KurCdHx4M6dETzXQJyuxoj6QqyJR7rlkExbf4UlpPcxADCXZdD2ToZxb6f+f4JSEU9cpB3HIxOFWTbh3vocZdKZglSuF2LtD9GPu/dfHxKY947lXaUZYEpcPA/75ahgczk3hAj9PfuGLRwcLEDrxn7xf4EzMgRGBWqcL+YFP7NvcvXXz71hDFIaTfmfSCNRpNZTNcxVhfAADJr2ca1LdsdE= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3003: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(50582790962513); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 4:0xw6lCdEI+zX1TsYqCNIti4pPSjsIqrDPVxWab66i0ZjMYyi9B05V4al6Kt8hDH7XUnoUGKdUdMnIkfZqDJdSc/mi8T5xZjakT4hbM4feWv8TRI+jMs+ePZOTW/1DDnw4YdEMuxC1RDuFdZg2EB4xMhCtcZyEC/8yPwYzN3u/dbEP4V8rrOvk/XROW7hgOAXsPb/dF2ISVtB+2osrswV1AjThwwnRxHZfyYtRx+6aqJ2fVf0K0U1nJwUxI0oIK6Db2NFR5IsfPjvo+vlV4JDrqyWTdBBEsfzzfqAOv401qw1YbQqqa+xEt4jN2/pPYVNiS0Y+MmUxRwtcgvewWfq71p7xD+9TAZMm/tYc+YwX+M= X-Forefront-PRVS: 0636271852 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(346002)(376002)(366004)(39380400002)(13464003)(51444003)(189003)(199004)(446003)(9686003)(26005)(229853002)(47776003)(97736004)(4720700003)(50226002)(186003)(2906002)(6666003)(62236002)(44716002)(66066001)(16526019)(105586002)(61296003)(478600001)(84392002)(50466002)(44736005)(6486002)(8936002)(6306002)(53546011)(86362001)(3846002)(4326008)(7736002)(81816011)(14496001)(81686011)(23756003)(6496006)(966005)(33896004)(25786009)(386003)(5660300001)(6116002)(1556002)(110136005)(956004)(476003)(54906003)(6246003)(52116002)(8676002)(230700001)(81156014)(68736007)(305945005)(76176011)(81166006)(316002)(486006)(106356001)(53936002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3003; 23:H7gei2qSL8flpiRfVHMX2zMEmLAcx99gatAZf?= =?iso-8859-1?Q?T9QnD4AHuzk1vOM+rUoJNoGXCEVOV+LCBorfxNu/crp8MIIdrnqVfLcVRI?= =?iso-8859-1?Q?LKvQaiOcdj1yLHG+3i40xe4jVCfYs1HVl69zXFq7Q4vGRK8mRHHci+5PVe?= =?iso-8859-1?Q?MRz3H4S11mPkwbj38qP/6axYMI51ZIhJSiEImrgi4wQWTe325ESKpL1nnN?= =?iso-8859-1?Q?a6sG3gVRRITugEiGFXbARubEyf3BIlmmhHV5bbQEOUq7XjdAhdVhLpa0J1?= =?iso-8859-1?Q?gjuvyCzyqjDP/J/uUbz0udEKa6BWRO3kvGhPy3EBbqP2L9HB7IzriP478Z?= =?iso-8859-1?Q?3ztisMOY7yZ8MF1vB6aUmwVjK4VONfl7HRXUKIpM3dk67gypLmmjvnAgup?= =?iso-8859-1?Q?NSbvDxUQSK4GkiOrJrMKfEFytXR4LI76wbXiBzQJHTeTnchebZ+gb82Rq4?= =?iso-8859-1?Q?OpfJkn2TMTwIOQ8opExUgwJUyY4OSVeh+UiOrqCb7WL5VLKrQmxAphkGbG?= =?iso-8859-1?Q?SECI0YWfstJxO7pFNFfSd2reY0MAz44a1STmcxTSuWa/o7FfRpXw72IHeN?= =?iso-8859-1?Q?O7pqOLL1dstxH8K36Hdu2FLkfOhgVIfGgHFlB2VeO4/FPWs9/Drq6t73TJ?= =?iso-8859-1?Q?zqBHJ+Y+eXyV3PstzkKjwbk8jJyCOXq2XJZti3IrEjSrxycQiaYmtPgMVI?= =?iso-8859-1?Q?sgGIkJzpoqlt7ShuVuYDWl78bJ8jjhAJKEa+1FiPBo9X7K+QTAVB0pxAnQ?= =?iso-8859-1?Q?cySir2yMNSBGmAyBAxb/SpleIN4W4/YDXeKBx2oWpXY27kmml5tIBYRAHL?= =?iso-8859-1?Q?R0vdyQcDS6Y3HK0jvkrAAJnZtN/HNRCge1t8OsOLlRiRlDlSFXV92vzrLU?= =?iso-8859-1?Q?McV6jC0QzIMXp4Cjwkd416AH2AYLeHKcyNWXV8PW7Ng0wJ6ao8a9j92YRp?= =?iso-8859-1?Q?ccYe4KuOUjW7KTudQCcd/BCC1U4V1jxZ8o30nDdAu7t3HkqZUy5Pr3Odio?= =?iso-8859-1?Q?n21spOkuj1ajSzOjVnsAQ2WW52paCQoGli3ihHFl/yyCMMbjO3TA0LfWid?= =?iso-8859-1?Q?AsRNaFZN1zQYt4iIC7MB+7/If+/w3NdRh7My6QQYj/SNIkYam2Tye+39lV?= =?iso-8859-1?Q?chuK2u7E5bwLH58iJd9DwMQ1nHrEsgFnEZ+i87Od3btCCc/QHWkX5FZBf6?= =?iso-8859-1?Q?K2zdhF21jpthUSJNEKNCe2Cynk8YMBBu9C5UVXke/RQ3ZCwr92zHeWFYsC?= =?iso-8859-1?Q?PITx24t0H6AFjR8r/wbRqmg3ESTwOyEBZqH6ugZgV+6S0OVF8crmv6s1lT?= =?iso-8859-1?Q?iqHXp40MBGXLn1mz4CYQ7wZO8eLCr2L3RhOViGXuHZUL0XERcdr2CxOEBb?= =?iso-8859-1?Q?iWWMQdOJ1QUV8rfc/cZEZn0adhN9xD6xrlqPIP6fnTg8GF/82/t3VAJJR9?= =?iso-8859-1?Q?gnbGYVQJzLhWmU9qIxdjdifhx3DpjZd+325ZIFfw6K0ogzx+CipnhKsgw3?= =?iso-8859-1?Q?+KwoTS7IBfdDaVExNAxONre4SOAIM9Hsma//O5D8uwL9cWrOqh0kyVZ+Ck?= =?iso-8859-1?Q?QeIFB/CSuRqvh6CQPEqATXQgLoTs0rGCkTkDPUtLLOxVfNmAH?= X-Microsoft-Antispam-Message-Info: SfBHtgQXpjGAyeknHgaaIvBJ113VNnYAyvG/+7BvHpxrtTzlAykwO0tjmjxKBTqPv1zD7sqsCcVrk5Prj3qGrQsvO8h2MEf0SHXGUE2Grqk8auX7kCL4GkoHSqnz3jTWDj06sLPUGc1I2AXBlBlOeu+osQYmfFwYo5PLz/B+tdk2flq1Ao+MFRSJh47yk4GB X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:oYgyyNhpWe2kV1mbPrlJDJAZFD55dKl9DQ0yXHFKQeoraO6xm8HTEUHc/wljOOmhRRu4BX6i+gcubrgnD/ckZUIS98K/1OyNMbt0eDDmYJoypldbI/9f+DpjChPZI9TXOag4+r7uANk91j94cy8PRkzbKwhA52dT5j/IykmROf/4GEtfzAJxr6bgxkpMKNTu9z+y44qtUNaak0IU1p7Ip/Zud6z9m7wNi6PmeOH0bAG3aDI8hbjb821SjEs6Oq31bvdNNzlBWHIlv5z2WsU3/CnNnW4wQvJVRixUbQcOqaPockCNLuSlrHQ5Cc04KmDR8b5nNYZY0NPBNCsJCtcmU9OyRZnFYQaWOy08a+CeyyZuiGZPVof85U0CZeZmW1HVZvuOQkWL9c/zXC0v2BC/6XDeQobqIM0J/G9bD+vtouowygTvXxm5PYyB9p+1VqgC6ugL86TCasN4gbWGn40Uxw==; 5:/WdvoepINaGyc7m4snn9w4/dYQJ/7ZE1wnCYE1gWVPfA7GyO1Tc0ChWwEhQP0wjFxjeyKMUvbAdZnTROy1GHUIEeOCZi/Maqyeime2/AQKiT+5t2I63pDezks1pXtcYqwRn8Y71RK4TXFOH1eJFNBCpXH+8jXrdBHiYBbwCBfQs=; 24:oB63KgJp89cHCoyNSn0xgwkkR4QVXtLjAZP9DrjcCHF1UULUR5si1vzxoigF/SAdCC7sOgLFGR/TP+2lNTKStZzXQ/v4Qj7ngorZ/JGDFXA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 7:u9+eUdpVeOpmPPIfMorvSJTaV8nEDnOMySaZNMN6MhNijKjEhGlTEmXdfduRgbNPKepmgqnHlBoIYNyBTbqAA62eb671QuTWYSbxla9yUm/GZnoasmxjilLHJcVw31PRdHUzcsXnLt/lTzY7k6cWGCPTU9UZdwyqccDfAng6HbUHNabeeZRgc7HBKHRwqDySHSNARdLQiOcVnIaUmYiUeEokgM8eaPd3vMJUruf2cg4k/hW8vDIkO4C4BVxiJf3Y X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2018 11:42:19.7652 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e5ea9e52-1e6f-46ca-4594-08d59d45c9a6 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003 Archived-At: Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 11:42:26 -0000 ---- Original Message ----- From: "Mach Chen" To: "Alissa Cooper" ; "The IESG" Cc: ; ; ; Sent: Sunday, April 08, 2018 9:23 AM > Hi Alissa, > > Thanks for your comments! > > Please see my responses inline... > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa Cooper > > Sent: Tuesday, April 03, 2018 11:10 PM > > To: The IESG > > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i2rs-chairs@ietf.org; > > shares@ndzh.com > > Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: > > (with COMMENT) > > > > Alissa Cooper has entered the following ballot position for > > draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Sec 1.2: > > > > "YANG tree diagrams provide a concise representation of a YANG module, > > and SHOULD be included to help readers understand YANG module > > structure." > > > > This document does not seem like an appropriate place to have normative > > guidance about this. And if this sentence is removed, I don't see the point of > > including Section 1.2 otherwise. This would also imply deleting the reference to > > I-D.ietf-netmod-yang-tree-diagrams. > > This results from a YANG doctor review. I saw it also occurs in other published documents. I personally think it's no harm to keep it, how do you think? Mach I think that this is very odd. YANG guidelines rfc6087bis says " YANG tree diagrams provide a concise representation of a YANG module, and SHOULD be included to help readers understand YANG module structure. Guidelines on tree diagrams can be found in Section 3 of [I-D.ietf-netmod-yang-tree-diagrams]. " which I think is the correct guidance in the correct place. A quick look at the recently published RFC8343, RFC8344, RFC8345, RFC8346 contain no text of the kind you suggest so if it occurs in other I-D, then I would regard those other I-D as being in error. If I look back at a thread from Ebben for a yang doctor review of an earlier version of this I-D, the text I see proposed is " > A simplified graphical representation of the data model is used in > this document. The meaning of the symbols in these diagrams is > defined in [I-D.ietf-netmod-yang-tree-diagrams]. " which I think is rather different. Tom Petch (not a YANG doctor) > > > > Sec 2.1: Again here I'm confused about the use of normative language. Why do > > you need to specify normative requirements for what this very document is > > specifying? Or are these supposed to be requirements on implementations? > > OK, how about this: > > "...a RIB data model needs to specify a way for an external entity to learn about the functional capabilities of a network device." And > > " The RIB data model needs a way to expose the nexthop chaining capability supported by a given network device." > > > > > Sec 2.5: s/causes/caused/ > > Done > > The above updates will be reelected in version-11. > > Thanks, > Mach > > From nobody Sun Apr 8 06:20:36 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4A912946D; Sun, 8 Apr 2018 06:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 cnqO2uEIzeC7; Sun, 8 Apr 2018 06:20:27 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 D549B127444; Sun, 8 Apr 2018 06:20:26 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CBADBEB8A2295; Sun, 8 Apr 2018 14:20:22 +0100 (IST) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 8 Apr 2018 14:20:24 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.73]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0361.001; Sun, 8 Apr 2018 21:20:20 +0800 From: Mach Chen To: t.petch , Alissa Cooper , The IESG CC: "i2rs@ietf.org" , "draft-ietf-i2rs-rib-data-model@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Thread-Topic: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) Thread-Index: AQHTy13moi2oBFWZPEShrejzOgw/4qP2htDAgAA/0nCAABhS0A== Date: Sun, 8 Apr 2018 13:20:19 +0000 Message-ID: References: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com> <00d801d3cf2e$92becf20$4001a8c0@gateway.2wire.net> In-Reply-To: <00d801d3cf2e$92becf20$4001a8c0@gateway.2wire.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 13:20:29 -0000 Hi Tom, > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Sunday, April 08, 2018 7:42 PM > To: Mach Chen ; Alissa Cooper > ; The IESG > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i2rs-chairs@i= etf.org; > shares@ndzh.com > Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-d= ata- > model-10: (with COMMENT) >=20 > ---- Original Message ----- > From: "Mach Chen" > To: "Alissa Cooper" ; "The IESG" > Cc: ; ; > ; > Sent: Sunday, April 08, 2018 9:23 AM >=20 > > Hi Alissa, > > > > Thanks for your comments! > > > > Please see my responses inline... > > > > > -----Original Message----- > > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa Cooper > > > Sent: Tuesday, April 03, 2018 11:10 PM > > > To: The IESG > > > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; > i2rs-chairs@ietf.org; > > > shares@ndzh.com > > > Subject: [i2rs] Alissa Cooper's No Objection on > draft-ietf-i2rs-rib-data-model-10: > > > (with COMMENT) > > > > > > Alissa Cooper has entered the following ballot position for > > > draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > Sec 1.2: > > > > > > "YANG tree diagrams provide a concise representation of a YANG > module, > > > and SHOULD be included to help readers understand YANG module > > > structure." > > > > > > This document does not seem like an appropriate place to have > normative > > > guidance about this. And if this sentence is removed, I don't see > the point of > > > including Section 1.2 otherwise. This would also imply deleting the > reference to > > > I-D.ietf-netmod-yang-tree-diagrams. > > > > This results from a YANG doctor review. I saw it also occurs in other > published documents. I personally think it's no harm to keep it, how do y= ou > think? >=20 > Mach >=20 > I think that this is very odd. >=20 > YANG guidelines rfc6087bis says > " YANG tree diagrams provide a concise representation of a YANG > module, > and SHOULD be included to help readers understand YANG module > structure. Guidelines on tree diagrams can be found in Section 3 of > [I-D.ietf-netmod-yang-tree-diagrams]. > " > which I think is the correct guidance in the correct place. >=20 > A quick look at the recently published RFC8343, RFC8344, RFC8345, > RFC8346 contain no text of the kind you suggest so if it occurs in other = I-D, then > I would regard those other I-D as being in error. >=20 > If I look back at a thread from Ebben for a yang doctor review of an earl= ier > version of this I-D, the text I see proposed is >=20 > " > > A simplified graphical representation of the data model is used in > > this document. The meaning of the symbols in these diagrams is > > defined in [I-D.ietf-netmod-yang-tree-diagrams]. > " > which I think is rather different. Indeed, my fault, I just checked Ebben's suggestion, it's as above quoted.= =20 To Alissa: If change to following text, is it OK for you? "A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is defined in [I-D.ietf-netmod-yang-tree-diagrams]." Best regards, Mach >=20 > Tom Petch > (not a YANG doctor) >=20 > > > > > > Sec 2.1: Again here I'm confused about the use of normative > language. Why do > > > you need to specify normative requirements for what this very > document is > > > specifying? Or are these supposed to be requirements on > implementations? > > > > OK, how about this: > > > > "...a RIB data model needs to specify a way for an external entity to > learn about the functional capabilities of a network device." And > > > > " The RIB data model needs a way to expose the nexthop chaining > capability supported by a given network device." > > > > > > > > Sec 2.5: s/causes/caused/ > > > > Done > > > > The above updates will be reelected in version-11. > > > > Thanks, > > Mach > > > From nobody Mon Apr 9 08:44:30 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA7C12AAB6; Mon, 9 Apr 2018 08:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.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 oBnoIrZQupYD; Mon, 9 Apr 2018 08:44:25 -0700 (PDT) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670118.outbound.protection.outlook.com [40.107.67.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2974F12025C; Mon, 9 Apr 2018 08:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.onmicrosoft.com; s=selector1-kaloom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T1bFovZ8EMjH9ocInbD6I8ebBPTm5HeJQywsfdo3Qwc=; b=KZuvuyDYm0I3YGxdudqMjehFM0ij3BS/5X92VNd1ZMYtmypeX2av+RIINclFS7BerAPlR1EADPUSe17VcOGLBVto4Eyil8JH1EJaH7MQryg55jKCA1xy4RMa/+Z9Kjiw6sThwA3pot5HWWWQ8So7RdQwcsVs7XRB9ERdya89MnM= Received: from YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM (52.132.77.143) by YQXPR0101MB1927.CANPRD01.PROD.OUTLOOK.COM (52.132.77.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Mon, 9 Apr 2018 15:44:23 +0000 Received: from YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM ([fe80::252a:e52c:402c:cf7]) by YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM ([fe80::252a:e52c:402c:cf7%13]) with mapi id 15.20.0653.016; Mon, 9 Apr 2018 15:44:23 +0000 From: Suresh Krishnan To: Susan Hares CC: The IESG , "i2rs@ietf.org" , "i2rs-chairs@ietf.org" , "draft-ietf-i2rs-rib-info-model@ietf.org" Thread-Topic: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Thread-Index: AQGzXOuogYIVg/6+qC65IQQLrrWnfqQzEdVAgAZnlQA= Date: Mon, 9 Apr 2018 15:44:23 +0000 Message-ID: <857B482B-FC82-4D32-BF57-FAB01F0E7F00@kaloom.com> References: <152290489812.25948.2495908999143424774.idtracker@ietfa.amsl.com> <045701d3cce7$1c8bec00$55a3c400$@ndzh.com> In-Reply-To: <045701d3cce7$1c8bec00$55a3c400$@ndzh.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=Suresh@kaloom.com; x-originating-ip: [45.19.110.76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQXPR0101MB1927; 7:mz0MnBTxFxR9F3QS/KDpXfHp6MqSm9mnp5QkrjsiCFJgJKGQkCLasrWU40BRqmdVfi2LT/hYWcQhPgU6jxz2X00X9bMteyi78zXU7/ftu6moV8BfKQbGIaU+XDfz+Yb0fj3k06fzC+YrtoPEhi1Nx6K4lyNc8aAPJjFK6z1j24A/YhsRHSrduSgRWRNHTQULQJJ6YrpHFP3TXVeFmTz2562/VN4SpHT6RuGayHamB+oFRTTTw4OCKRfG3BXgjegh x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: 47282945-df62-48a4-45c4-08d59e30c44b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:YQXPR0101MB1927; x-ms-traffictypediagnostic: YQXPR0101MB1927: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123560045)(2016111802025)(20161123562045)(20161123558120)(20161123564045)(6043046)(6072148)(201708071742011); SRVR:YQXPR0101MB1927; BCL:0; PCL:0; RULEID:; SRVR:YQXPR0101MB1927; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(39830400003)(376002)(396003)(346002)(199004)(189003)(13464003)(345774005)(59450400001)(68736007)(6486002)(2900100001)(6436002)(106356001)(86362001)(6506007)(25786009)(966005)(53546011)(3846002)(2906002)(26005)(6116002)(54896002)(6512007)(6306002)(236005)(186003)(53946003)(478600001)(486006)(82746002)(6246003)(446003)(229853002)(6916009)(76176011)(2616005)(5660300001)(14454004)(72206003)(53936002)(476003)(606006)(83716003)(4326008)(7736002)(33656002)(66066001)(54906003)(105586002)(97736004)(99286004)(80792005)(8676002)(316002)(11346002)(8936002)(5250100002)(81166006)(81156014)(3660700001)(102836004)(36756003)(3280700002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:YQXPR0101MB1927; H:YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Rq12okBTgCyLxvLrVX7gdCsf1dhu3stQabHJ29daA5Ef6AzNdQSOS1+RR1UDVmtxz0j97V49DIpPp5j2p+3/ur8OKxPABaq/k22i7mHNpYxw2MJvOsbV4MAX/HdXTQQmnWCy932WcrGuRJSMG/Gzoj2HSdMK3czne8gdXiOO2VBSU5XkXsxq2bPCOQifY2CpjBvW09WHB1+3XbAn9+CS4YQxKGPhKrimu43ZLADpAaHYX6mHtAVVaoJwUUo0/Oyen2EvCzXKfy657PjJyT1W8718K6EjvWodTZVy3c5HOZ/+BxInpvpxAiLFa3UfznIr7wHAKH7BMeIRGk/KT5v7XjnSbHN8X3yAeF3JuyTQg2OX6T6L3NDeaQlr3ZUyqp26xrEfleLDt3wYJfTmI0ErgcSKj9Rn6h9cNwHOyxdrx+4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_857B482BFC824D32BF57FAB01F0E7F00kaloomcom_" MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: 47282945-df62-48a4-45c4-08d59e30c44b X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 15:44:23.1054 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB1927 Archived-At: Subject: Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 15:44:28 -0000 --_000_857B482BFC824D32BF57FAB01F0E7F00kaloomcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for checking Sue. Hope the 2.3 text will be fixed in the next rev. Regards Suresh On Apr 5, 2018, at 10:05 AM, Susan Hares > wrote: Suresh: Thank you for catching these errors. See my comments below. Summary: Section 2.3 (good catch). Section 4 and 6 - I think the document represents the WG consensus. I will review the emails, WG documents, and contact previous chairs. Susan Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Suresh Krishnan Sent: Thursday, April 5, 2018 1:08 AM To: The IESG Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; shares@ndzh.com; draft-ietf-i2rs-rib-info-model@ietf.org Subject: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 2.3. Regarding the OSPF route for 2001:DB8::1/32 Did you mean 2001:DB8::1/128 for the host route? If not, this example is wrong since 2001:DB8::1/32 expands to 2001:DB8:0000:0000:0000:0000:0000:1/3= 2 -> 2001:DB8::/32 as the route Sue: Yes - this is an error. * Figure 4. Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into nexthop processing just like the derived nexthops do? Suresh - I need to check the email list archives and get back to you on thi= s point. My recollection was that there was a case where things people did not want to automatically loop this back. However, I cannot bring the discussion of 3.5 years ago to mind. I will take this as an action item as = a reviewer to try to recreate the discussion. Thank you for mentioning this point. It is important to clarify in either case. * Section 6 I would have expected the match type to have some indication about whether it requires an exact match or LPM (e.g. A MAC route uses an exact match but an IPv6 route uses LPM). Has the WG discussed this? The short answer is yes, extensive in early interims, list discussions and in session. Can you provide more depth to your questions. For the early discussions, I may need to query Alia Atlas and Jeff Haas (previous chairs) to get the institutional memory on this topic. (One of the reason I really want to have this document discussed with Alia Atlas as AD0. _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_857B482BFC824D32BF57FAB01F0E7F00kaloomcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <01FF54B08571A241890B239B1B8DCC48@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable Thanks for checking Sue. Hope the 2.3 text will be fixed in the next rev.

Regards
Suresh

On Apr 5, 2018, at 10:05 AM, Susan Hares <shares@ndzh.com> wrote:

Suresh:

Thank you for catching these errors.  See my comments below.  <= br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo= nt-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-= align: start; text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">
Summary: 
Section 2.3 (good catch).  
Section 4 and 6 - I think the document represents the WG consensus.  I will
review the emails, WG documents, and contact previous chairs. 

Susan Hares 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Suresh Krishnan
Sent: Thursday, April 5, 2018 1:08 AM
To: The IESG
Cc:&n= bsp;i2rs@ietf.org; i2rs-chai= rs@ietf.org; shares@ndzh.com;
draft-ietf-i2rs-rib-info-model@ietf.org Subject: [i2rs] Suresh Krishnan's No Objection on
draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

Suresh Krishnan has entered the following ballot position for
draft-ietf-i2rs-rib-info-model-15: 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/d= oc/draft-ietf-i2rs-rib-info-model/



-------------------------------------------= ---------------------------
COMMENT:
-------------------------------------------= ---------------------------

* Section 2.3.

Regarding the OSPF route for 2001:DB8::1/32

Did you mean 2001:DB8::1/128 for the host route? If not, this example is
wrong since 2001:DB8::1/32 expands to 2001:DB8:0000:0000:0000:0000:0000:1/32
->
2001:DB8::/32 as the route

Sue: Yes - this is an error. =

* Figure 4.

Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into nexthop processing just like the derived nexthops do?

Suresh - I need to check the email list archives and get back to you on this
point.  My recollection was that there was a case where things  people = did
not want to automatically loop this  back. However, I cannot bring the
discussion of 3.5 years ago to mind. I will take this as an action item as a reviewer to try to recreate the discussion.   Thank you for mentioning th= is
point. It is important to clarify in either case. 

* Section 6

I would have expected the match type to have some indication about whether
it requires an exact match or LPM (e.g. A MAC route uses an exact match but
an
IPv6 route uses LPM). Has the WG discussed this?

The short answer is yes, extensive in early interims, list discussions and
in session.  Can you provide more depth to your questions.  For the= early
discussions, I may need to query Alia Atlas and Jeff Haas (previous chairs)
to get the institutional memory on this topic.  (One of the reason I rea= lly
want to have this document discussed with Alia Atlas as AD0. 


___________________________________________= ____
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

--_000_857B482BFC824D32BF57FAB01F0E7F00kaloomcom_-- From nobody Mon Apr 9 12:50:49 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F06712D7E5; Mon, 9 Apr 2018 12:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=QK7+3xkj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FJqLlzgV 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 XCoi1kHVS87w; Mon, 9 Apr 2018 12:50:41 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02A612D77E; Mon, 9 Apr 2018 12:50:40 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2396B218E7; Mon, 9 Apr 2018 15:50:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 09 Apr 2018 15:50:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=qejKx8SesqxPKZqd1IWFiPauhVm6j 4FYrOEp1Rsnbbk=; b=QK7+3xkjowmfTs7JJqkR4SnDC6DwnMKXBKCCYY8GLfrgV mmFO359qLE7CDa58UhsXfGCFqcFC2WxAEDn5IIMYqtUx20XMYIm06xETbDpkc90t Z4BzoBd2N5o54BsQkH5h462dXlXSevZHUbIBDRzzcl8JYe5G30BxyLNkBFfv6mTT 3uTizULESWs0kpVcFzKS2SmYEwIoGM7PmiQGljLRBnK9GcQuaeqSEWXnRnTDuIBu qpoJxseljmQGV+FFlSueoAYz8iuuabO0pFB8JUoDOqFd/KcvvJKCXoIpSE7iX54R TVPim2N0XDWWUZCW1fykJ+LKrzByVuEAQFhsZ71uA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=qejKx8 SesqxPKZqd1IWFiPauhVm6j4FYrOEp1Rsnbbk=; b=FJqLlzgVoi2yrxqHJDj61s AequDuEOjUHxOg4/1AlMrDadMs3mcYuxyNPFKyav0KY0UUY7tkku/sPiSsIwdePT AqEKM4N1nhn2uNnDkGPgWzXwIM0x88UscI4D5Bj+hXzAJPU6JlEIP86sTDe77mS4 cx37MtX5Ya1JBr0UYOpcwCPEEasUDob96Md0WzSfLRzRY1MyqOXx2oTm4vDys7m8 UEBJBP1ZA27Hiz0rsqGOumoNGT0HPZESrOMxStOO3WXkqRLrsMJqy6hH6EPFLydS bkGl297700gPC/73HdV/u3ofENqOa1zSmJDISHEhr+9yiCZbJuMmA/pnWkyu5P5A == X-ME-Sender: Received: from rtp-alcoop-nitro3.cisco.com (unknown [173.38.117.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 83054E5083; Mon, 9 Apr 2018 15:50:39 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Mon, 9 Apr 2018 15:50:38 -0400 Cc: "t.petch" , IESG , "i2rs@ietf.org" , "draft-ietf-i2rs-rib-data-model@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Content-Transfer-Encoding: quoted-printable Message-Id: References: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com> <00d801d3cf2e$92becf20$4001a8c0@gateway.2wire.net> To: Mach Chen X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 19:50:48 -0000 > On Apr 8, 2018, at 9:20 AM, Mach Chen wrote: >=20 > Hi Tom, >=20 >> -----Original Message----- >> From: t.petch [mailto:ietfc@btconnect.com] >> Sent: Sunday, April 08, 2018 7:42 PM >> To: Mach Chen ; Alissa Cooper >> ; The IESG >> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; = i2rs-chairs@ietf.org; >> shares@ndzh.com >> Subject: Re: [i2rs] Alissa Cooper's No Objection on = draft-ietf-i2rs-rib-data- >> model-10: (with COMMENT) >>=20 >> ---- Original Message ----- >> From: "Mach Chen" >> To: "Alissa Cooper" ; "The IESG" >> Cc: ; ; >> ; >> Sent: Sunday, April 08, 2018 9:23 AM >>=20 >>> Hi Alissa, >>>=20 >>> Thanks for your comments! >>>=20 >>> Please see my responses inline... >>>=20 >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa = Cooper >>>> Sent: Tuesday, April 03, 2018 11:10 PM >>>> To: The IESG >>>> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; >> i2rs-chairs@ietf.org; >>>> shares@ndzh.com >>>> Subject: [i2rs] Alissa Cooper's No Objection on >> draft-ietf-i2rs-rib-data-model-10: >>>> (with COMMENT) >>>>=20 >>>> Alissa Cooper has entered the following ballot position for >>>> draft-ietf-i2rs-rib-data-model-10: No Objection >>>>=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-i2rs-rib-data-model/ >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>=20 >>> = ---------------------------------------------------------------------- >>>>=20 >>>> Sec 1.2: >>>>=20 >>>> "YANG tree diagrams provide a concise representation of a YANG >> module, >>>> and SHOULD be included to help readers understand YANG module >>>> structure." >>>>=20 >>>> This document does not seem like an appropriate place to have >> normative >>>> guidance about this. And if this sentence is removed, I don't see >> the point of >>>> including Section 1.2 otherwise. This would also imply deleting the >> reference to >>>> I-D.ietf-netmod-yang-tree-diagrams. >>>=20 >>> This results from a YANG doctor review. I saw it also occurs in = other >> published documents. I personally think it's no harm to keep it, how = do you >> think? >>=20 >> Mach >>=20 >> I think that this is very odd. >>=20 >> YANG guidelines rfc6087bis says >> " YANG tree diagrams provide a concise representation of a YANG >> module, >> and SHOULD be included to help readers understand YANG module >> structure. Guidelines on tree diagrams can be found in Section 3 = of >> [I-D.ietf-netmod-yang-tree-diagrams]. >> " >> which I think is the correct guidance in the correct place. >>=20 >> A quick look at the recently published RFC8343, RFC8344, RFC8345, >> RFC8346 contain no text of the kind you suggest so if it occurs in = other I-D, then >> I would regard those other I-D as being in error. >>=20 >> If I look back at a thread from Ebben for a yang doctor review of an = earlier >> version of this I-D, the text I see proposed is >>=20 >> " >>> A simplified graphical representation of the data model is used in >>> this document. The meaning of the symbols in these diagrams is >>> defined in [I-D.ietf-netmod-yang-tree-diagrams]. >> " >> which I think is rather different. >=20 > Indeed, my fault, I just checked Ebben's suggestion, it's as above = quoted.=20 >=20 > To Alissa: > If change to following text, is it OK for you? >=20 > "A simplified graphical representation of the data model is used in > this document. The meaning of the symbols in these diagrams is > defined in [I-D.ietf-netmod-yang-tree-diagrams].=E2=80=9D Yes, thanks. Alissa >=20 >=20 > Best regards, > Mach >>=20 >> Tom Petch >> (not a YANG doctor) >>=20 >>>>=20 >>>> Sec 2.1: Again here I'm confused about the use of normative >> language. Why do >>>> you need to specify normative requirements for what this very >> document is >>>> specifying? Or are these supposed to be requirements on >> implementations? >>>=20 >>> OK, how about this: >>>=20 >>> "...a RIB data model needs to specify a way for an external entity = to >> learn about the functional capabilities of a network device." And >>>=20 >>> " The RIB data model needs a way to expose the nexthop chaining >> capability supported by a given network device." >>>=20 >>>>=20 >>>> Sec 2.5: s/causes/caused/ >>>=20 >>> Done >>>=20 >>> The above updates will be reelected in version-11. >>>=20 >>> Thanks, >>> Mach >>>>=20 >=20 From nobody Mon Apr 9 22:54:19 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F79B12D96A for ; Mon, 9 Apr 2018 22:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0BNrwjs2rRHA for ; Mon, 9 Apr 2018 22:54:15 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 52CEC12D95D for ; Mon, 9 Apr 2018 22:54:15 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id g14so7350259pfh.3 for ; Mon, 09 Apr 2018 22:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4p3GVR/o8JJ9zhcBmdkYeGn1Z+v5FCOTtnBkyraV+iM=; b=M+dJOl3Ezzw/AtvS5dz4sKFa5fA9yiL4vubCQPHYfP8n8XobNl76Bu7EPrSWZjgzmO lFGWmoF04ARFStYW7avlRURsqyzZtL3jPaN0DBzug9/+4S0oXToRNsarC+RJp5cAG/Wy kFgYn9X+hu4KFq+KNv2a1EY8Ykt2CRR7cLJWsH4knpwzi20Trh3ZhW5spq1q7rzcQpu+ E54wAfIR4dk9VMBjh/D07ecKMEBuS0uLQjdKXrCLsw92vj2Kn0nqg8ZGWbBrSbEAjspP rUklxw+WiDr/bKuJ+UsB271YCkwmL9USzWV/xhdEX+HgQ9zbh2L6ORDeUxKaAKumR/mm /mlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4p3GVR/o8JJ9zhcBmdkYeGn1Z+v5FCOTtnBkyraV+iM=; b=j2oRf6FQ3S3EO1GGPgFWUWO4gDTE/9dG5NziHdQua5dgnbYWco5VHn8u2TKeWpZhuL M1IVZ51YY94dsZ1vSVOADyiuxyi+EQTcOJLiGcytIba45Pf367E85h4CBonuwLoHApY4 /H0zlXsQAuGS4D/7gG/q0pDPs5EC6IHUs78Wl+0j2EDPjO38IEa6iZxn/zTKLJqRli7G 12RuKBKKKeut3sRsBrH7PWUNGtQ/ds2NSNanktt6v6gxHZA1o+NDBjQYyufrSLsOzS6s 2kIcVLQffx9hSJQIgTjX0AB44jS11gYCU6jwnWZIGIfW+oZwWhXRVVIxVFdi6CfMFown DqaQ== X-Gm-Message-State: ALQs6tC73znICy/DaJDryp7jS7crxiwRyrlZEqNQHNl6tKrIqBFqYhKR NeqgmF6OIwBK5lt8SF24UGjEXT74grU6L3SDTxvtlg== X-Google-Smtp-Source: AIpwx48QgZ4diWeQU3ZTm0JnJ94vuELGpvJpqZxdrEuxSl6MrBq+CN0lXRHUApDBFCoKhGoY2laWRfL99956hB8OfRY= X-Received: by 10.98.58.75 with SMTP id h72mr1559775pfa.209.1523339654236; Mon, 09 Apr 2018 22:54:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.138.9 with HTTP; Mon, 9 Apr 2018 22:54:13 -0700 (PDT) From: Fabio Zaccantte Date: Tue, 10 Apr 2018 02:54:13 -0300 Message-ID: To: i2rs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1256ecf691fc056978264b" Archived-At: Subject: [i2rs] I2RS has something implementable X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 05:54:17 -0000 --94eb2c1256ecf691fc056978264b Content-Type: text/plain; charset="UTF-8" Hello, good night, I'd like to know wether I2RS has something implementable or only rfc, if yes, what parts? Regards Fabio. --94eb2c1256ecf691fc056978264b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, good night,


I'd lik= e to know wether I2RS has something implementable or only rfc, if yes, what= parts?


Regards
Fabi= o.

--94eb2c1256ecf691fc056978264b-- From nobody Tue Apr 10 15:26:35 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E84812D7EF for ; Tue, 10 Apr 2018 15:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raWf43RuzVSY for ; Tue, 10 Apr 2018 15:26:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 50EC312421A for ; Tue, 10 Apr 2018 15:26:32 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3D07289A6B712 for ; Tue, 10 Apr 2018 23:26:27 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 10 Apr 2018 23:26:29 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML703-CHM.china.huawei.com ([169.254.5.179]) with mapi id 14.03.0382.000; Tue, 10 Apr 2018 15:26:22 -0700 From: Alexander Clemm To: Fabio Zaccantte , "i2rs@ietf.org" Thread-Topic: [i2rs] I2RS has something implementable Thread-Index: AQHT0JBsLv3ArI6lEkahSbCKXtsi+KP6lF1Q Date: Tue, 10 Apr 2018 22:26:21 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAF8466@sjceml521-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.217.34] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAF8466sjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [i2rs] I2RS has something implementable X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 22:26:34 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAF8466sjceml521mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbCwgaG9wZWZ1bGx5IGl0IGlzIGltcGxlbWVudGFibGU6LSkNCkkgYW0gYXdhcmUgb2YgaW1w bGVtZW50YXRpb25zIG9mIHRoZSB0b3BvbG9neSBtb2RlbCwgaS5lLiBSRkMgODM0NS84MzQ2LCBp biBPcGVuIERheWxpZ2h0Lg0KLS0tIEFsZXgNCg0KRnJvbTogaTJycyBbbWFpbHRvOmkycnMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEZhYmlvIFphY2NhbnR0ZQ0KU2VudDogTW9uZGF5 LCBBcHJpbCAwOSwgMjAxOCAxMDo1NCBQTQ0KVG86IGkycnNAaWV0Zi5vcmcNClN1YmplY3Q6IFtp MnJzXSBJMlJTIGhhcyBzb21ldGhpbmcgaW1wbGVtZW50YWJsZQ0KDQpIZWxsbywgZ29vZCBuaWdo dCwNCg0KDQpJJ2QgbGlrZSB0byBrbm93IHdldGhlciBJMlJTIGhhcyBzb21ldGhpbmcgaW1wbGVt ZW50YWJsZSBvciBvbmx5IHJmYywgaWYgeWVzLCB3aGF0IHBhcnRzPw0KDQoNClJlZ2FyZHMNCkZh YmlvLg0KDQo= --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAF8466sjceml521mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2VsbCwgaG9wZWZ1bGx5IGl0 IGlzIGltcGxlbWVudGFibGU6LSkmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFtIGF3YXJl IG9mIGltcGxlbWVudGF0aW9ucyBvZiB0aGUgdG9wb2xvZ3kgbW9kZWwsIGkuZS4gUkZDIDgzNDUv ODM0NiwgaW4gT3BlbiBEYXlsaWdodC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS0tIEFsZXg8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBpMnJzIFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5GYWJpbyBaYWNjYW50dGU8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAwOSwg MjAxOCAxMDo1NCBQTTxicj4NCjxiPlRvOjwvYj4gaTJyc0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBbaTJyc10gSTJSUyBoYXMgc29tZXRoaW5nIGltcGxlbWVudGFibGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8sIGdvb2Qg bmlnaHQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2QgbGlrZSB0 byBrbm93IHdldGhlciBJMlJTIGhhcyBzb21ldGhpbmcgaW1wbGVtZW50YWJsZSBvciBvbmx5IHJm YywgaWYgeWVzLCB3aGF0IHBhcnRzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GYWJpby48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAF8466sjceml521mbschi_-- From nobody Wed Apr 11 02:22:55 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850F4127333; Wed, 11 Apr 2018 02:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 Occ9VzyIihSQ; Wed, 11 Apr 2018 02:22:51 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0096.outbound.protection.outlook.com [104.47.2.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4EE1271DF; Wed, 11 Apr 2018 02:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mPU3SOeHEun/c+jmLQ93Je4nUZzw49jvs99rrUYyzPQ=; b=SWWRL5ljYJ3DKu0By5pUJ3KhYQGp9rGzU6MdOWV8Bkv6qT64+CmeL1mv2vhVN6NuIMsjAvdAIAt0brIk+k48NBx+IywDH+zgJagEqOq+X25h9nlQIhC5LaA/dRl0zXjRoH9tC8GMULKKh5jbIEJjkOcRcs1V6dpjmkNdc4b0Bu8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.165.129.75) by HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.6; Wed, 11 Apr 2018 09:22:47 +0000 Message-ID: <011801d3d176$90dc9e40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Alissa Cooper" , "Mach Chen" Cc: "IESG" , , , , References: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com> <00d801d3cf2e$92becf20$4001a8c0@gateway.2wire.net> Date: Wed, 11 Apr 2018 10:21:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.165.129.75] X-ClientProxiedBy: AM5P190CA0027.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:14::40) To HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 3:nHcYVZFCXu7Ed1UM/zmR08qyUMNRDq8TB76DVTn0aWsMPA+LBJHE2iWtm6bNi/LVVi5NWHROShXYvPB/TGiIzA3b66z9UWKoGKBDdg24acppiZ9FadoJtd10Sksj3HroVpS1ILwx1PmoPDBtP1oSq1laeSIDESvQnATDxV9jlswKUiSXUXUdS+iLwJjTJUnu2njyfYFQoVfysjoaIjerEKKjRv1uIgqfoTVFVlyFArrSyAnyQ5eIBqmGyqz8TJ5u3kj1P8yNtjroD6hZ72+eKE6AQccGPTwGJrHYZAT67o8=; 25:IU/TT9Uct83128uNRyu372RZp4a6OwkB6KuDw/shXdmTbqRGRou6fWU5G6qwLM6Yc0Pbd+cqMwOHA5qDJGmGqZ7Qdc4tiUD72ac6B+TgFKmTGoGuhXVv1dnaeCzpV0IEk4AKuqlbGdKn3Uq1RJhatfypksCEcX+kyqDKCzj12sIOKWt3MMu5N+ne77mOMuTrluYBFtblzY/l3Do5+ogyN/qTjCfMtUTJznFw9F5fTYQsi6bRHh94F0nFQpO3FNUGIdKh/9smXqja3yc6OJVEUAhOFUbMinwAgTulwO75WW/IJlayC3zS5nBm3nnYaF5JM6RSEQjxJHoATB17xNjc6A==; 31:3klkwWWSbP6qbf/+K0dJfuZ3mRp4amEWuhNXDLXSyxQmEMSag3KUeDVKP/j3kUVkXb4pxaSLIK4488JhfM/PsB57STjgml6fdKT5KjcveB0tTIj+15K+UqF7XK/yW8xXATJBQL+Q6ebSoMLjUjEmFTw+w9ik1sg9EmnU5avLjEGhlRonFoEiVRIwes/gmefXpd9LAkls5Tr4qS4jM8wn/6mteYA6nso2Raa/ZXWB8f4= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3003: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(120809045254105)(50582790962513)(15185016700835); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231221)(944501327)(52105095)(20161123222025)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 4:MZVQHfol+7RkGGUyiv3ToJuAml0pTtcctVW/uz0S9gtdZ4honvKg55e47gE9qu5QrCKo12jMi/e78O1TC0OILHwza9Y4ai7OuXdS34yE6Pj8Rw1QkwLoNyFW0InV3SPfI8P5WfO+xqiHi881EOuGI2hGut5BfsBbprroZkkqLtXbVXmaLEJv8E90Lqal70hiQhF9nPXcnJ3b8ViDze/AjkV34dy2XSD/8VO6Ppwgoq3r6XXxytu00ohQxVkokSvn+lMW46x5ayPmYZACGk2Jx2KO5MXGcUtgiUrVJ+IMUdtibR26ng2SpkvnVL6vrKVf+sdOdpKC9ytNo7B7RDEWZmmiFKgyxw0cIbZvSslrIimD6O5JIOr846ES19SDWGdchuaBcXeOjLgjna4csLcSdK9DH4/o3ADL2IRXB86SSIA= X-Forefront-PRVS: 0639027A9E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(366004)(376002)(396003)(39380400002)(199004)(189003)(51444003)(13464003)(1556002)(110136005)(25786009)(6496006)(6116002)(33896004)(6486002)(386003)(3846002)(5660300001)(14496001)(81816011)(81686011)(4326008)(7736002)(316002)(305945005)(106356001)(81156014)(53936002)(966005)(81166006)(54906003)(6246003)(86362001)(52116002)(956004)(68736007)(486006)(476003)(2486003)(76176011)(50226002)(4720700003)(62236002)(44716002)(2906002)(186003)(6666003)(66066001)(47776003)(97736004)(229853002)(478600001)(8676002)(2870700001)(23676004)(446003)(8936002)(44736005)(26005)(6306002)(93886005)(105586002)(53546011)(61296003)(84392002)(50466002)(16526019)(9686003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDM7MjM6TlhqSW9Ba3NWMVdpS2lQV21vd2pUc2Ra?= =?utf-8?B?Q3ZGK2l1RUJwSGNidThJMEVvZzNtS3RRN3pFcis0VW11aE5HVjBSdGd0MVJ1?= =?utf-8?B?TE4zTWZkUG84MytwUnROQm4xNFMva3JRekJ6MDJpbklTTlR1aHpDdWQ4QTFV?= =?utf-8?B?RExidXFSdmRQV3JGUEhFUHM4Q1ZKYkI2QnFSbXZmT0lRWkplUDRNYkRuakZP?= =?utf-8?B?RWh5U0F5Z0lJYk1pZHgyMXJwSWZuUWd5Q09XMXE2dFNZYkFqUm83dElRdEpC?= =?utf-8?B?Syt1RldqN3RpaTNTR2gvSldwRlM3bTJ4MVdRV0hNWWI0bkpuclloa215UEY4?= =?utf-8?B?elZzYmJBWG9VNFJGMS90N1JIbkFEU0pON09qcUxqVm8wTExGZk9DUXFaN2R5?= =?utf-8?B?QkN2VG9xL3hQazlSeWdqdnVHcXMxb0N4UTJjYkhjVmZ4bzZOMHpHZklka1Jo?= =?utf-8?B?Z0pOd214WmxQYkhJSm5zN3pMdEN3dDdDb3puS0hIcG1vVkhBN04vMEs0RWlx?= =?utf-8?B?MjJqcHUyM1VVeUlwb2d5TUY0TGUwckJ6WU9tOERaVUJtRi9yd0h1WG9kbjVR?= =?utf-8?B?ZEdYZklKMUFkVHlUOXVqalZtRFFVZUFmYWdISDczSDRReXZpbnZ1dEk0cENW?= =?utf-8?B?ekRBVmNRbHFHalo4emZLeDNKbTM4dUxoUFFTS3JtVHhDMFRhV2ZVL3lDWHRo?= =?utf-8?B?c3EvV2c3cm1TS2hrcmtBV2VjdCtETUhYczZ1Ynh4SWZBVWU1TG02a1dBQ29p?= =?utf-8?B?RkZmZnhtQ0Q5YlFiMzhBSzdpaDhMQW9vNXBRY1Foc1FMUU54dVpZZVhzZjE1?= =?utf-8?B?ZjJwSW00dTRxWlN6c1FDa3M5eDNvcmM1bEpJT0wzUjdETzg3UVdQN2dvTDZ3?= =?utf-8?B?VkxKNGN5dU9QblY2RnQ1S2YrNGxFdU94ZjFSc1lXZGhuRDVPZE8rMnZTRlkv?= =?utf-8?B?TVVJODRUellteDBrQkdXVjBmcXJKejRsbjhtVkNNampmK2Yya0NLM1EzU2JC?= =?utf-8?B?SnRDaUdMeWFpeU9KVldzdXlIVTUvWUNTS3QxbG5GK2tNS3BZQzYwUkpxYWYw?= =?utf-8?B?ekg0andLZSswRWtCQ1VtK3JOZUQ1SThpSmFqU3RCa3Z6a0szdmdVWlNWYzJU?= =?utf-8?B?WWFRbDdGeTJHUmhsQnRhR24rSjFmU0hIeFBEQTZjczZKaUZBcmZOT3JMMmdr?= =?utf-8?B?K3p5TGFqMmgyN01FS2Y5UmV6UlFGdjRvZC9Qa3NPWDZyeDBZeXBZTzFHVSt3?= =?utf-8?B?YW1xbzRXb3VadWNnMmUydjhxTTMxSEMzM253Z1diZEtCSEZBbjJkN2pzclR0?= =?utf-8?B?NUFOS3hQREEvc2pSTG8zM2JEMkN6SnhBaGZENncwaTJjTGliR09kQ2lsTFVT?= =?utf-8?B?V3VDR3dRT28rampZN3N1Uk5OQWozbGZEV0p4cTdIeTkyMXYwN2Q4R2RhZktu?= =?utf-8?B?WVlFS25zNFQwbjZpYmVRVVVWYmwzKzVUZ1R4aXNuaTBSYWI4YVZ5WUFNRDNy?= =?utf-8?B?L0F1Y2N1NS9tU3E2UTlSbFV1U05YS0QvaHI1bnN4d0pZbUM1T3pCbmFTT1lT?= =?utf-8?B?anNnZ1NaNWdJcTQyc3RWMWJvMlZVQVAvRFllcjVZem1MLy9Ca2E0bm9QVUt3?= =?utf-8?B?elBBUVpvY3RXTjdEdlk5ME9RaytmSktFNHJuTlc5a3V6azUrcjZab0VkNzVz?= =?utf-8?B?TDVjTE1VckNkUXoxbzRDTGY2SHkvUnRTczBPdWl4c2VkbHNkM01UUWdtUTd4?= =?utf-8?B?RmNqRGY4K1JLM3JkODE5MWoxMElQWDBLSThXTElHc3dDMzdHNGNZQ1dEZW9S?= =?utf-8?B?OGhZYjJoNm5VMmg2MUM3aDRsNVhJUUJnYThEUFl2SXNqUWhLMmlEbUVDUlVz?= =?utf-8?B?M1pYK3pQUVNqK04wV2daeUhTVk5kVmJoY3JPcktUb01hNXFRSXJtSlQrcTg5?= =?utf-8?B?NVpZekkrNHd0TGhVcTFVSWcrZ3A1TmZ4azNKcFEyMmRBcjQwQVhZbnpaVmUz?= =?utf-8?B?OVVMaWsxUFgwQzVMR2dSd05SZ2FEUlk3aWsvN3J2MnZlZlY4MHRjY1g2b25w?= =?utf-8?B?djd3OGVoblRkaC84YW85em1YdXBYOG0xQ3lyemh2WWJFY2dONkV3YmU3WHE3?= =?utf-8?Q?kA8loeL+kAuK/aQaX8KbIUsjk=3D?= X-Microsoft-Antispam-Message-Info: FBWyUH+SRFVWzpgLQaX9tXhIzbou/xoefXrmrKBfrl09XNkud8OqIJGTy5uPXEXECnGfz1XpIt5rvzJoftrw7FbJ9T8/uyRL4UtGAiTSp5Ry5vSs/M7cmq2+lMnlRXabo+UtxpPF9QxMhA6pAPogA4rBnehtcFuBjh7rf+97P4dceFgtDHIiFMO5hAEHIAf8 X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:57EG9lQOhD3PE6h1yFhcm5dR0COmmyP5JY00ds0ZglhdYyGz8TlHX3km7MGGMl5Aes6ZkNirJihisJ+xJRXa71qxD81Kxo31H+zcTHKUsuDiyg8Z7kVyeSJJqHQgYDo/DOsmu9xvwZctKmM9FA4w00j80Z+jgcH9eA5hdP4xZHW67wOmVVVfagcICokijbBFv+Z94P2iBoWD/HKmfUDsXtTDzIJPv2YI7mifxJF2FoOwCFY8x6ihUZb+goLuhVrCFYEMJ38TYkkWlvtNIl8pag9Z1B72sFmSnSzdSwX96GOln8E+jlfz3prY7g4Md6EF146zz54BJalifa/J4E/Yjo16Hhbeap15Fbx9nK1vkFAj6+avoW9nPEy7L9D1iQjueGeFpE0SM+21JkmoorRsFWbP0ftHkwdU0Ogj8Sd6YQ4O2mggj+b9BrTev6z/wWqXsW+JT1bU520h7knLEZ0wQw==; 5:aAVdIpiUYgBZvfWilgpFy/EUilLPtWzGRqShP4M9WgQytQLTPdejD7+A7AI0CPWMpF66jgzUJ+fdf/aRmcQU4rEWd5EvruqOAkEtp1m4oiIC4Uh6c+nrADWGkY7xzCGkjhaSAcJp6u8XED5spbuSE4uLz0ARJ9S+xNeX0v9gexc=; 24:TluVthkFtaf7WiORnmME0IpNguD98BwXkDSePf2oHHVh5K0SCejqG6AiXRjVRAio3bB2lN4P0zt7/NAm4ZE/LRZN4KjN9ZD1vtTRPF7PFtU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 7:KFt16tz24Zliv6zQku3FsQ00duz9iFlGn0uvluJFLq07UhoQdK3olTfunpyfBY1vi8QHiofE92FEbRxxfwtheZEjj3OVZRM15NLoYBXV61IP7LRdYy6xhbITuyTx3rhTzabysYCPwGDVnRQs1fAeAu8zZpVzYeYc/48aPCq1pkvhaikxD0sfeTfjWDfe6t5FH1Od0rc6VEpA/0xYfpRBo9HRG3uI+9G2fPL2dcRoVMtkFgMkG1OI5GFF3URy4S9x X-MS-Office365-Filtering-Correlation-Id: 4d807a2c-ac7a-41d7-ab1d-08d59f8dca76 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2018 09:22:47.0804 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4d807a2c-ac7a-41d7-ab1d-08d59f8dca76 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003 Archived-At: Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 09:22:54 -0000 Mach One additional thought on tree diagrams. This is now RFC8340 and YANG guidelines 6087bis section 3.4 says " If YANG tree diagrams are used, then an informative reference to the YANG tree diagrams specification MUST be included in the document. " whereas you currently have it as a Normative Reference (well, perhaps two related thoughts:-( Tom Petch ----- Original Message ----- From: "Alissa Cooper" Sent: Monday, April 09, 2018 8:50 PM > On Apr 8, 2018, at 9:20 AM, Mach Chen wrote: > > Hi Tom, > >> -----Original Message----- >> From: t.petch [mailto:ietfc@btconnect.com] >> Sent: Sunday, April 08, 2018 7:42 PM >> To: Mach Chen ; Alissa Cooper >> ; The IESG >> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i2rs-chairs@ietf.org; >> shares@ndzh.com >> Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data- >> model-10: (with COMMENT) >> >> ---- Original Message ----- >> From: "Mach Chen" >> To: "Alissa Cooper" ; "The IESG" >> Cc: ; ; >> ; >> Sent: Sunday, April 08, 2018 9:23 AM >> >>> Hi Alissa, >>> >>> Thanks for your comments! >>> >>> Please see my responses inline... >>> >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa Cooper >>>> Sent: Tuesday, April 03, 2018 11:10 PM >>>> To: The IESG >>>> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; >> i2rs-chairs@ietf.org; >>>> shares@ndzh.com >>>> Subject: [i2rs] Alissa Cooper's No Objection on >> draft-ietf-i2rs-rib-data-model-10: >>>> (with COMMENT) >>>> >>>> Alissa Cooper has entered the following ballot position for >>>> draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ >>>> >>>> >>>> >>> >>> -------------------------------------------------------------------- -- >>>> COMMENT: >>> >>> -------------------------------------------------------------------- -- >>>> >>>> Sec 1.2: >>>> >>>> "YANG tree diagrams provide a concise representation of a YANG >> module, >>>> and SHOULD be included to help readers understand YANG module >>>> structure." >>>> >>>> This document does not seem like an appropriate place to have >> normative >>>> guidance about this. And if this sentence is removed, I don't see >> the point of >>>> including Section 1.2 otherwise. This would also imply deleting the >> reference to >>>> I-D.ietf-netmod-yang-tree-diagrams. >>> >>> This results from a YANG doctor review. I saw it also occurs in other >> published documents. I personally think it's no harm to keep it, how do you >> think? >> >> Mach >> >> I think that this is very odd. >> >> YANG guidelines rfc6087bis says >> " YANG tree diagrams provide a concise representation of a YANG >> module, >> and SHOULD be included to help readers understand YANG module >> structure. Guidelines on tree diagrams can be found in Section 3 of >> [I-D.ietf-netmod-yang-tree-diagrams]. >> " >> which I think is the correct guidance in the correct place. >> >> A quick look at the recently published RFC8343, RFC8344, RFC8345, >> RFC8346 contain no text of the kind you suggest so if it occurs in other I-D, then >> I would regard those other I-D as being in error. >> >> If I look back at a thread from Ebben for a yang doctor review of an earlier >> version of this I-D, the text I see proposed is >> >> " >>> A simplified graphical representation of the data model is used in >>> this document. The meaning of the symbols in these diagrams is >>> defined in [I-D.ietf-netmod-yang-tree-diagrams]. >> " >> which I think is rather different. > > Indeed, my fault, I just checked Ebben's suggestion, it's as above quoted. > > To Alissa: > If change to following text, is it OK for you? > > "A simplified graphical representation of the data model is used in > this document. The meaning of the symbols in these diagrams is > defined in [I-D.ietf-netmod-yang-tree-diagrams].” Yes, thanks. Alissa > > > Best regards, > Mach >> >> Tom Petch >> (not a YANG doctor) >> >>>> >>>> Sec 2.1: Again here I'm confused about the use of normative >> language. Why do >>>> you need to specify normative requirements for what this very >> document is >>>> specifying? Or are these supposed to be requirements on >> implementations? >>> >>> OK, how about this: >>> >>> "...a RIB data model needs to specify a way for an external entity to >> learn about the functional capabilities of a network device." And >>> >>> " The RIB data model needs a way to expose the nexthop chaining >> capability supported by a given network device." >>> >>>> >>>> Sec 2.5: s/causes/caused/ >>> >>> Done >>> >>> The above updates will be reelected in version-11. >>> >>> Thanks, >>> Mach >>>> > From nobody Wed Apr 11 11:01:20 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EF9129502 for ; Wed, 11 Apr 2018 11:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 QOvAHDBtdKdF for ; Wed, 11 Apr 2018 11:01:17 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 2757B128D2E for ; Wed, 11 Apr 2018 11:01:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.120.167; From: "Susan Hares" To: "'t.petch'" Cc: References: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com> <00d801d3cf2e$92becf20$4001a8c0@gateway.2wire.net> <011801d3d176$90dc9e40$4001a8c0@gateway.2wire.net> In-Reply-To: <011801d3d176$90dc9e40$4001a8c0@gateway.2wire.net> Date: Wed, 11 Apr 2018 14:01:06 -0400 Message-ID: <011301d3d1bf$10e6b470$32b41d50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGaPyxkPDbyGdF7yadUUUstfBcVZwMWvGGkAcL9pqECmtwzEQGVgS7BAbPYW+WkGRAyMA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 18:01:20 -0000 Tom - thank you for your continued review of this work! Sue Hares=20 -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com]=20 Sent: Wednesday, April 11, 2018 5:22 AM To: Alissa Cooper; Mach Chen Cc: IESG; i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; = i2rs-chairs@ietf.org; shares@ndzh.com Subject: Re: [i2rs] Alissa Cooper's No Objection on = draft-ietf-i2rs-rib-data-model-10: (with COMMENT) Mach One additional thought on tree diagrams. This is now RFC8340 and YANG guidelines 6087bis section 3.4 says " If YANG tree diagrams are used, then an informative reference to the YANG tree diagrams specification MUST be included in the document. " whereas you currently have it as a Normative Reference (well, perhaps = two related thoughts:-( Tom Petch ----- Original Message ----- From: "Alissa Cooper" Sent: Monday, April 09, 2018 8:50 PM > On Apr 8, 2018, at 9:20 AM, Mach Chen wrote: > > Hi Tom, > >> -----Original Message----- >> From: t.petch [mailto:ietfc@btconnect.com] >> Sent: Sunday, April 08, 2018 7:42 PM >> To: Mach Chen ; Alissa Cooper=20 >> ; The IESG >> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i2rs-chairs@ietf.org; >> shares@ndzh.com >> Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data- >> model-10: (with COMMENT) >> >> ---- Original Message ----- >> From: "Mach Chen" >> To: "Alissa Cooper" ; "The IESG" >> Cc: ; ; >> ; >> Sent: Sunday, April 08, 2018 9:23 AM >> >>> Hi Alissa, >>> >>> Thanks for your comments! >>> >>> Please see my responses inline... >>> >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa Cooper >>>> Sent: Tuesday, April 03, 2018 11:10 PM >>>> To: The IESG >>>> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; >> i2rs-chairs@ietf.org; >>>> shares@ndzh.com >>>> Subject: [i2rs] Alissa Cooper's No Objection on >> draft-ietf-i2rs-rib-data-model-10: >>>> (with COMMENT) >>>> >>>> Alissa Cooper has entered the following ballot position for >>>> draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ >>>> >>>> >>>> >>> >>> -------------------------------------------------------------------- -- >>>> COMMENT: >>> >>> -------------------------------------------------------------------- -- >>>> >>>> Sec 1.2: >>>> >>>> "YANG tree diagrams provide a concise representation of a YANG >> module, >>>> and SHOULD be included to help readers understand YANG module >>>> structure." >>>> >>>> This document does not seem like an appropriate place to have >> normative >>>> guidance about this. And if this sentence is removed, I don't see >> the point of >>>> including Section 1.2 otherwise. This would also imply deleting the >> reference to >>>> I-D.ietf-netmod-yang-tree-diagrams. >>> >>> This results from a YANG doctor review. I saw it also occurs in other >> published documents. I personally think it's no harm to keep it, how do you >> think? >> >> Mach >> >> I think that this is very odd. >> >> YANG guidelines rfc6087bis says >> " YANG tree diagrams provide a concise representation of a YANG >> module, >> and SHOULD be included to help readers understand YANG module >> structure. Guidelines on tree diagrams can be found in Section 3 of >> [I-D.ietf-netmod-yang-tree-diagrams]. >> " >> which I think is the correct guidance in the correct place. >> >> A quick look at the recently published RFC8343, RFC8344, RFC8345, >> RFC8346 contain no text of the kind you suggest so if it occurs in other I-D, then >> I would regard those other I-D as being in error. >> >> If I look back at a thread from Ebben for a yang doctor review of an earlier >> version of this I-D, the text I see proposed is >> >> " >>> A simplified graphical representation of the data model is used in >>> this document. The meaning of the symbols in these diagrams is >>> defined in [I-D.ietf-netmod-yang-tree-diagrams]. >> " >> which I think is rather different. > > Indeed, my fault, I just checked Ebben's suggestion, it's as above quoted. > > To Alissa: > If change to following text, is it OK for you? > > "A simplified graphical representation of the data model is used in=20 > this document. The meaning of the symbols in these diagrams is=20 > defined in [I-D.ietf-netmod-yang-tree-diagrams].=E2=80=9D Yes, thanks. Alissa > > > Best regards, > Mach >> >> Tom Petch >> (not a YANG doctor) >> >>>> >>>> Sec 2.1: Again here I'm confused about the use of normative >> language. Why do >>>> you need to specify normative requirements for what this very >> document is >>>> specifying? Or are these supposed to be requirements on >> implementations? >>> >>> OK, how about this: >>> >>> "...a RIB data model needs to specify a way for an external entity to >> learn about the functional capabilities of a network device." And >>> >>> " The RIB data model needs a way to expose the nexthop chaining >> capability supported by a given network device." >>> >>>> >>>> Sec 2.5: s/causes/caused/ >>> >>> Done >>> >>> The above updates will be reelected in version-11. >>> >>> Thanks, >>> Mach >>>> > From nobody Wed Apr 11 23:07:53 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12B3127058; Wed, 11 Apr 2018 23:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kuu2bs2Ykzj1; Wed, 11 Apr 2018 23:07:44 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 35831126E64; Wed, 11 Apr 2018 23:07:44 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6FDF139D55AB6; Thu, 12 Apr 2018 07:07:40 +0100 (IST) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 12 Apr 2018 07:07:41 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.73]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0361.001; Thu, 12 Apr 2018 14:07:39 +0800 From: Mach Chen To: t.petch , Alissa Cooper CC: IESG , "i2rs@ietf.org" , "draft-ietf-i2rs-rib-data-model@ietf.org" , "i2rs-chairs@ietf.org" , "shares@ndzh.com" Thread-Topic: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) Thread-Index: AQHTy13moi2oBFWZPEShrejzOgw/4qP2htDAgAA/0nCAABhS0IABfEQAgAL7abCAAVtD8A== Date: Thu, 12 Apr 2018 06:07:38 +0000 Message-ID: References: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com> <00d801d3cf2e$92becf20$4001a8c0@gateway.2wire.net> <011801d3d176$90dc9e40$4001a8c0@gateway.2wire.net> In-Reply-To: <011801d3d176$90dc9e40$4001a8c0@gateway.2wire.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 06:07:47 -0000 SGkgVG9tLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMhDQoNCkl0IHdpbGwgYmUgZml4ZWQg aW4gdGhlIHVwY29taW5nIHZlcnNpb24tMTEuDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0LnBldGNoIFttYWlsdG86aWV0ZmNA YnRjb25uZWN0LmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMSwgMjAxOCA1OjIyIFBN DQo+IFRvOiBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj47IE1hY2ggQ2hlbiA8bWFj aC5jaGVuQGh1YXdlaS5jb20+DQo+IENjOiBJRVNHIDxpZXNnQGlldGYub3JnPjsgaTJyc0BpZXRm Lm9yZzsgZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsQGlldGYub3JnOw0KPiBpMnJzLWNo YWlyc0BpZXRmLm9yZzsgc2hhcmVzQG5kemguY29tDQo+IFN1YmplY3Q6IFJlOiBbaTJyc10gQWxp c3NhIENvb3BlcidzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtDQo+ IG1vZGVsLTEwOiAod2l0aCBDT01NRU5UKQ0KPiANCj4gTWFjaA0KPiANCj4gT25lIGFkZGl0aW9u YWwgdGhvdWdodCBvbiB0cmVlIGRpYWdyYW1zLg0KPiANCj4gVGhpcyBpcyBub3cgUkZDODM0MA0K PiANCj4gYW5kDQo+IA0KPiBZQU5HIGd1aWRlbGluZXMgNjA4N2JpcyBzZWN0aW9uIDMuNCBzYXlz DQo+IA0KPiAiICAgSWYgWUFORyB0cmVlIGRpYWdyYW1zIGFyZSB1c2VkLCB0aGVuIGFuIGluZm9y bWF0aXZlIHJlZmVyZW5jZSB0byB0aGUNCj4gICAgWUFORyB0cmVlIGRpYWdyYW1zIHNwZWNpZmlj YXRpb24gTVVTVCBiZSBpbmNsdWRlZCBpbiB0aGUgZG9jdW1lbnQuDQo+ICINCj4gd2hlcmVhcyB5 b3UgY3VycmVudGx5IGhhdmUgaXQgYXMgYSBOb3JtYXRpdmUgUmVmZXJlbmNlICh3ZWxsLCBwZXJo YXBzIHR3bw0KPiByZWxhdGVkIHRob3VnaHRzOi0oDQo+IA0KPiBUb20gUGV0Y2gNCj4gDQo+IC0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogIkFsaXNzYSBDb29wZXIiIDxhbGlz c2FAY29vcGVydy5pbj4NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAwOSwgMjAxOCA4OjUwIFBNDQo+ IA0KPiA+IE9uIEFwciA4LCAyMDE4LCBhdCA5OjIwIEFNLCBNYWNoIENoZW4gPG1hY2guY2hlbkBo dWF3ZWkuY29tPiB3cm90ZToNCj4gPg0KPiA+IEhpIFRvbSwNCj4gPg0KPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiB0LnBldGNoIFttYWlsdG86aWV0ZmNAYnRjb25u ZWN0LmNvbV0NCj4gPj4gU2VudDogU3VuZGF5LCBBcHJpbCAwOCwgMjAxOCA3OjQyIFBNDQo+ID4+ IFRvOiBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPjsgQWxpc3NhIENvb3Blcg0KPiA+ PiA8YWxpc3NhQGNvb3BlcncuaW4+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gPj4gQ2M6 IGkycnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbEBpZXRmLm9yZzsN Cj4gaTJycy1jaGFpcnNAaWV0Zi5vcmc7DQo+ID4+IHNoYXJlc0BuZHpoLmNvbQ0KPiA+PiBTdWJq ZWN0OiBSZTogW2kycnNdIEFsaXNzYSBDb29wZXIncyBObyBPYmplY3Rpb24gb24NCj4gZHJhZnQt aWV0Zi1pMnJzLXJpYi1kYXRhLQ0KPiA+PiBtb2RlbC0xMDogKHdpdGggQ09NTUVOVCkNCj4gPj4N Cj4gPj4gLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4+IEZyb206ICJNYWNoIENoZW4i IDxtYWNoLmNoZW5AaHVhd2VpLmNvbT4NCj4gPj4gVG86ICJBbGlzc2EgQ29vcGVyIiA8YWxpc3Nh QGNvb3BlcncuaW4+OyAiVGhlIElFU0ciIDxpZXNnQGlldGYub3JnPg0KPiA+PiBDYzogPGkycnNA aWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsQGlldGYub3JnPjsNCj4g Pj4gPGkycnMtY2hhaXJzQGlldGYub3JnPjsgPHNoYXJlc0BuZHpoLmNvbT4NCj4gPj4gU2VudDog U3VuZGF5LCBBcHJpbCAwOCwgMjAxOCA5OjIzIEFNDQo+ID4+DQo+ID4+PiBIaSBBbGlzc2EsDQo+ ID4+Pg0KPiA+Pj4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KPiA+Pj4NCj4gPj4+IFBsZWFz ZSBzZWUgbXkgcmVzcG9uc2VzIGlubGluZS4uLg0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGlzc2ENCj4gQ29vcGVyDQo+ID4+Pj4gU2VudDogVHVlc2Rh eSwgQXByaWwgMDMsIDIwMTggMTE6MTAgUE0NCj4gPj4+PiBUbzogVGhlIElFU0cgPGllc2dAaWV0 Zi5vcmc+DQo+ID4+Pj4gQ2M6IGkycnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0 YS1tb2RlbEBpZXRmLm9yZzsNCj4gPj4gaTJycy1jaGFpcnNAaWV0Zi5vcmc7DQo+ID4+Pj4gc2hh cmVzQG5kemguY29tDQo+ID4+Pj4gU3ViamVjdDogW2kycnNdIEFsaXNzYSBDb29wZXIncyBObyBP YmplY3Rpb24gb24NCj4gPj4gZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTEwOg0KPiA+ Pj4+ICh3aXRoIENPTU1FTlQpDQo+ID4+Pj4NCj4gPj4+PiBBbGlzc2EgQ29vcGVyIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+Pj4+IGRyYWZ0LWlldGYt aTJycy1yaWItZGF0YS1tb2RlbC0xMDogTm8gT2JqZWN0aW9uDQo+ID4+Pj4NCj4gPj4+PiBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0bw0KPiA+PiBhbGwgZW1haWwNCj4gPj4+PiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRv IGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPiA+PiBpbnRyb2R1Y3RvcnkN Cj4gPj4+PiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBQbGVh c2UgcmVmZXIgdG8NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlz Y3Vzcy1jcml0ZXJpYS5odG1sDQo+ID4+Pj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4g VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZCBoZXJlOg0KPiA+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC8NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+ DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiA+Pj4+IENPTU1FTlQ6DQo+ID4+Pg0KPiA+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gLS0NCj4gPj4+Pg0KPiA+Pj4+IFNlYyAxLjI6DQo+ID4+Pj4NCj4gPj4+ PiAiWUFORyB0cmVlIGRpYWdyYW1zIHByb3ZpZGUgYSBjb25jaXNlIHJlcHJlc2VudGF0aW9uIG9m IGEgWUFORw0KPiA+PiBtb2R1bGUsDQo+ID4+Pj4gICBhbmQgU0hPVUxEIGJlIGluY2x1ZGVkIHRv IGhlbHAgcmVhZGVycyB1bmRlcnN0YW5kIFlBTkcgbW9kdWxlDQo+ID4+Pj4gICBzdHJ1Y3R1cmUu Ig0KPiA+Pj4+DQo+ID4+Pj4gVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBzZWVtIGxpa2UgYW4gYXBw cm9wcmlhdGUgcGxhY2UgdG8gaGF2ZQ0KPiA+PiBub3JtYXRpdmUNCj4gPj4+PiBndWlkYW5jZSBh Ym91dCB0aGlzLiBBbmQgaWYgdGhpcyBzZW50ZW5jZSBpcyByZW1vdmVkLCBJIGRvbid0IHNlZQ0K PiA+PiB0aGUgcG9pbnQgb2YNCj4gPj4+PiBpbmNsdWRpbmcgU2VjdGlvbiAxLjIgb3RoZXJ3aXNl LiBUaGlzIHdvdWxkIGFsc28gaW1wbHkgZGVsZXRpbmcgdGhlDQo+ID4+IHJlZmVyZW5jZSB0bw0K PiA+Pj4+IEktRC5pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMuDQo+ID4+Pg0KPiA+Pj4g VGhpcyByZXN1bHRzIGZyb20gYSBZQU5HIGRvY3RvciByZXZpZXcuICBJIHNhdyBpdCBhbHNvIG9j Y3VycyBpbg0KPiBvdGhlcg0KPiA+PiBwdWJsaXNoZWQgZG9jdW1lbnRzLiBJIHBlcnNvbmFsbHkg dGhpbmsgaXQncyBubyBoYXJtIHRvIGtlZXAgaXQsIGhvdw0KPiBkbyB5b3UNCj4gPj4gdGhpbms/ DQo+ID4+DQo+ID4+IE1hY2gNCj4gPj4NCj4gPj4gSSB0aGluayB0aGF0IHRoaXMgaXMgdmVyeSBv ZGQuDQo+ID4+DQo+ID4+IFlBTkcgZ3VpZGVsaW5lcyByZmM2MDg3YmlzIHNheXMNCj4gPj4gIiAg IFlBTkcgdHJlZSBkaWFncmFtcyBwcm92aWRlIGEgY29uY2lzZSByZXByZXNlbnRhdGlvbiBvZiBh IFlBTkcNCj4gPj4gbW9kdWxlLA0KPiA+PiAgIGFuZCBTSE9VTEQgYmUgaW5jbHVkZWQgdG8gaGVs cCByZWFkZXJzIHVuZGVyc3RhbmQgWUFORyBtb2R1bGUNCj4gPj4gICBzdHJ1Y3R1cmUuICBHdWlk ZWxpbmVzIG9uIHRyZWUgZGlhZ3JhbXMgY2FuIGJlIGZvdW5kIGluIFNlY3Rpb24gMw0KPiBvZg0K PiA+PiAgIFtJLUQuaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zXS4NCj4gPj4gIg0KPiA+ PiB3aGljaCBJIHRoaW5rIGlzIHRoZSBjb3JyZWN0IGd1aWRhbmNlIGluIHRoZSBjb3JyZWN0IHBs YWNlLg0KPiA+Pg0KPiA+PiBBIHF1aWNrIGxvb2sgYXQgdGhlIHJlY2VudGx5IHB1Ymxpc2hlZCBS RkM4MzQzLCBSRkM4MzQ0LCBSRkM4MzQ1LA0KPiA+PiBSRkM4MzQ2IGNvbnRhaW4gbm8gdGV4dCBv ZiB0aGUga2luZCB5b3Ugc3VnZ2VzdCBzbyBpZiBpdCBvY2N1cnMgaW4NCj4gb3RoZXIgSS1ELCB0 aGVuDQo+ID4+IEkgd291bGQgcmVnYXJkIHRob3NlIG90aGVyIEktRCBhcyBiZWluZyBpbiBlcnJv ci4NCj4gPj4NCj4gPj4gSWYgSSBsb29rIGJhY2sgYXQgYSB0aHJlYWQgZnJvbSBFYmJlbiBmb3Ig YSB5YW5nIGRvY3RvciByZXZpZXcgb2YgYW4NCj4gZWFybGllcg0KPiA+PiB2ZXJzaW9uIG9mIHRo aXMgSS1ELCB0aGUgdGV4dCBJIHNlZSBwcm9wb3NlZCBpcw0KPiA+Pg0KPiA+PiAiDQo+ID4+PiAg IEEgc2ltcGxpZmllZCBncmFwaGljYWwgcmVwcmVzZW50YXRpb24gb2YgdGhlIGRhdGEgbW9kZWwg aXMgdXNlZCBpbg0KPiA+Pj4gICB0aGlzIGRvY3VtZW50LiAgVGhlIG1lYW5pbmcgb2YgdGhlIHN5 bWJvbHMgaW4gdGhlc2UgZGlhZ3JhbXMgaXMNCj4gPj4+ICAgZGVmaW5lZCBpbiBbSS1ELmlldGYt bmV0bW9kLXlhbmctdHJlZS1kaWFncmFtc10uDQo+ID4+ICINCj4gPj4gd2hpY2ggSSB0aGluayBp cyByYXRoZXIgZGlmZmVyZW50Lg0KPiA+DQo+ID4gSW5kZWVkLCBteSBmYXVsdCwgSSBqdXN0IGNo ZWNrZWQgRWJiZW4ncyBzdWdnZXN0aW9uLCBpdCdzIGFzIGFib3ZlDQo+IHF1b3RlZC4NCj4gPg0K PiA+IFRvIEFsaXNzYToNCj4gPiBJZiBjaGFuZ2UgdG8gZm9sbG93aW5nIHRleHQsIGlzIGl0IE9L IGZvciB5b3U/DQo+ID4NCj4gPiAiQSBzaW1wbGlmaWVkIGdyYXBoaWNhbCByZXByZXNlbnRhdGlv biBvZiB0aGUgZGF0YSBtb2RlbCBpcyB1c2VkIGluDQo+ID4gdGhpcyBkb2N1bWVudC4gIFRoZSBt ZWFuaW5nIG9mIHRoZSBzeW1ib2xzIGluIHRoZXNlIGRpYWdyYW1zIGlzDQo+ID4gZGVmaW5lZCBp biBbSS1ELmlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtc10u4oCdDQo+IA0KPiBZZXMsIHRo YW5rcy4NCj4gQWxpc3NhDQo+IA0KPiA+DQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gTWFj aA0KPiA+Pg0KPiA+PiBUb20gUGV0Y2gNCj4gPj4gKG5vdCBhIFlBTkcgZG9jdG9yKQ0KPiA+Pg0K PiA+Pj4+DQo+ID4+Pj4gU2VjIDIuMTogQWdhaW4gaGVyZSBJJ20gY29uZnVzZWQgYWJvdXQgdGhl IHVzZSBvZiBub3JtYXRpdmUNCj4gPj4gbGFuZ3VhZ2UuIFdoeSBkbw0KPiA+Pj4+IHlvdSBuZWVk IHRvIHNwZWNpZnkgbm9ybWF0aXZlIHJlcXVpcmVtZW50cyBmb3Igd2hhdCB0aGlzIHZlcnkNCj4g Pj4gZG9jdW1lbnQgaXMNCj4gPj4+PiBzcGVjaWZ5aW5nPyBPciBhcmUgdGhlc2Ugc3VwcG9zZWQg dG8gYmUgcmVxdWlyZW1lbnRzIG9uDQo+ID4+IGltcGxlbWVudGF0aW9ucz8NCj4gPj4+DQo+ID4+ PiBPSywgaG93IGFib3V0IHRoaXM6DQo+ID4+Pg0KPiA+Pj4gIi4uLmEgUklCIGRhdGEgbW9kZWwg bmVlZHMgdG8gc3BlY2lmeSBhIHdheSBmb3IgYW4gZXh0ZXJuYWwgZW50aXR5DQo+IHRvDQo+ID4+ IGxlYXJuIGFib3V0IHRoZSBmdW5jdGlvbmFsIGNhcGFiaWxpdGllcyBvZiBhIG5ldHdvcmsgZGV2 aWNlLiIgQW5kDQo+ID4+Pg0KPiA+Pj4gIiBUaGUgUklCIGRhdGEgbW9kZWwgbmVlZHMgYSB3YXkg dG8gZXhwb3NlIHRoZSBuZXh0aG9wIGNoYWluaW5nDQo+ID4+IGNhcGFiaWxpdHkgc3VwcG9ydGVk IGJ5IGEgZ2l2ZW4gbmV0d29yayBkZXZpY2UuIg0KPiA+Pj4NCj4gPj4+Pg0KPiA+Pj4+IFNlYyAy LjU6IHMvY2F1c2VzL2NhdXNlZC8NCj4gPj4+DQo+ID4+PiBEb25lDQo+ID4+Pg0KPiA+Pj4gVGhl IGFib3ZlIHVwZGF0ZXMgd2lsbCBiZSByZWVsZWN0ZWQgaW4gdmVyc2lvbi0xMS4NCj4gPj4+DQo+ ID4+PiBUaGFua3MsDQo+ID4+PiBNYWNoDQo+ID4+Pj4NCj4gPg0KDQo= From nobody Thu Apr 12 23:02:00 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DF9126D45 for ; Thu, 12 Apr 2018 23:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 ohM5dfP7VRyO for ; Thu, 12 Apr 2018 23:01:57 -0700 (PDT) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (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 26BA2126DFF for ; Thu, 12 Apr 2018 23:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1523599315; bh=QCt0A3I0ddKe7wGPVOdOZBEoJswZGCO1ryJA7N5Ctx4=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=keY7WW3qF52QjGCIZZUNtehQ0iKXDjwXKT/D3OISHDXKIuXlp0NCQG56ikQIGaw6klAnPlLPnzm7uCZOR0QiYXydvxQjAeJSG1BDzL0QY0kgEDpN+ZynUkmDyK35Ym+d80FpX4/pFfdilJpA/GY4Xh9MZg2ZANJJvWR74c+m0t65490cp/edNHfBCd/ttbZ0F8N18X/MoExvXNuIPaMeBKH5TaB50kpLzdE/YtVnbfJPXCGc0Af7NxJFUWM0B1Uepi3t6adyamz8+4joPnAbbK1/y93zo8YR0AZ2qNZKtVoLPqEywjGuRC71UDmUjx+kKshusVpjYCfjvGh/X1eF9A== X-YMail-OSG: eTGoD7MVM1mTnt2NgO58K1WPgwc2Jls.IOtw_A10KTMSnXuXRfvvM0MXpFQ8MIT Vcq.0Tmczn8c3dC2sw9JpNgQzktDZAZ3sVK_vWEPUBIm1RD5rEORCAR60CaayW3n504NoKABKd1i 59rWTxHlSAkw5SoYmaFGZ1RmwEMOX_X4c.y6TzEXLi.u6d_D0VmCfzHz.7VUxJAysXfzh46hpbsB tvEdTWLXZvhwQc65YD9LHgAklARDvZ6cSHNz98A15ErHvO7LRUKFLIndyS9k2JQCCX6nU4HmnDhI 0rMHtRN.LAPwdaUoYmCMARTQaHlyDcqFHQ40tCYzeccDaGS1dAkM0cB72SkJtJTHV6HLaBiEJ9Ok 3sSz0zhUexCpR9PVsHl4j_isrTjCyEDvDFWxX0AVEqmAXEzIGD6RbtXw6ltJdtjB20U.e0.FTNH7 gW96kFeugZgAjdFjMUJC4ldNe.JsfXpIxa.THa8GptKWjPwUlegnVS.GA_MfNxRdMnWs6ev_QRg3 7J2Hukqbimc8YSg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 13 Apr 2018 06:01:55 +0000 Received: from c-73-158-191-172.hsd1.ca.comcast.net (EHLO [192.168.0.106]) ([73.158.191.172]) by smtp432.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0e982fd1cf02a906420b3fcea109ed8d; Fri, 13 Apr 2018 05:51:53 +0000 (UTC) User-Agent: Microsoft-MacOutlook/10.9.0.180116 Date: Thu, 12 Apr 2018 22:51:50 -0700 From: Nitin Bahadur To: Susan Hares , 'Suresh Krishnan' , 'The IESG' CC: , , Message-ID: <1CF12BE1-AE55-43CF-95B4-66BC5B67E38F@yahoo.com> Thread-Topic: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) References: <152290489812.25948.2495908999143424774.idtracker@ietfa.amsl.com> <045701d3cce7$1c8bec00$55a3c400$@ndzh.com> In-Reply-To: <045701d3cce7$1c8bec00$55a3c400$@ndzh.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 06:01:59 -0000 Hi Suresh, Thanks for the review. Please see NB> below for comments. Did you mean 2001:DB8::1/128 for the host route? If not, this example is wrong since 2001:DB8::1/32 expands to 2001:DB8:0000:0000:0000:0000:0000:1/32 -> 2001:DB8::/32 as the route Sue: Yes - this is an error. NB> Nice catch. Fixing it in next rev. * Figure 4. Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into nexthop processing just like the derived nexthops do? Suresh - I need to check the email list archives and get back to you on this point. My recollection was that there was a case where things people did not want to automatically loop this back. However, I cannot bring the discussion of 3.5 years ago to mind. I will take this as an action item as a reviewer to try to recreate the discussion. Thank you for mentioning this point. It is important to clarify in either case. NB> Sue is right that there were some cases where folks did not want the packet to be automatically sent back for lookup. They wanted an explicit specification on what to do with the packet. I believe the reasoning was there might be L2 processing that needs to be performed after the encap/decap and L2 processing was mainly out of scope of this draft. * Section 6 I would have expected the match type to have some indication about whether it requires an exact match or LPM (e.g. A MAC route uses an exact match but an IPv6 route uses LPM). Has the WG discussed this? The short answer is yes, extensive in early interims, list discussions and in session. Can you provide more depth to your questions. For the early discussions, I may need to query Alia Atlas and Jeff Haas (previous chairs) to get the institutional memory on this topic. (One of the reason I really want to have this document discussed with Alia Atlas as AD0. NB> Quoting from the grammar ::= ( | | ( )) ::= ::= ::= Thus IP addresses have a "prefix length" associated with them indicating a LPM (or exact-match if prefix length is 32). A MAC route is expected to have an exact match. LPM for MAC routes was out of scope. Thanks Nitin From nobody Thu Apr 12 23:19:08 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44718124D68 for ; Thu, 12 Apr 2018 23:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=yahoo.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 DjhOaC3Fq1_B for ; Thu, 12 Apr 2018 23:19:01 -0700 (PDT) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 3B0A8126C22 for ; Thu, 12 Apr 2018 23:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1523600340; bh=lx4HA0arh5/Cj/lJ+jhL2A+gXpSHYzy6fcY0Wfa96mM=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=LcmBwtvdmN3zmimC7nhKJWPbM+0iyQKzccflwhQElXve33FSlqmo8MHxnORSESTOxS7/yqH0qHSgBHk66TDMnQ1lE43bUc/q1fhyAKKnKlAfiWF4j6cmFULFK+L/bvpivTT9hFtUJXn0RdU0BKuaw+ylIh022fzOx2fOOjfvrEcgP15yi1ob+0u0+qRuhzcFoA1zTqhlJFBqJ/c5+LiYQeqZuo+iyT3iHtjahsO+O5u/xP+RyalADecERXHSBwxyELosylxQPgNoMlAolaOHdfs/nE6c/dzK9UE+KEi9AEuK5DJinT2XjqKIOvbtuwFKJ9OmJQ6whLSArB5K2mU0Bw== X-YMail-OSG: FC4SKzwVM1kAtn.sMPqtthNQKOLvAG0lNvnohU.SKICSgwnBmbZ_unhT1awSJPc Iau3hJlrRkj_aburyggpfIj6n_fIlmko4zCZmYPqsgA4lzsLAarZh0A5InyCzDfzrLDOMd7wVH5m n.Rc20xHJsdKAAA6ZyA_sJxOW904mquHWfF6mFZQXsmxrlFNq_6l5xthRZss6QP1wcZ_k0TjR4Qz GCGUNk.iyX93QAwNJc3ieqwJYm_KwFzCs1JoUoXBTD0kbHl..1KlKcZDcI784hLheJIb1zhsewGg wJR2zQ0zZn1FRh0okZA1sNNDSEg9CbuL8PFKYdwDl6H8x3qhsyOsrj3nPY1wpwGNtAlE8poebtgx JpALbdaCuoY0kVjAug4FhED118gJQdnPOqv66vwMmPvlb.1N40BXYc3IkatBzP1pF_47OHiZB8ZL 53ICLF1B6vRo5Fs4.2.R0FPMgd53i3XpKclTEAO96oK8PGTITSRkuExjd6maQqHPn1OCnNUjMaoA jQKat0rG35vxaBg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 13 Apr 2018 06:19:00 +0000 Received: from c-73-158-191-172.hsd1.ca.comcast.net (EHLO [192.168.0.106]) ([73.158.191.172]) by smtp404.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 27951770991dcadfd7c1a7524db2f629; Fri, 13 Apr 2018 06:08:56 +0000 (UTC) User-Agent: Microsoft-MacOutlook/10.9.0.180116 Date: Thu, 12 Apr 2018 23:08:54 -0700 From: Nitin Bahadur To: Alvaro Retana , The IESG CC: , Susan Hares , , Message-ID: <344B4088-7547-4479-8745-99DFBCD3A224@yahoo.com> Thread-Topic: Alvaro Retana's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) References: <152273965001.13971.7531466101349529801.idtracker@ietfa.amsl.com> In-Reply-To: <152273965001.13971.7531466101349529801.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 06:19:02 -0000 Hi Alvaro, Thanks for the review. Please see NB> below (1) Even if just Informative, it would be nice to have a reference to draft-ietf-i2rs-rib-data-model. NB> I'm not sure how referencing works. If I understand correctly, rib-info-model then can't be published until data-model is published...and then there is circular referencing. (2) I think that the use of some Normative Language is not as expected. (2.1) For example, in S2.1 (RIB definition): "There MAY be many routing instances and each routing instance MAY contain RIBs." In both cases "MAY" seems to be a statement of fact, and not a normative statement to indicate that a routing instance can optionally include RIBs. NB> Rewording to " A network device MAY contain routing instances and each routing instance MAY contain RIBs." Note that S2.2 (Routing instance) identifies a rib-list as a mandatory component of a routing instance, and there's no clear indication that the list may be empty. NB> Good point. I'll fix that. (2.2) S2.1: "A routing instance MAY even have two or more RIBs of the same rib family (e.g., IPv6)." This use of "MAY" also seems to be stating a fact. NB> Yes it is a fact. So removed use of "MAY". (2.3) "MAY be optionally", "MAY contain the following optional fields" are redundant phrases as MAY already means optional. NB> Good point. Fixed. Thanks Nitin From nobody Thu Apr 12 23:30:02 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E10212E3AE for ; Thu, 12 Apr 2018 23:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=yahoo.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 e-k3PSFo8o9D for ; Thu, 12 Apr 2018 23:29:42 -0700 (PDT) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 D8BE41270B4 for ; Thu, 12 Apr 2018 23:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1523600960; bh=fLnnRsmNBY/idHkbD7Uo88flFSk3pLGrX3ZSGumvWT0=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=YIO8/aoJocTM2+rC6aDutQkvsRAvR4vFOapUt6bz85qyPDS4snYNtMSwAbmQFgY2cMaQMi8uVgFeKBSQNR/CqtU4h6KNmefz8w9p6WIdx/UbZ74y57iF11maNgQqf1GwI1vVMROvmj3tGPHKbQSa3Foe4V7ISS4VmJqngxBp2Lq71LaQotGHr+4/6s1239CO2fezmIMGs+7svJ5Vgt8N8cmHzKqDb6X3pjuJPMsxJneSI9KG27+zc4YXpDAujzprd89rhcuheqUXUFKCVF6wJlylnsFSqKrIZ4ZkSDg3RP1YCnSk7G6rZDJvrRuxd5/0cXaseGpSymOFisT06cSriA== X-YMail-OSG: PKd5IbsVM1mfqsV2c8B_5ajFO1JWEziD48ZA0m_d7xgQ7sf5TzOSefPuEo9GDYX ZSbtPi3z59bDSloitk_ixqPfbisyRxzM4riHz.Zzs.0epPc9zYdKrv0ZizFdlhGL8dNkj426AOhk 7If20UD185OvQ.729cN69.5cnrncH.vXRyuSmpTeCrddS_ik7Sco9DhbAWvROWoaGGCMNkMj6RVX u5w_Xq5PLjDgjAM21z.qlj5fz_nosZ8hbN7PROjt0b9Na7RITPOe66WdHVQBzXWHA7QqFJiahPR. tUI30lJOf.UKmtJY0_n8u36ofEXf4euYctvpM81TyWAnFefAlY2wcT_xSFxsuiy.d0AKytWtSlzL jK6XhZnGgoMHE9mzpakd3VtBt4ofz2wITWV8xj1W87TikWW2zMBHJ4_zbwiFzyoBqUmw6nRhGIsG L0XM4eSMgTxPubqnGlexgta.gEb_Q4XHXt9xNLiMvOhtyBrItXSYbkF8LKovyfEAY3EcxT3CVhWC tvUwLFSCrPfmKsNR2kr5rFShvu0F0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 13 Apr 2018 06:29:20 +0000 Received: from c-73-158-191-172.hsd1.ca.comcast.net (EHLO [192.168.0.106]) ([73.158.191.172]) by smtp429.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7d39593f121024b674fe3a1dc5b7bdb9; Fri, 13 Apr 2018 06:19:16 +0000 (UTC) User-Agent: Microsoft-MacOutlook/10.9.0.180116 Date: Thu, 12 Apr 2018 23:19:14 -0700 From: Nitin Bahadur To: Susan Hares , 'Benjamin Kaduk' , 'The IESG' CC: , , Message-ID: <89B8E4F5-3C13-44C7-89E7-0E9D998FF8ED@yahoo.com> Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) References: <152289224356.25972.5946145598014687422.idtracker@ietfa.amsl.com> <034101d3cc7f$72e1cd30$58a56790$@ndzh.com> In-Reply-To: <034101d3cc7f$72e1cd30$58a56790$@ndzh.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 06:29:47 -0000 Hi Benjamin/Sue, NB> The reason string is indeed not relevant for the success case. The success case is "Installed is TRUE AND Active is TRUE". For everything else a reason will help. It will help the client to know why something was installed but is not active. As I recall (and my memory may be spotty), the reason was available for both "yes" and "no" in case "yes" it is active, and "no" it is not installed (example - 20 ECMP routes and only 10 get installed). Nitin may have more details on this RFC. Cheerily, Susan Hares -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@mit.edu] Sent: Wednesday, April 4, 2018 9:37 PM To: The IESG Cc: draft-ietf-i2rs-rib-info-model@ietf.org; Susan Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Warren's question (and, IIRC, asked a similar one about the associated data-model document). Just one other minor question: in Section 4 Route programming in the RIB MUST result in a return code that contains the following attributes: o Installed - Yes/No (Indicates whether the route got installed in the FIB) o Active - Yes/No (Indicates whether a route is fully resolved and is a candidate for selection) o Reason - e.g., Not authorized Is the Reason only relevant when one of the other two is "No"? From nobody Fri Apr 13 09:01:06 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A6C12708C; Fri, 13 Apr 2018 09:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 Ojel4YM4AsSi; Fri, 13 Apr 2018 09:01:03 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 18CC9126CC4; Fri, 13 Apr 2018 09:01:03 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.120.167; From: "Susan Hares" To: "'Nitin Bahadur'" , "'Benjamin Kaduk'" , "'The IESG'" Cc: , , References: <152289224356.25972.5946145598014687422.idtracker@ietfa.amsl.com> <034101d3cc7f$72e1cd30$58a56790$@ndzh.com> <89B8E4F5-3C13-44C7-89E7-0E9D998FF8ED@yahoo.com> In-Reply-To: <89B8E4F5-3C13-44C7-89E7-0E9D998FF8ED@yahoo.com> Date: Fri, 13 Apr 2018 12:00:52 -0400 Message-ID: <016101d3d340$99ff9d30$cdfed790$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM8qJ9Kz8N5WEWm3I2uC23bntTqtAKLuaB8AlXw8omhBiKAUA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 16:01:05 -0000 Nitin: Thank you for email. It really helps the process! Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur Sent: Friday, April 13, 2018 2:19 AM To: Susan Hares; 'Benjamin Kaduk'; 'The IESG' Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; draft-ietf-i2rs-rib-info-model@ietf.org Subject: Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Hi Benjamin/Sue, NB> The reason string is indeed not relevant for the success case. The success case is "Installed is TRUE AND Active is TRUE". For everything else a reason will help. It will help the client to know why something was installed but is not active. As I recall (and my memory may be spotty), the reason was available for both "yes" and "no" in case "yes" it is active, and "no" it is not installed (example - 20 ECMP routes and only 10 get installed). Nitin may have more details on this RFC. Cheerily, Susan Hares -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@mit.edu] Sent: Wednesday, April 4, 2018 9:37 PM To: The IESG Cc: draft-ietf-i2rs-rib-info-model@ietf.org; Susan Hares; i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Benjamin Kaduk's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-i2rs-rib-info-model-15: 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-i2rs-rib-info-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Warren's question (and, IIRC, asked a similar one about the associated data-model document). Just one other minor question: in Section 4 Route programming in the RIB MUST result in a return code that contains the following attributes: o Installed - Yes/No (Indicates whether the route got installed in the FIB) o Active - Yes/No (Indicates whether a route is fully resolved and is a candidate for selection) o Reason - e.g., Not authorized Is the Reason only relevant when one of the other two is "No"? _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Apr 13 09:04:19 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9683B1272E1; Fri, 13 Apr 2018 09:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 MbTRO8WE3hFy; Fri, 13 Apr 2018 09:04:16 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C47D41271DF; Fri, 13 Apr 2018 09:04:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.120.167; From: "Susan Hares" To: "'Nitin Bahadur'" , "'Alvaro Retana'" , "'The IESG'" Cc: , , References: <152273965001.13971.7531466101349529801.idtracker@ietfa.amsl.com> <344B4088-7547-4479-8745-99DFBCD3A224@yahoo.com> In-Reply-To: <344B4088-7547-4479-8745-99DFBCD3A224@yahoo.com> Date: Fri, 13 Apr 2018 12:04:09 -0400 Message-ID: <016301d3d341$0f4c4cf0$2de4e6d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHlL8EtsaIHtA0wmpBSZtkX90UkgQJmxtm+o8jrq9A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 16:04:18 -0000 Nitin: On #1) - These drafts will work through the process at the same time. There will be a "MISREF" - but it should be cleared. Originally we were concerned about this fact because we wanted to send the I2RS Info model earlier. However, due to the network management datastore model work in netmod/netconf - this work has been held up. Please put the reference in and spin it as -16.txt. Thanks! Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur Sent: Friday, April 13, 2018 2:09 AM To: Alvaro Retana; The IESG Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; Susan Hares; draft-ietf-i2rs-rib-info-model@ietf.org Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Hi Alvaro, Thanks for the review. Please see NB> below (1) Even if just Informative, it would be nice to have a reference to draft-ietf-i2rs-rib-data-model. NB> I'm not sure how referencing works. If I understand correctly, rib-info-model then can't be published until data-model is published...and then there is circular referencing. (2) I think that the use of some Normative Language is not as expected. (2.1) For example, in S2.1 (RIB definition): "There MAY be many routing instances and each routing instance MAY contain RIBs." In both cases "MAY" seems to be a statement of fact, and not a normative statement to indicate that a routing instance can optionally include RIBs. NB> Rewording to " A network device MAY contain routing instances and each routing instance MAY contain RIBs." Note that S2.2 (Routing instance) identifies a rib-list as a mandatory component of a routing instance, and there's no clear indication that the list may be empty. NB> Good point. I'll fix that. (2.2) S2.1: "A routing instance MAY even have two or more RIBs of the same rib family (e.g., IPv6)." This use of "MAY" also seems to be stating a fact. NB> Yes it is a fact. So removed use of "MAY". (2.3) "MAY be optionally", "MAY contain the following optional fields" are redundant phrases as MAY already means optional. NB> Good point. Fixed. Thanks Nitin _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Apr 13 09:11:55 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84D61272E1; Fri, 13 Apr 2018 09:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 fgQTvCRGbxtj; Fri, 13 Apr 2018 09:11:45 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E9B27127275; Fri, 13 Apr 2018 09:11:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.120.167; From: "Susan Hares" To: "'Nitin Bahadur'" , "'Suresh Krishnan'" , "'The IESG'" Cc: , , References: <152290489812.25948.2495908999143424774.idtracker@ietfa.amsl.com> <045701d3cce7$1c8bec00$55a3c400$@ndzh.com> <1CF12BE1-AE55-43CF-95B4-66BC5B67E38F@yahoo.com> In-Reply-To: <1CF12BE1-AE55-43CF-95B4-66BC5B67E38F@yahoo.com> Date: Fri, 13 Apr 2018 12:11:37 -0400 Message-ID: <017501d3d342$1a19b130$4e4d1390$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGzXOuogYIVg/6+qC65IQQLrrWnfgJG+DIiAfwLyY+kHbChMA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 16:11:47 -0000 Nitin: Thanks for fixing Suresh's comments. I've trimmed the text below to = text tunnel-encap/decap text and LPM text. =20 I will do a deep dive on the tunnel encap/decap on the mail list to see = if I can find any additional comments to help your text. However, I = suspect that what you will naturally write will be the best text.=20 On the LPM, let's see if Suresh has a suggestion on where to add text. = Again, I'm sure you will do a great job writing up the text.=20 Would you remember to send the revised text to Warren and to Ignas. We = could really use their review of the revisions for these two points. = Warren and Ignas have experience with RIBs.=20 Sue Hares=20 -----Original Message----- From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com]=20 Sent: Friday, April 13, 2018 1:52 AM To: Susan Hares; 'Suresh Krishnan'; 'The IESG' Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-rib-info-model@ietf.org Subject: Re: [i2rs] Suresh Krishnan's No Objection on = draft-ietf-i2rs-rib-info-model-15: (with COMMENT) Suresh: =20 Shouldn't the tunnel-encap and tunnel-decap also loop the packet = back into nexthop processing just like the derived nexthops do? =20 Suresh - I need to check the email list archives and get back to you = on this point. My recollection was that there was a case where things = people did not want to automatically loop this back. However, I cannot bring = the discussion of 3.5 years ago to mind. I will take this as an action = item as a reviewer to try to recreate the discussion. Thank you for = mentioning this point. It is important to clarify in either case.=20 =20 NB> Sue is right that there were some cases where folks did not want the = packet to be automatically sent back for lookup. They wanted an explicit = specification on what to do with the packet. I believe the reasoning = was there might be L2 processing that needs to be performed after the = encap/decap and L2 processing was mainly out of scope of this draft. Sue> Could you put this in the draft? It makes my recollection. I will = be doing a deep dive on the I2RS mail list and presentation today to = provide additional test.=20 Suresh>=20 * Section 6 =20 I would have expected the match type to have some indication about = whether it requires an exact match or LPM (e.g. A MAC route uses an exact = match but an IPv6 route uses LPM). Has the WG discussed this? =20 The short answer is yes, extensive in early interims, list = discussions and in session. Can you provide more depth to your questions. For the = early discussions, I may need to query Alia Atlas and Jeff Haas (previous = chairs) to get the institutional memory on this topic. (One of the reason I = really want to have this document discussed with Alia Atlas as AD0.=20 =20 NB> Quoting from the grammar ::=3D ( | = | ( )) ::=3D ::=3D ::=3D Thus IP addresses have a "prefix length" associated with them indicating = a LPM (or exact-match if prefix length is 32). A MAC route is expected = to have an exact match. LPM for MAC routes was out of scope. Sue: This matches my understanding. If Suresh is confused, others will = be. Let's see if Suresh has a suggestion on where to add text. Will = you follow up with Suresh on this point?=20 From nobody Mon Apr 16 07:08:13 2018 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8BC12D95C; Mon, 16 Apr 2018 07:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 ABy2o8PPHVb6; Mon, 16 Apr 2018 07:08:02 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67157127137; Mon, 16 Apr 2018 07:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23252; q=dns/txt; s=iport; t=1523887682; x=1525097282; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ib5rmXAzuhEaQt7dWmVqfCzX0WOo9qsCIUIvP8zfFz8=; b=MZWFtCEWuptZixSml52b89WepDmaJVJpzIcfvceBZTbCOGB8p03lbX5I gofg5h1l2AyIZtwkLl4AWM6RG1MsFvFXz089+Jx6xguPoYKL4p/Z2kgvv D5c1ZtHA/o6FwBh37Jeg0MqQ8s+P1nTsWng1K9fvf23cfrxdj29m0KQT9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXBAACrdRa/xjFo0gZAUIZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBhCMXYyiDZ4hgjX4pdRqSaBSBZwsYAQqEYAKCZDUXAQIBAQE?= =?us-ascii?q?BAQECbBwMhSIBAQEBAwEBIUsLDAQLEQQBAQEgBwMCAicfCQgGAQwGAgEBhQkPi?= =?us-ascii?q?RGcLYIcH4Q4g2WCKgWJWj+BDyOCMzWDEQEBAQEBAYEkBQESAQeDGIJUAocuhTe?= =?us-ascii?q?DfIcDCIVZiFwGgTODXII4hQSJLIFThSCBJR4DM2FYEQgzGggbFTuCQ4JIiEiFS?= =?us-ascii?q?zIwAYwBgjYBAQ?= X-IronPort-AV: E=Sophos; i="5.48,459,1517875200"; d="scan'208,217"; a="86336582" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2018 14:07:57 +0000 Received: from [10.68.209.76] ([10.68.209.76]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w3GE7uKG030782; Mon, 16 Apr 2018 14:07:57 GMT To: Mach Chen , "t.petch" , Alissa Cooper Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-rib-data-model@ietf.org" , IESG , "shares@ndzh.com" , "i2rs-chairs@ietf.org" References: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com> <00d801d3cf2e$92becf20$4001a8c0@gateway.2wire.net> <011801d3d176$90dc9e40$4001a8c0@gateway.2wire.net> From: Benoit Claise Message-ID: Date: Mon, 16 Apr 2018 22:07:55 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C8A337957D9A03F63A58EA62" Content-Language: en-US Archived-At: Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 14:08:06 -0000 This is a multi-part message in MIME format. --------------C8A337957D9A03F63A58EA62 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, On this topic, we tried to have a consistent section for all recently published RFCs. 1.x . Tree Diagrams Tree diagrams used in this document follow the notation defined in [RFC8340 ]. Ex: rfc8343 Regards, Benoit > Hi Tom, > > Thanks for your comments! > > It will be fixed in the upcoming version-11. > > Best regards, > Mach > >> -----Original Message----- >> From: t.petch [mailto:ietfc@btconnect.com] >> Sent: Wednesday, April 11, 2018 5:22 PM >> To: Alissa Cooper ; Mach Chen >> Cc: IESG ; i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; >> i2rs-chairs@ietf.org; shares@ndzh.com >> Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data- >> model-10: (with COMMENT) >> >> Mach >> >> One additional thought on tree diagrams. >> >> This is now RFC8340 >> >> and >> >> YANG guidelines 6087bis section 3.4 says >> >> " If YANG tree diagrams are used, then an informative reference to the >> YANG tree diagrams specification MUST be included in the document. >> " >> whereas you currently have it as a Normative Reference (well, perhaps two >> related thoughts:-( >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Alissa Cooper" >> Sent: Monday, April 09, 2018 8:50 PM >> >>> On Apr 8, 2018, at 9:20 AM, Mach Chen wrote: >>> >>> Hi Tom, >>> >>>> -----Original Message----- >>>> From: t.petch [mailto:ietfc@btconnect.com] >>>> Sent: Sunday, April 08, 2018 7:42 PM >>>> To: Mach Chen ; Alissa Cooper >>>> ; The IESG >>>> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; >> i2rs-chairs@ietf.org; >>>> shares@ndzh.com >>>> Subject: Re: [i2rs] Alissa Cooper's No Objection on >> draft-ietf-i2rs-rib-data- >>>> model-10: (with COMMENT) >>>> >>>> ---- Original Message ----- >>>> From: "Mach Chen" >>>> To: "Alissa Cooper" ; "The IESG" >>>> Cc: ; ; >>>> ; >>>> Sent: Sunday, April 08, 2018 9:23 AM >>>> >>>>> Hi Alissa, >>>>> >>>>> Thanks for your comments! >>>>> >>>>> Please see my responses inline... >>>>> >>>>>> -----Original Message----- >>>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa >> Cooper >>>>>> Sent: Tuesday, April 03, 2018 11:10 PM >>>>>> To: The IESG >>>>>> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; >>>> i2rs-chairs@ietf.org; >>>>>> shares@ndzh.com >>>>>> Subject: [i2rs] Alissa Cooper's No Objection on >>>> draft-ietf-i2rs-rib-data-model-10: >>>>>> (with COMMENT) >>>>>> >>>>>> Alissa Cooper has entered the following ballot position for >>>>>> draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/ >>>>>> >>>>>> >>>>>> >>>>> -------------------------------------------------------------------- >> -- >>>>>> COMMENT: >>>>> -------------------------------------------------------------------- >> -- >>>>>> Sec 1.2: >>>>>> >>>>>> "YANG tree diagrams provide a concise representation of a YANG >>>> module, >>>>>> and SHOULD be included to help readers understand YANG module >>>>>> structure." >>>>>> >>>>>> This document does not seem like an appropriate place to have >>>> normative >>>>>> guidance about this. And if this sentence is removed, I don't see >>>> the point of >>>>>> including Section 1.2 otherwise. This would also imply deleting the >>>> reference to >>>>>> I-D.ietf-netmod-yang-tree-diagrams. >>>>> This results from a YANG doctor review. I saw it also occurs in >> other >>>> published documents. I personally think it's no harm to keep it, how >> do you >>>> think? >>>> >>>> Mach >>>> >>>> I think that this is very odd. >>>> >>>> YANG guidelines rfc6087bis says >>>> " YANG tree diagrams provide a concise representation of a YANG >>>> module, >>>> and SHOULD be included to help readers understand YANG module >>>> structure. Guidelines on tree diagrams can be found in Section 3 >> of >>>> [I-D.ietf-netmod-yang-tree-diagrams]. >>>> " >>>> which I think is the correct guidance in the correct place. >>>> >>>> A quick look at the recently published RFC8343, RFC8344, RFC8345, >>>> RFC8346 contain no text of the kind you suggest so if it occurs in >> other I-D, then >>>> I would regard those other I-D as being in error. >>>> >>>> If I look back at a thread from Ebben for a yang doctor review of an >> earlier >>>> version of this I-D, the text I see proposed is >>>> >>>> " >>>>> A simplified graphical representation of the data model is used in >>>>> this document. The meaning of the symbols in these diagrams is >>>>> defined in [I-D.ietf-netmod-yang-tree-diagrams]. >>>> " >>>> which I think is rather different. >>> Indeed, my fault, I just checked Ebben's suggestion, it's as above >> quoted. >>> To Alissa: >>> If change to following text, is it OK for you? >>> >>> "A simplified graphical representation of the data model is used in >>> this document. The meaning of the symbols in these diagrams is >>> defined in [I-D.ietf-netmod-yang-tree-diagrams].” >> Yes, thanks. >> Alissa >> >>> >>> Best regards, >>> Mach >>>> Tom Petch >>>> (not a YANG doctor) >>>> >>>>>> Sec 2.1: Again here I'm confused about the use of normative >>>> language. Why do >>>>>> you need to specify normative requirements for what this very >>>> document is >>>>>> specifying? Or are these supposed to be requirements on >>>> implementations? >>>>> OK, how about this: >>>>> >>>>> "...a RIB data model needs to specify a way for an external entity >> to >>>> learn about the functional capabilities of a network device." And >>>>> " The RIB data model needs a way to expose the nexthop chaining >>>> capability supported by a given network device." >>>>>> Sec 2.5: s/causes/caused/ >>>>> Done >>>>> >>>>> The above updates will be reelected in version-11. >>>>> >>>>> Thanks, >>>>> Mach > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --------------C8A337957D9A03F63A58EA62 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,

On this topic, we tried to have a consistent section for all recently published RFCs. 
1.x.  Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [RFC8340].
Ex: rfc8343

Regards, Benoit
Hi Tom,

Thanks for your comments!

It will be fixed in the upcoming version-11.

Best regards,
Mach


-----Original Message-----
From: t.petch [mailto:ietfc@btconnect.com]
Sent: Wednesday, April 11, 2018 5:22 PM
To: Alissa Cooper <alissa@cooperw.in>; Mach Chen <mach.chen@huawei.com>
Cc: IESG <iesg@ietf.org>; i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;
i2rs-chairs@ietf.org; shares@ndzh.com
Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-
model-10: (with COMMENT)

Mach

One additional thought on tree diagrams.

This is now RFC8340

and

YANG guidelines 6087bis section 3.4 says

"   If YANG tree diagrams are used, then an informative reference to the
   YANG tree diagrams specification MUST be included in the document.
"
whereas you currently have it as a Normative Reference (well, perhaps two
related thoughts:-(

Tom Petch

----- Original Message -----
From: "Alissa Cooper" <alissa@cooperw.in>
Sent: Monday, April 09, 2018 8:50 PM


On Apr 8, 2018, at 9:20 AM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Tom,


-----Original Message-----
From: t.petch [mailto:ietfc@btconnect.com]
Sent: Sunday, April 08, 2018 7:42 PM
To: Mach Chen <mach.chen@huawei.com>; Alissa Cooper
<alissa@cooperw.in>; The IESG <iesg@ietf.org>
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;

i2rs-chairs@ietf.org;

shares@ndzh.com
Subject: Re: [i2rs] Alissa Cooper's No Objection on

draft-ietf-i2rs-rib-data-

model-10: (with COMMENT)

---- Original Message -----
From: "Mach Chen" <mach.chen@huawei.com>
To: "Alissa Cooper" <alissa@cooperw.in>; "The IESG" <iesg@ietf.org>
Cc: <i2rs@ietf.org>; <draft-ietf-i2rs-rib-data-model@ietf.org>;
<i2rs-chairs@ietf.org>; <shares@ndzh.com>
Sent: Sunday, April 08, 2018 9:23 AM


Hi Alissa,

Thanks for your comments!

Please see my responses inline...


-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa

Cooper

Sent: Tuesday, April 03, 2018 11:10 PM
To: The IESG <iesg@ietf.org>
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;

i2rs-chairs@ietf.org;

shares@ndzh.com
Subject: [i2rs] Alissa Cooper's No Objection on

draft-ietf-i2rs-rib-data-model-10:

(with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-i2rs-rib-data-model-10: 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-i2rs-rib-data-model/




--------------------------------------------------------------------

--

COMMENT:

--------------------------------------------------------------------

--

Sec 1.2:

"YANG tree diagrams provide a concise representation of a YANG

module,

  and SHOULD be included to help readers understand YANG module
  structure."

This document does not seem like an appropriate place to have

normative

guidance about this. And if this sentence is removed, I don't see

the point of

including Section 1.2 otherwise. This would also imply deleting the

reference to

I-D.ietf-netmod-yang-tree-diagrams.

This results from a YANG doctor review.  I saw it also occurs in

other

published documents. I personally think it's no harm to keep it, how

do you

think?

Mach

I think that this is very odd.

YANG guidelines rfc6087bis says
"   YANG tree diagrams provide a concise representation of a YANG
module,
  and SHOULD be included to help readers understand YANG module
  structure.  Guidelines on tree diagrams can be found in Section 3

of

  [I-D.ietf-netmod-yang-tree-diagrams].
"
which I think is the correct guidance in the correct place.

A quick look at the recently published RFC8343, RFC8344, RFC8345,
RFC8346 contain no text of the kind you suggest so if it occurs in

other I-D, then

I would regard those other I-D as being in error.

If I look back at a thread from Ebben for a yang doctor review of an

earlier

version of this I-D, the text I see proposed is

"

  A simplified graphical representation of the data model is used in
  this document.  The meaning of the symbols in these diagrams is
  defined in [I-D.ietf-netmod-yang-tree-diagrams].

"
which I think is rather different.

Indeed, my fault, I just checked Ebben's suggestion, it's as above

quoted.

To Alissa:
If change to following text, is it OK for you?

"A simplified graphical representation of the data model is used in
this document.  The meaning of the symbols in these diagrams is
defined in [I-D.ietf-netmod-yang-tree-diagrams].”

Yes, thanks.
Alissa



Best regards,
Mach

Tom Petch
(not a YANG doctor)


Sec 2.1: Again here I'm confused about the use of normative

language. Why do

you need to specify normative requirements for what this very

document is

specifying? Or are these supposed to be requirements on

implementations?

OK, how about this:

"...a RIB data model needs to specify a way for an external entity

to

learn about the functional capabilities of a network device." And

" The RIB data model needs a way to expose the nexthop chaining

capability supported by a given network device."


              

                
Sec 2.5: s/causes/caused/


              

              
Done

The above updates will be reelected in version-11.

Thanks,
Mach


              

                

              

            

          

          

        

      

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


    

    

  


--------------C8A337957D9A03F63A58EA62--


From nobody Mon Apr 16 10:27:28 2018
Return-Path: 
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2790612D7E5; Mon, 16 Apr 2018 10:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 TtUdhII5ZB0R; Mon, 16 Apr 2018 10:27:24 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 5DEA9120721; Mon, 16 Apr 2018 10:27:24 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id CFF1821C6225C; Mon, 16 Apr 2018 18:27:20 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 16 Apr 2018 18:27:22 +0100
Received: from SJCEML521-MBB.china.huawei.com ([169.254.6.91]) by SJCEML701-CHM.china.huawei.com ([169.254.3.93]) with mapi id 14.03.0382.000; Mon, 16 Apr 2018 10:27:15 -0700
From: Michael McBride 
To: "i2rs-chairs@ietf.org" , "draft-ietf-i2rs-rib-data-model@ietf.org" 
CC: "rtg-dir@ietf.org" , "i2rs@ietf.org" 
Thread-Topic: Rtgdir early review of draft-ietf-i2rs-rib-data-model-10
Thread-Index: AdPVoijcOdSSVfroSK+tyaCMp+qlSw==
Date: Mon, 16 Apr 2018 17:27:14 +0000
Message-ID: <8CCB28152EA2E14A96BBEDC15823481A1CAE8BCB@SJCEML521-MBB.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.246.40]
Content-Type: multipart/alternative; boundary="_000_8CCB28152EA2E14A96BBEDC15823481A1CAE8BCBSJCEML521MBBchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [i2rs] Rtgdir early review of draft-ietf-i2rs-rib-data-model-10
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2018 17:27:26 -0000

--_000_8CCB28152EA2E14A96BBEDC15823481A1CAE8BCBSJCEML521MBBchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBoYXZlIGJlZW4gc2VsZWN0ZWQgdG8gZG8gYSByb3V0aW5nIGRpcmVjdG9yYXRlIOKAnGVhcmx5
4oCdIHJldmlldyBvZiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwuDQoNCkRvY3VtZW50
OiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMTANClJldmlld2VyOiBNaWtlIE1jQnJp
ZGUNClJldmlldyBEYXRlOiAxMy0wNC0yMDE4DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBU
cmFjaw0KDQpDb21tZW50czoNCg0KSSBvbmx5IGZvdW5kIGEgZmV3IG5pdHMuIExvb2tzIGxpa2Ug
aXTigJlzIGJlZW4gdGhyb3VnaCBzZXZlcmFsIHJldmlld3MgYW5kIG90aGVyd2lzZSBsb29rcyBn
b29kIHRvIGdvIHRvIG1lLiBUaGUgbml0cyB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIGNvbnNpZGVy
ZWQ6DQoNCjIuMi4gUm91dGluZyBJbnN0YW5jZSBhbmQgUmliDQoNCi0tLVNob3VsZCAiUmliIiBi
ZSAiUklCIj8NCg0KMi40LiBOZXh0aG9wDQpBIG5leHRob3AgcmVwcmVzZW50cyBhbiBvYmplY3Qg
cmVzdWx0aW5nIGZyb20gYSByb3V0ZSBsb29rdXAuIEFzIGlsbHVzdHJhdGVkIGluIFNlY3Rpb24g
Mi40IG9mIFtJLUQuaWV0Zi1pMnJzLXJpYi1pbmZvLW1vZGVsXSwgdG8gc3VwcG9ydCB2YXJpb3Vz
IHVzZSBjYXNlcyAoZS5nLiwgbG9hZCBiYWxhbmNlLCBwcm90ZWN0aW9uLCBtdWx0aWNhc3QNCg0K
LS0tU2hvdWxkICJsb2FkIGJhbGFuY2UiIGJlICJsb2FkIGJhbGFuY2luZyI/DQoNCjEuMS4gRGVm
aW5pdGlvbnMgYW5kIEFjcm9ueW1zDQoNCi0tLVNob3VsZCBSUEMgYmUgYWRkZWQ/IEhvdyBhYm91
dCBGSUI/IFJpZ2h0IG5vdyBvbmx5IFJJQiBpcyBkZWZpbmVkLg0KDQoyLjUuIFJQQyBPcGVyYXRp
b25zDQpyb3V0ZS1hZGQ6IEFkZCBhIHJvdXRlIG9yIGEgc2V0IG9mIHJvdXRlcyB0byBhIFJJQi4g
QSBSSUIgbmFtZSwgdGhlIHJvdXRlIHByZWZpeChlcyksIHJvdXRlIGF0dHJpYnV0ZXMsIHJvdXRl
IHZlbmRvciBhdHRyaWJ1dGVzLCBuZXh0aG9wIGFuZCB3aGV0aGVyIHJldHVybiBmYWlsdXJlIGRl
dGFpbCBhcmUgcGFzc2VkIGFzIHRoZSBpbnB1dA0KDQotLS1Ib3cgYWJvdXQgImRldGFpbCIgYmUg
ImRldGFpbHMiLg0KDQpwYXJhbWV0ZXJzLiBCZWZvcmUgY2FsbGluZyB0aGUgcm91dGUtYWRkIHJw
YywgaXQgaXMgcmVxdWlyZWQgdG8gY2FsbCB0aGUgbmgtYWRkIHJwYyB0byBjcmVhdGUgYW5kL29y
IHJldHVybiB0aGUgbmV4dGhvcCBpZGVudGlmaWVyIGJ1dCBkdXJpbmcgc2l0dWF0aW9ucyB3aGVu
IHRoZSBuZXh0aG9wIGFscmVhZHkgZXhpc3RzIGFuZCB0aGUgbmV4dGhvcC1pZCBpcyBrbm93biwg
dGhpcyBhY3Rpb24gaXMgbm90IGV4cGVjdGVkLi4gVGhlIG91dHB1dCBpcyBhDQoNCi0tLVRoaXMg
c2VudGVuY2UgaXMgYXdrd2FyZCB0byBtZS4gSSB3b3VsZCByZWNvbW1lbmQgY2hhbmdpbmcgaXQg
dG8gdHdvIHNlbnRlbmNlcyBhcyBsb25nIGFzIGl0IGRvZXNu4oCZdCBhbHRlciB0aGUgaW50ZW50
Og0KDQoiQmVmb3JlIGNhbGxpbmcgdGhlIHJvdXRlLWFkZCBycGMsIGl0IGlzIHJlcXVpcmVkIHRv
IGNhbGwgdGhlIG5oLWFkZCBycGMgdG8gY3JlYXRlIGFuZC9vciByZXR1cm4gdGhlIG5leHRob3Ag
aWRlbnRpZmllci4gSG93ZXZlciwgaW4gc2l0dWF0aW9ucyB3aGVuIHRoZSBuZXh0aG9wIGFscmVh
ZHkgZXhpc3RzLCBhbmQgdGhlIG5leHRob3AtaWQgaXMga25vd24sIHRoaXMgY2FsbCBhY3Rpb24g
aXMgbm90IGV4cGVjdGVkLiINCg0KU291bmQgcmVhc29uYWJsZT8NCg0KbWlrZQ0K

--_000_8CCB28152EA2E14A96BBEDC15823481A1CAE8BCBSJCEML521MBBchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj
OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl
ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i
ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv
aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZl
IGJlZW4gc2VsZWN0ZWQgdG8gZG8gYSByb3V0aW5nIGRpcmVjdG9yYXRlIOKAnGVhcmx54oCdIHJl
dmlldyBvZiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwuPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkRvY3VtZW50OiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMTA8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJldmlld2VyOiBNaWtlIE1jQnJpZGU8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJldmlldyBEYXRlOiAxMy0wNC0yMDE4
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbnRlbmRlZCBTdGF0dXM6IFN0
YW5kYXJkcyBUcmFjazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db21tZW50czo8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSBvbmx5IGZvdW5kIGEgZmV3IG5pdHMuIExvb2tzIGxpa2UgaXTigJlz
IGJlZW4gdGhyb3VnaCBzZXZlcmFsIHJldmlld3MgYW5kIG90aGVyd2lzZSBsb29rcyBnb29kIHRv
IGdvIHRvIG1lLiBUaGUgbml0cyB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIGNvbnNpZGVyZWQ6PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuMi4gUm91dGluZyBJbnN0YW5jZSBhbmQgUmliPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPi0tLVNob3VsZCAmcXVvdDtSaWImcXVvdDsgYmUgJnF1b3Q7UklC
JnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLjQuIE5leHRob3A8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbmV4dGhvcCByZXByZXNlbnRzIGFuIG9iamVjdCBy
ZXN1bHRpbmcgZnJvbSBhIHJvdXRlIGxvb2t1cC4gQXMgaWxsdXN0cmF0ZWQgaW4gU2VjdGlvbiAy
LjQgb2YgW0ktRC5pZXRmLWkycnMtcmliLWluZm8tbW9kZWxdLCB0byBzdXBwb3J0IHZhcmlvdXMg
dXNlIGNhc2VzIChlLmcuLCBsb2FkIGJhbGFuY2UsIHByb3RlY3Rpb24sIG11bHRpY2FzdDxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS1TaG91bGQgJnF1b3Q7bG9hZCBiYWxhbmNlJnF1b3Q7IGJl
ICZxdW90O2xvYWQgYmFsYW5jaW5nJnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLjEu
IERlZmluaXRpb25zIGFuZCBBY3JvbnltczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS1TaG91
bGQgUlBDIGJlIGFkZGVkPyBIb3cgYWJvdXQgRklCPyBSaWdodCBub3cgb25seSBSSUIgaXMgZGVm
aW5lZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi41LiBSUEMgT3BlcmF0aW9uczxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cm91dGUtYWRkOiBBZGQgYSByb3V0ZSBvciBh
IHNldCBvZiByb3V0ZXMgdG8gYSBSSUIuIEEgUklCIG5hbWUsIHRoZSByb3V0ZSBwcmVmaXgoZXMp
LCByb3V0ZSBhdHRyaWJ1dGVzLCByb3V0ZSB2ZW5kb3IgYXR0cmlidXRlcywgbmV4dGhvcCBhbmQg
d2hldGhlciByZXR1cm4gZmFpbHVyZSBkZXRhaWwgYXJlIHBhc3NlZCBhcyB0aGUgaW5wdXQ8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tSG93IGFib3V0ICZxdW90O2RldGFpbCZxdW90OyBiZSAm
cXVvdDtkZXRhaWxzJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wYXJhbWV0ZXJzLiBC
ZWZvcmUgY2FsbGluZyB0aGUgcm91dGUtYWRkIHJwYywgaXQgaXMgcmVxdWlyZWQgdG8gY2FsbCB0
aGUgbmgtYWRkIHJwYyB0byBjcmVhdGUgYW5kL29yIHJldHVybiB0aGUgbmV4dGhvcCBpZGVudGlm
aWVyIGJ1dCBkdXJpbmcgc2l0dWF0aW9ucyB3aGVuIHRoZSBuZXh0aG9wIGFscmVhZHkgZXhpc3Rz
IGFuZCB0aGUgbmV4dGhvcC1pZCBpcyBrbm93biwgdGhpcyBhY3Rpb24gaXMgbm90IGV4cGVjdGVk
Li4NCiBUaGUgb3V0cHV0IGlzIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tVGhpcyBzZW50
ZW5jZSBpcyBhd2t3YXJkIHRvIG1lLiBJIHdvdWxkIHJlY29tbWVuZCBjaGFuZ2luZyBpdCB0byB0
d28gc2VudGVuY2VzIGFzIGxvbmcgYXMgaXQgZG9lc27igJl0IGFsdGVyIHRoZSBpbnRlbnQ6PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O0JlZm9yZSBjYWxsaW5nIHRoZSByb3V0ZS1hZGQg
cnBjLCBpdCBpcyByZXF1aXJlZCB0byBjYWxsIHRoZSBuaC1hZGQgcnBjIHRvIGNyZWF0ZSBhbmQv
b3IgcmV0dXJuIHRoZSBuZXh0aG9wIGlkZW50aWZpZXIuIEhvd2V2ZXIsIGluIHNpdHVhdGlvbnMg
d2hlbiB0aGUgbmV4dGhvcCBhbHJlYWR5IGV4aXN0cywgYW5kIHRoZSBuZXh0aG9wLWlkIGlzIGtu
b3duLCB0aGlzIGNhbGwgYWN0aW9uIGlzIG5vdCBleHBlY3RlZC4mcXVvdDs8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+U291bmQgcmVhc29uYWJsZT8gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1p
a2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_8CCB28152EA2E14A96BBEDC15823481A1CAE8BCBSJCEML521MBBchi_--


From nobody Wed Apr 18 01:31:40 2018
Return-Path: 
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332AF126D74; Wed, 18 Apr 2018 01:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level: 
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 mucGyr3gk52g; Wed, 18 Apr 2018 01:31:34 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 7AC67124C27; Wed, 18 Apr 2018 01:31:33 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id F2C853205AED8; Wed, 18 Apr 2018 09:31:29 +0100 (IST)
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 18 Apr 2018 09:31:30 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.73]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0361.001; Wed, 18 Apr 2018 16:31:25 +0800
From: Mach Chen 
To: Benoit Claise , t.petch , "Alissa Cooper" 
CC: "i2rs@ietf.org" , "draft-ietf-i2rs-rib-data-model@ietf.org" , IESG , "shares@ndzh.com" , "i2rs-chairs@ietf.org" 
Thread-Topic: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)
Thread-Index: AQHTy13moi2oBFWZPEShrejzOgw/4qP2htDAgAA/0nCAABhS0IABfEQAgAL7abCAAVtD8IAGSeWAgANMI0A=
Date: Wed, 18 Apr 2018 08:31:25 +0000
Message-ID: 
References: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com>  <00d801d3cf2e$92becf20$4001a8c0@gateway.2wire.net>   <011801d3d176$90dc9e40$4001a8c0@gateway.2wire.net>  
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.194.201]
Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2923AF85Ddggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2018 08:31:37 -0000

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2923AF85Ddggeml510mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQmVub2l0LA0KDQpPSywgd2lsbCB1c2UgeW91IHN1Z2dlc3RlZCB0ZXh0IGJlbG93Lg0KDQpU
aGFua3MsDQpNYWNoDQoNCkZyb206IEJlbm9pdCBDbGFpc2UgW21haWx0bzpiY2xhaXNlQGNpc2Nv
LmNvbV0NClNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTggMTA6MDggUE0NClRvOiBNYWNoIENo
ZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPjsgdC5wZXRjaCA8aWV0ZmNAYnRjb25uZWN0LmNvbT47
IEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPg0KQ2M6IGkycnNAaWV0Zi5vcmc7IGRy
YWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbEBpZXRmLm9yZzsgSUVTRyA8aWVzZ0BpZXRmLm9y
Zz47IHNoYXJlc0BuZHpoLmNvbTsgaTJycy1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb
aTJyc10gQWxpc3NhIENvb3BlcidzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWkycnMtcmli
LWRhdGEtbW9kZWwtMTA6ICh3aXRoIENPTU1FTlQpDQoNCkRlYXIgYWxsLA0KDQpPbiB0aGlzIHRv
cGljLCB3ZSB0cmllZCB0byBoYXZlIGEgY29uc2lzdGVudCBzZWN0aW9uIGZvciBhbGwgcmVjZW50
bHkgcHVibGlzaGVkIFJGQ3MuDQoxLng8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgz
NDMjc2VjdGlvbi0xLjM+LiAgVHJlZSBEaWFncmFtcw0KDQoNCg0KICAgVHJlZSBkaWFncmFtcyB1
c2VkIGluIHRoaXMgZG9jdW1lbnQgZm9sbG93IHRoZSBub3RhdGlvbiBkZWZpbmVkIGluDQoNCiAg
IFtSRkM4MzQwPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MzQwPl0uDQpFeDogcmZj
ODM0Mw0KDQpSZWdhcmRzLCBCZW5vaXQNCg0KDQpIaSBUb20sDQoNCg0KDQpUaGFua3MgZm9yIHlv
dXIgY29tbWVudHMhDQoNCg0KDQpJdCB3aWxsIGJlIGZpeGVkIGluIHRoZSB1cGNvbWluZyB2ZXJz
aW9uLTExLg0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpNYWNoDQoNCg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiB0LnBldGNoIFttYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNv
bV0NCg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMSwgMjAxOCA1OjIyIFBNDQoNClRvOiBBbGlz
c2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj48bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPjsg
TWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbT48bWFpbHRvOm1hY2guY2hlbkBodWF3ZWku
Y29tPg0KDQpDYzogSUVTRyA8aWVzZ0BpZXRmLm9yZz48bWFpbHRvOmllc2dAaWV0Zi5vcmc+OyBp
MnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1pMnJzLXJpYi1k
YXRhLW1vZGVsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWxA
aWV0Zi5vcmc+Ow0KDQppMnJzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86aTJycy1jaGFpcnNAaWV0
Zi5vcmc+OyBzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4NCg0KU3ViamVj
dDogUmU6IFtpMnJzXSBBbGlzc2EgQ29vcGVyJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYt
aTJycy1yaWItZGF0YS0NCg0KbW9kZWwtMTA6ICh3aXRoIENPTU1FTlQpDQoNCg0KDQpNYWNoDQoN
Cg0KDQpPbmUgYWRkaXRpb25hbCB0aG91Z2h0IG9uIHRyZWUgZGlhZ3JhbXMuDQoNCg0KDQpUaGlz
IGlzIG5vdyBSRkM4MzQwDQoNCg0KDQphbmQNCg0KDQoNCllBTkcgZ3VpZGVsaW5lcyA2MDg3Ymlz
IHNlY3Rpb24gMy40IHNheXMNCg0KDQoNCiIgICBJZiBZQU5HIHRyZWUgZGlhZ3JhbXMgYXJlIHVz
ZWQsIHRoZW4gYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRoZQ0KDQogICBZQU5HIHRyZWUg
ZGlhZ3JhbXMgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSBkb2N1bWVudC4N
Cg0KIg0KDQp3aGVyZWFzIHlvdSBjdXJyZW50bHkgaGF2ZSBpdCBhcyBhIE5vcm1hdGl2ZSBSZWZl
cmVuY2UgKHdlbGwsIHBlcmhhcHMgdHdvDQoNCnJlbGF0ZWQgdGhvdWdodHM6LSgNCg0KDQoNClRv
bSBQZXRjaA0KDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KDQpGcm9tOiAiQWxp
c3NhIENvb3BlciIgPGFsaXNzYUBjb29wZXJ3LmluPjxtYWlsdG86YWxpc3NhQGNvb3BlcncuaW4+
DQoNClNlbnQ6IE1vbmRheSwgQXByaWwgMDksIDIwMTggODo1MCBQTQ0KDQoNCg0KT24gQXByIDgs
IDIwMTgsIGF0IDk6MjAgQU0sIE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+PG1haWx0
bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQoNCg0KDQpIaSBUb20sDQoNCg0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiB0LnBldGNoIFttYWlsdG86aWV0ZmNAYnRj
b25uZWN0LmNvbV0NCg0KU2VudDogU3VuZGF5LCBBcHJpbCAwOCwgMjAxOCA3OjQyIFBNDQoNClRv
OiBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPjxtYWlsdG86bWFjaC5jaGVuQGh1YXdl
aS5jb20+OyBBbGlzc2EgQ29vcGVyDQoNCjxhbGlzc2FAY29vcGVydy5pbj48bWFpbHRvOmFsaXNz
YUBjb29wZXJ3LmluPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+PG1haWx0bzppZXNnQGlldGYu
b3JnPg0KDQpDYzogaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz47IGRyYWZ0LWll
dGYtaTJycy1yaWItZGF0YS1tb2RlbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pMnJzLXJp
Yi1kYXRhLW1vZGVsQGlldGYub3JnPjsNCg0KaTJycy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmky
cnMtY2hhaXJzQGlldGYub3JnPjsNCg0Kc2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6
aC5jb20+DQoNClN1YmplY3Q6IFJlOiBbaTJyc10gQWxpc3NhIENvb3BlcidzIE5vIE9iamVjdGlv
biBvbg0KDQpkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtDQoNCm1vZGVsLTEwOiAod2l0aCBDT01N
RU5UKQ0KDQoNCg0KLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQoNCkZyb206ICJNYWNoIENo
ZW4iIDxtYWNoLmNoZW5AaHVhd2VpLmNvbT48bWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tPg0K
DQpUbzogIkFsaXNzYSBDb29wZXIiIDxhbGlzc2FAY29vcGVydy5pbj48bWFpbHRvOmFsaXNzYUBj
b29wZXJ3LmluPjsgIlRoZSBJRVNHIiA8aWVzZ0BpZXRmLm9yZz48bWFpbHRvOmllc2dAaWV0Zi5v
cmc+DQoNCkNjOiA8aTJyc0BpZXRmLm9yZz48bWFpbHRvOmkycnNAaWV0Zi5vcmc+OyA8ZHJhZnQt
aWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsQGlldGYub3JnPjxtYWlsdG86ZHJhZnQtaWV0Zi1pMnJz
LXJpYi1kYXRhLW1vZGVsQGlldGYub3JnPjsNCg0KPGkycnMtY2hhaXJzQGlldGYub3JnPjxtYWls
dG86aTJycy1jaGFpcnNAaWV0Zi5vcmc+OyA8c2hhcmVzQG5kemguY29tPjxtYWlsdG86c2hhcmVz
QG5kemguY29tPg0KDQpTZW50OiBTdW5kYXksIEFwcmlsIDA4LCAyMDE4IDk6MjMgQU0NCg0KDQoN
CkhpIEFsaXNzYSwNCg0KDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyENCg0KDQoNClBsZWFz
ZSBzZWUgbXkgcmVzcG9uc2VzIGlubGluZS4uLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCg0KRnJvbTogaTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIEFsaXNzYQ0KDQpDb29wZXINCg0KU2VudDogVHVlc2RheSwgQXByaWwgMDMsIDIwMTgg
MTE6MTAgUE0NCg0KVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjxtYWlsdG86aWVzZ0BpZXRm
Lm9yZz4NCg0KQ2M6IGkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+OyBkcmFmdC1p
ZXRmLWkycnMtcmliLWRhdGEtbW9kZWxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaTJycy1y
aWItZGF0YS1tb2RlbEBpZXRmLm9yZz47DQoNCmkycnMtY2hhaXJzQGlldGYub3JnPG1haWx0bzpp
MnJzLWNoYWlyc0BpZXRmLm9yZz47DQoNCnNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5k
emguY29tPg0KDQpTdWJqZWN0OiBbaTJyc10gQWxpc3NhIENvb3BlcidzIE5vIE9iamVjdGlvbiBv
bg0KDQpkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMTA6DQoNCih3aXRoIENPTU1FTlQp
DQoNCg0KDQpBbGlzc2EgQ29vcGVyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv
c2l0aW9uIGZvcg0KDQpkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwtMTA6IE5vIE9iamVj
dGlvbg0KDQoNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5l
IGludGFjdCBhbmQgcmVwbHkgdG8NCg0KYWxsIGVtYWlsDQoNCmFkZHJlc3NlcyBpbmNsdWRlZCBp
biB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQoNCmludHJvZHVj
dG9yeQ0KDQpwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNCg0KDQoNClBsZWFzZSByZWZlciB0bw0K
DQpodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0
bWwNCg0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5U
IHBvc2l0aW9ucy4NCg0KDQoNCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFs
bG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC8NCg0KDQoNCg0KDQoN
Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0tDQoNCkNPTU1FTlQ6DQoNCg0KDQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
DQotLQ0KDQoNCg0KU2VjIDEuMjoNCg0KDQoNCiJZQU5HIHRyZWUgZGlhZ3JhbXMgcHJvdmlkZSBh
IGNvbmNpc2UgcmVwcmVzZW50YXRpb24gb2YgYSBZQU5HDQoNCm1vZHVsZSwNCg0KICBhbmQgU0hP
VUxEIGJlIGluY2x1ZGVkIHRvIGhlbHAgcmVhZGVycyB1bmRlcnN0YW5kIFlBTkcgbW9kdWxlDQoN
CiAgc3RydWN0dXJlLiINCg0KDQoNClRoaXMgZG9jdW1lbnQgZG9lcyBub3Qgc2VlbSBsaWtlIGFu
IGFwcHJvcHJpYXRlIHBsYWNlIHRvIGhhdmUNCg0Kbm9ybWF0aXZlDQoNCmd1aWRhbmNlIGFib3V0
IHRoaXMuIEFuZCBpZiB0aGlzIHNlbnRlbmNlIGlzIHJlbW92ZWQsIEkgZG9uJ3Qgc2VlDQoNCnRo
ZSBwb2ludCBvZg0KDQppbmNsdWRpbmcgU2VjdGlvbiAxLjIgb3RoZXJ3aXNlLiBUaGlzIHdvdWxk
IGFsc28gaW1wbHkgZGVsZXRpbmcgdGhlDQoNCnJlZmVyZW5jZSB0bw0KDQpJLUQuaWV0Zi1uZXRt
b2QteWFuZy10cmVlLWRpYWdyYW1zLg0KDQoNCg0KVGhpcyByZXN1bHRzIGZyb20gYSBZQU5HIGRv
Y3RvciByZXZpZXcuICBJIHNhdyBpdCBhbHNvIG9jY3VycyBpbg0KDQpvdGhlcg0KDQpwdWJsaXNo
ZWQgZG9jdW1lbnRzLiBJIHBlcnNvbmFsbHkgdGhpbmsgaXQncyBubyBoYXJtIHRvIGtlZXAgaXQs
IGhvdw0KDQpkbyB5b3UNCg0KdGhpbms/DQoNCg0KDQpNYWNoDQoNCg0KDQpJIHRoaW5rIHRoYXQg
dGhpcyBpcyB2ZXJ5IG9kZC4NCg0KDQoNCllBTkcgZ3VpZGVsaW5lcyByZmM2MDg3YmlzIHNheXMN
Cg0KIiAgIFlBTkcgdHJlZSBkaWFncmFtcyBwcm92aWRlIGEgY29uY2lzZSByZXByZXNlbnRhdGlv
biBvZiBhIFlBTkcNCg0KbW9kdWxlLA0KDQogIGFuZCBTSE9VTEQgYmUgaW5jbHVkZWQgdG8gaGVs
cCByZWFkZXJzIHVuZGVyc3RhbmQgWUFORyBtb2R1bGUNCg0KICBzdHJ1Y3R1cmUuICBHdWlkZWxp
bmVzIG9uIHRyZWUgZGlhZ3JhbXMgY2FuIGJlIGZvdW5kIGluIFNlY3Rpb24gMw0KDQpvZg0KDQog
IFtJLUQuaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zXS4NCg0KIg0KDQp3aGljaCBJIHRo
aW5rIGlzIHRoZSBjb3JyZWN0IGd1aWRhbmNlIGluIHRoZSBjb3JyZWN0IHBsYWNlLg0KDQoNCg0K
QSBxdWljayBsb29rIGF0IHRoZSByZWNlbnRseSBwdWJsaXNoZWQgUkZDODM0MywgUkZDODM0NCwg
UkZDODM0NSwNCg0KUkZDODM0NiBjb250YWluIG5vIHRleHQgb2YgdGhlIGtpbmQgeW91IHN1Z2dl
c3Qgc28gaWYgaXQgb2NjdXJzIGluDQoNCm90aGVyIEktRCwgdGhlbg0KDQpJIHdvdWxkIHJlZ2Fy
ZCB0aG9zZSBvdGhlciBJLUQgYXMgYmVpbmcgaW4gZXJyb3IuDQoNCg0KDQpJZiBJIGxvb2sgYmFj
ayBhdCBhIHRocmVhZCBmcm9tIEViYmVuIGZvciBhIHlhbmcgZG9jdG9yIHJldmlldyBvZiBhbg0K
DQplYXJsaWVyDQoNCnZlcnNpb24gb2YgdGhpcyBJLUQsIHRoZSB0ZXh0IEkgc2VlIHByb3Bvc2Vk
IGlzDQoNCg0KDQoiDQoNCiAgQSBzaW1wbGlmaWVkIGdyYXBoaWNhbCByZXByZXNlbnRhdGlvbiBv
ZiB0aGUgZGF0YSBtb2RlbCBpcyB1c2VkIGluDQoNCiAgdGhpcyBkb2N1bWVudC4gIFRoZSBtZWFu
aW5nIG9mIHRoZSBzeW1ib2xzIGluIHRoZXNlIGRpYWdyYW1zIGlzDQoNCiAgZGVmaW5lZCBpbiBb
SS1ELmlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtc10uDQoNCiINCg0Kd2hpY2ggSSB0aGlu
ayBpcyByYXRoZXIgZGlmZmVyZW50Lg0KDQoNCg0KSW5kZWVkLCBteSBmYXVsdCwgSSBqdXN0IGNo
ZWNrZWQgRWJiZW4ncyBzdWdnZXN0aW9uLCBpdCdzIGFzIGFib3ZlDQoNCnF1b3RlZC4NCg0KDQoN
ClRvIEFsaXNzYToNCg0KSWYgY2hhbmdlIHRvIGZvbGxvd2luZyB0ZXh0LCBpcyBpdCBPSyBmb3Ig
eW91Pw0KDQoNCg0KIkEgc2ltcGxpZmllZCBncmFwaGljYWwgcmVwcmVzZW50YXRpb24gb2YgdGhl
IGRhdGEgbW9kZWwgaXMgdXNlZCBpbg0KDQp0aGlzIGRvY3VtZW50LiAgVGhlIG1lYW5pbmcgb2Yg
dGhlIHN5bWJvbHMgaW4gdGhlc2UgZGlhZ3JhbXMgaXMNCg0KZGVmaW5lZCBpbiBbSS1ELmlldGYt
bmV0bW9kLXlhbmctdHJlZS1kaWFncmFtc10u4oCdDQoNCg0KDQpZZXMsIHRoYW5rcy4NCg0KQWxp
c3NhDQoNCg0KDQoNCg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KTWFjaA0KDQoNCg0KVG9tIFBldGNo
DQoNCihub3QgYSBZQU5HIGRvY3RvcikNCg0KDQoNCg0KDQpTZWMgMi4xOiBBZ2FpbiBoZXJlIEkn
bSBjb25mdXNlZCBhYm91dCB0aGUgdXNlIG9mIG5vcm1hdGl2ZQ0KDQpsYW5ndWFnZS4gV2h5IGRv
DQoNCnlvdSBuZWVkIHRvIHNwZWNpZnkgbm9ybWF0aXZlIHJlcXVpcmVtZW50cyBmb3Igd2hhdCB0
aGlzIHZlcnkNCg0KZG9jdW1lbnQgaXMNCg0Kc3BlY2lmeWluZz8gT3IgYXJlIHRoZXNlIHN1cHBv
c2VkIHRvIGJlIHJlcXVpcmVtZW50cyBvbg0KDQppbXBsZW1lbnRhdGlvbnM/DQoNCg0KDQpPSywg
aG93IGFib3V0IHRoaXM6DQoNCg0KDQoiLi4uYSBSSUIgZGF0YSBtb2RlbCBuZWVkcyB0byBzcGVj
aWZ5IGEgd2F5IGZvciBhbiBleHRlcm5hbCBlbnRpdHkNCg0KdG8NCg0KbGVhcm4gYWJvdXQgdGhl
IGZ1bmN0aW9uYWwgY2FwYWJpbGl0aWVzIG9mIGEgbmV0d29yayBkZXZpY2UuIiBBbmQNCg0KDQoN
CiIgVGhlIFJJQiBkYXRhIG1vZGVsIG5lZWRzIGEgd2F5IHRvIGV4cG9zZSB0aGUgbmV4dGhvcCBj
aGFpbmluZw0KDQpjYXBhYmlsaXR5IHN1cHBvcnRlZCBieSBhIGdpdmVuIG5ldHdvcmsgZGV2aWNl
LiINCg0KDQoNCg0KDQpTZWMgMi41OiBzL2NhdXNlcy9jYXVzZWQvDQoNCg0KDQpEb25lDQoNCg0K
DQpUaGUgYWJvdmUgdXBkYXRlcyB3aWxsIGJlIHJlZWxlY3RlZCBpbiB2ZXJzaW9uLTExLg0KDQoN
Cg0KVGhhbmtzLA0KDQpNYWNoDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQoNCmkycnMgbWFpbGluZyBsaXN0DQoNCmkycnNAaWV0
Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vaTJycw0KDQo=

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2923AF85Ddggeml510mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl
ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ
e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0K
aDMNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Iuagh+mimCAzIENo
YXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox
My41cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6Ymxh
Y2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg
c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s
b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7
DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRN
TENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0K
CWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uaDMNCgl7bXNvLXN0
eWxlLW5hbWU6aDM7fQ0Kc3Bhbi4zQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5qCH6aKYIDMgQ2hh
ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Iuagh+mimCAzIjsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0RDc4
O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw
LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy
Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh
Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb
ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i
ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91
dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n
PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj
dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5
N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBCZW5v
aXQsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm
b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD
YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T0ssIHdpbGwgdXNlIHlvdSBz
dWdnZXN0ZWQgdGV4dCBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli
cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9
IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U
aGFua3MsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+TWFjaA0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl
PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGZvbnQgc2l6
ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
d2luZG93dGV4dDtmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250
IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOndpbmRvd3RleHQiPg0KIEJlbm9pdCBDbGFpc2UgW21haWx0bzpiY2xhaXNlQGNpc2NvLmNv
bV0gPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwv
Yj4gTW9uZGF5LCBBcHJpbCAxNiwgMjAxOCAxMDowOCBQTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJm
b250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBNYWNoIENoZW4gJmx0O21hY2guY2hlbkBo
dWF3ZWkuY29tJmd0OzsgdC5wZXRjaCAmbHQ7aWV0ZmNAYnRjb25uZWN0LmNvbSZndDs7IEFsaXNz
YSBDb29wZXIgJmx0O2FsaXNzYUBjb29wZXJ3LmluJmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJm
b250LXdlaWdodDpib2xkIj5DYzo8L3NwYW4+PC9iPiBpMnJzQGlldGYub3JnOyBkcmFmdC1pZXRm
LWkycnMtcmliLWRhdGEtbW9kZWxAaWV0Zi5vcmc7IElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7
OyBzaGFyZXNAbmR6aC5jb207IGkycnMtY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+PHNwYW4gc3R5
bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IFtpMnJzXSBBbGlz
c2EgQ29vcGVyJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2Rl
bC0xMDogKHdpdGggQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSJibGFj
ayIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IlRpbWVzIE5ldyBSb21h
biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkRlYXIgYWxsLDxicj4NCjxicj4NCk9u
IHRoaXMgdG9waWMsIHdlIHRyaWVkIHRvIGhhdmUgYSBjb25zaXN0ZW50IHNlY3Rpb24gZm9yIGFs
bCByZWNlbnRseSBwdWJsaXNoZWQgUkZDcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+
DQo8aDM+PGEgbmFtZT0ic2VjdGlvbi0xLjMiPjwvYT48YSBocmVmPSJodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvcmZjODM0MyNzZWN0aW9uLTEuMyI+PGZvbnQgZmFjZT0iQ291cmllciBOZXci
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MS54PC9z
cGFuPjwvZm9udD48L2E+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LiZuYnNwOyBUcmVlIERpYWdyYW1zPG86
cD48L286cD48L3NwYW4+PC9mb250PjwvaDM+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJi
bGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIi
IGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0Ij4mbmJzcDsmbmJzcDsgVHJlZSBkaWFncmFtcyB1c2VkIGluIHRoaXMgZG9jdW1lbnQg
Zm9sbG93IHRoZSBub3RhdGlvbiBkZWZpbmVkIGluPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFs8YSBocmVmPSJo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODM0MCIgdGl0bGU9IiZxdW90O1lBTkcgVHJl
ZSBEaWFncmFtcyZxdW90OyI+UkZDODM0MDwvYT5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9
ImJsYWNrIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0Ij5FeDogcmZjODM0Mzxicj4NCjxicj4NClJlZ2FyZHMsIEJlbm9pdDxicj4NCjxicj4NCjxv
OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9
ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi
PkhpIFRvbSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9
IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxm
b250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0Ij5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMhPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0i
YmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+
SXQgd2lsbCBiZSBmaXhlZCBpbiB0aGUgdXBjb21pbmcgdmVyc2lvbi0xMS48bzpwPjwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFj
ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJi
bGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5C
ZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBz
aXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdCI+TWFjaDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+
PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3By
ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNv
bG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0Ij5Gcm9tOiB0LnBldGNoIFs8YSBocmVmPSJtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbSI+
bWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb208L2E+XTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5l
dyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlNlbnQ6IFdlZG5lc2RheSwgQXByaWwg
MTEsIDIwMTggNToyMiBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZv
bnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQiPlRvOiBBbGlzc2EgQ29vcGVyIDxhIGhyZWY9Im1haWx0bzphbGlz
c2FAY29vcGVydy5pbiI+Jmx0O2FsaXNzYUBjb29wZXJ3LmluJmd0OzwvYT47IE1hY2ggQ2hlbiA8
YSBocmVmPSJtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb20iPiZsdDttYWNoLmNoZW5AaHVhd2Vp
LmNvbSZndDs8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBz
aXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdCI+Q2M6IElFU0cgPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPiZs
dDtpZXNnQGlldGYub3JnJmd0OzwvYT47IDxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5p
MnJzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaTJycy1yaWItZGF0
YS1tb2RlbEBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsQGlldGYub3Jn
PC9hPjs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIi
IGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0Ij48YSBocmVmPSJtYWlsdG86aTJycy1jaGFpcnNAaWV0Zi5vcmciPmkycnMtY2hhaXJz
QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5k
emguY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6
ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQiPlN1YmplY3Q6IFJlOiBbaTJyc10gQWxpc3NhIENvb3BlcidzIE5vIE9iamVj
dGlvbiBvbiBkcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtPG86cD48L286cD48L3NwYW4+PC9mb250
PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIg
TmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+bW9kZWwtMTA6ICh3aXRoIENPTU1F
TlQpPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBj
b2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBz
aXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdCI+TWFjaDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+
PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3By
ZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uZSBhZGRpdGlvbmFsIHRob3VnaHQgb24g
dHJlZSBkaWFncmFtcy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250
IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8
cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGlzIGlzIG5vdyBSRkM4MzQwPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0i
YmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+
YW5kPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBj
b2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBz
aXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdCI+WUFORyBndWlkZWxpbmVzIDYwODdiaXMgc2VjdGlvbiAzLjQgc2F5czxv
OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9
ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0i
MiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQiPiZxdW90OyZuYnNwOyZuYnNwOyBJZiBZQU5HIHRyZWUgZGlhZ3JhbXMgYXJlIHVz
ZWQsIHRoZW4gYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJD
b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBZ
QU5HIHRyZWUgZGlhZ3JhbXMgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSBk
b2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9
IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxm
b250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0Ij53aGVyZWFzIHlvdSBjdXJyZW50bHkgaGF2ZSBpdCBhcyBhIE5v
cm1hdGl2ZSBSZWZlcmVuY2UgKHdlbGwsIHBlcmhhcHMgdHdvPG86cD48L286cD48L3NwYW4+PC9m
b250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+cmVsYXRlZCB0aG91Z2h0czot
KDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29s
b3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6
ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQiPlRvbSBQZXRjaDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxw
cmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5l
dyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug
LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIi
IGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0Ij5Gcm9tOiAmcXVvdDtBbGlzc2EgQ29vcGVyJnF1b3Q7IDxhIGhyZWY9Im1haWx0bzph
bGlzc2FAY29vcGVydy5pbiI+Jmx0O2FsaXNzYUBjb29wZXJ3LmluJmd0OzwvYT48bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIg
ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5TZW50OiBN
b25kYXksIEFwcmlsIDA5LCAyMDE4IDg6NTAgUE08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
cmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXci
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L2ZvbnQ+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJD
b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uIEFwciA4LCAyMDE4
LCBhdCA5OjIwIEFNLCBNYWNoIENoZW4gPGEgaHJlZj0ibWFpbHRvOm1hY2guY2hlbkBodWF3ZWku
Y29tIj4mbHQ7bWFjaC5jaGVuQGh1YXdlaS5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFj
ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJi
bGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5I
aSBUb20sPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIy
IiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxm
b250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+
PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBm
YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkZyb206IHQu
cGV0Y2ggWzxhIGhyZWY9Im1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tIj5tYWlsdG86aWV0ZmNA
YnRjb25uZWN0LmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48
Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdCI+U2VudDogU3VuZGF5LCBBcHJpbCAwOCwgMjAxOCA3OjQyIFBN
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xv
cj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dCI+VG86IE1hY2ggQ2hlbiA8YSBocmVmPSJtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb20iPiZs
dDttYWNoLmNoZW5AaHVhd2VpLmNvbSZndDs8L2E+OyBBbGlzc2EgQ29vcGVyPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEgaHJlZj0i
bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluIj4mbHQ7YWxpc3NhQGNvb3BlcncuaW4mZ3Q7PC9hPjsg
VGhlIElFU0cgPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPiZsdDtpZXNnQGlldGYub3Jn
Jmd0OzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9
IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij5DYzogPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5v
cmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsQGll
dGYub3JnIj5kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWxAaWV0Zi5vcmc8L2E+OzxvOnA+
PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N
CjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxhIGhyZWY9Im1haWx0bzppMnJzLWNoYWlyc0Bp
ZXRmLm9yZyI+aTJycy1jaGFpcnNAaWV0Zi5vcmc8L2E+OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291
cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YSBocmVmPSJtYWlsdG86
c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9m
b250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+U3ViamVjdDogUmU6IFtpMnJz
XSBBbGlzc2EgQ29vcGVyJ3MgTm8gT2JqZWN0aW9uIG9uPG86cD48L286cD48L3NwYW4+PC9mb250
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48Zm9udCBzaXplPSIy
IiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdCI+ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291
cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5tb2RlbC0xMDogKHdpdGgg
Q09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9
IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxm
b250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0Ij4tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIg
ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Gcm9tOiAm
cXVvdDtNYWNoIENoZW4mcXVvdDsgPGEgaHJlZj0ibWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29t
Ij4mbHQ7bWFjaC5jaGVuQGh1YXdlaS5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVy
IE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRvOiAmcXVvdDtBbGlzc2EgQ29v
cGVyJnF1b3Q7IDxhIGhyZWY9Im1haWx0bzphbGlzc2FAY29vcGVydy5pbiI+Jmx0O2FsaXNzYUBj
b29wZXJ3LmluJmd0OzwvYT47ICZxdW90O1RoZSBJRVNHJnF1b3Q7IDxhIGhyZWY9Im1haWx0bzpp
ZXNnQGlldGYub3JnIj4mbHQ7aWVzZ0BpZXRmLm9yZyZndDs8L2E+PG86cD48L286cD48L3NwYW4+
PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNv
dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Q2M6IDxhIGhyZWY9Im1h
aWx0bzppMnJzQGlldGYub3JnIj4mbHQ7aTJyc0BpZXRmLm9yZyZndDs8L2E+OyA8YSBocmVmPSJt
YWlsdG86ZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsQGlldGYub3JnIj4mbHQ7ZHJhZnQt
aWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsQGlldGYub3JnJmd0OzwvYT47PG86cD48L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9
IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEgaHJlZj0ibWFp
bHRvOmkycnMtY2hhaXJzQGlldGYub3JnIj4mbHQ7aTJycy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PC9h
PjsgPGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+Jmx0O3NoYXJlc0BuZHpoLmNvbSZn
dDs8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIy
IiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdCI+U2VudDogU3VuZGF5LCBBcHJpbCAwOCwgMjAxOCA5OjIzIEFNPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9y
PSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij5IaSBBbGlzc2EsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBz
aXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHBy
ZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzITxvOnA+PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNr
IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29s
b3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQiPlBsZWFzZSBzZWUgbXkgcmVzcG9uc2VzIGlubGluZS4uLjxvOnA+PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3Vy
aWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvZm9udD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2si
IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJl
Pjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Gcm9tOiBpMnJzIFs8YSBocmVmPSJtYWlsdG86aTJycy1i
b3VuY2VzQGlldGYub3JnIj5tYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo
YWxmIE9mIEFsaXNzYTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PGZv
bnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQiPkNvb3BlcjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIg
TmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+U2VudDogVHVlc2RheSwgQXByaWwg
MDMsIDIwMTggMTE6MTAgUE08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxm
b250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0Ij5UbzogVGhlIElFU0cgPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0
Zi5vcmciPiZsdDtpZXNnQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBO
ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5DYzogPGEgaHJlZj0ibWFpbHRvOmky
cnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0
Zi1pMnJzLXJpYi1kYXRhLW1vZGVsQGlldGYub3JnIj5kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEt
bW9kZWxAaWV0Zi5vcmc8L2E+OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjwvYmxv
Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNr
IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxhIGhy
ZWY9Im1haWx0bzppMnJzLWNoYWlyc0BpZXRmLm9yZyI+aTJycy1jaGFpcnNAaWV0Zi5vcmc8L2E+
OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxmb250IHNpemU9IjIi
IGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0Ij48YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208
L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBj
b2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdCI+U3ViamVjdDogW2kycnNdIEFsaXNzYSBDb29wZXIncyBObyBPYmplY3Rpb24gb248bzpw
PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+
DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9k
ZWwtMTA6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PGZvbnQgc2l6
ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQiPih3aXRoIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJl
Pg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m
b250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QWxpc3NhIENvb3BlciBoYXMg
ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8bzpwPjwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0i
Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5kcmFmdC1pZXRmLWky
cnMtcmliLWRhdGEtbW9kZWwtMTA6IE5vIE9iamVjdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVy
IE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNl
PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPldoZW4gcmVzcG9u
ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvPG86
cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl
Pg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+YWxsIGVtYWlsPG86cD48L286cD48L3NwYW4+
PC9mb250PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNl
PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmFkZHJlc3NlcyBp
bmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPG86
cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl
Pg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aW50cm9kdWN0b3J5PG86cD48L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBm
YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPnBhcmFncmFw
aCwgaG93ZXZlci4pPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBz
aXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHBy
ZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+UGxlYXNlIHJlZmVyIHRvPG86cD48L286
cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHBy
ZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz
Zy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9p
ZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L2E+PG86cD48L286cD48L3NwYW4+
PC9mb250PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNl
PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmZvciBtb3JlIGlu
Zm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPG86cD48
L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxh
Y2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBj
b2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBz
aXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdCI+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np
dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4N
CjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC8iPmh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC88L2E+
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xv
cj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXpl
PSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48
Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9
IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxh
Y2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJi
bGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4t
LTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48Zm9udCBzaXpl
PSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+Q09NTUVOVDo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Js
b2NrcXVvdGU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmll
ciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFj
ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx
dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBm
YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi0tPG86cD48
L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxmb250IHNpemU9IjIiIGNv
bG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNp
emU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0Ij5TZWMgMS4yOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxw
cmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5l
dyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZxdW90O1lBTkcgdHJlZSBkaWFncmFt
cyBwcm92aWRlIGEgY29uY2lzZSByZXByZXNlbnRhdGlvbiBvZiBhIFlBTkc8bzpwPjwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxm
b250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0Ij5tb2R1bGUsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJl
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5l
dyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyBhbmQgU0hPVUxEIGJlIGlu
Y2x1ZGVkIHRvIGhlbHAgcmVhZGVycyB1bmRlcnN0YW5kIFlBTkcgbW9kdWxlPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7IHN0
cnVjdHVyZS4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250
IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8
cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGlzIGRvY3VtZW50IGRvZXMgbm90IHNlZW0gbGlr
ZSBhbiBhcHByb3ByaWF0ZSBwbGFjZSB0byBoYXZlPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48Zm9udCBzaXplPSIyIiBj
b2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdCI+bm9ybWF0aXZlPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+
PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmd1aWRhbmNlIGFib3V0IHRoaXMuIEFuZCBpZiB0aGlzIHNl
bnRlbmNlIGlzIHJlbW92ZWQsIEkgZG9uJ3Qgc2VlPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48Zm9udCBzaXplPSIyIiBj
b2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdCI+dGhlIHBvaW50IG9mPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
cmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmluY2x1ZGluZyBTZWN0aW9uIDEuMiBvdGhlcndpc2Uu
IFRoaXMgd291bGQgYWxzbyBpbXBseSBkZWxldGluZyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv
bnQ+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxmb250IHNpemU9
IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij5yZWZlcmVuY2UgdG88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SS1ELmlldGYtbmV0bW9kLXlhbmctdHJlZS1k
aWFncmFtcy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8
cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBO
ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGlzIHJlc3VsdHMgZnJvbSBhIFlB
TkcgZG9jdG9yIHJldmlldy4mbmJzcDsgSSBzYXcgaXQgYWxzbyBvY2N1cnMgaW48bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js
b2NrcXVvdGU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmll
ciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5vdGhlcjxvOnA+PC9vOnA+PC9z
cGFuPjwvZm9udD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIg
ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5wdWJsaXNo
ZWQgZG9jdW1lbnRzLiBJIHBlcnNvbmFsbHkgdGhpbmsgaXQncyBubyBoYXJtIHRvIGtlZXAgaXQs
IGhvdzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv
Y2txdW90ZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVy
IE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmRvIHlvdTxvOnA+PC9vOnA+PC9z
cGFuPjwvZm9udD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIg
ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij50aGluaz88
bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9y
PSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9
IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij5NYWNoPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9u
dCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0K
PHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SSB0aGluayB0aGF0IHRoaXMgaXMgdmVyeSBvZGQu
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xv
cj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXpl
PSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+WUFORyBndWlkZWxpbmVzIHJmYzYwODdiaXMgc2F5czxvOnA+PC9vOnA+PC9z
cGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNl
PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZxdW90OyZuYnNw
OyZuYnNwOyBZQU5HIHRyZWUgZGlhZ3JhbXMgcHJvdmlkZSBhIGNvbmNpc2UgcmVwcmVzZW50YXRp
b24gb2YgYSBZQU5HPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBz
aXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdCI+bW9kdWxlLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxw
cmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyBhbmQgU0hPVUxEIGJlIGluY2x1ZGVkIHRv
IGhlbHAgcmVhZGVycyB1bmRlcnN0YW5kIFlBTkcgbW9kdWxlPG86cD48L286cD48L3NwYW4+PC9m
b250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7IHN0cnVjdHVyZS4m
bmJzcDsgR3VpZGVsaW5lcyBvbiB0cmVlIGRpYWdyYW1zIGNhbiBiZSBmb3VuZCBpbiBTZWN0aW9u
IDM8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr
cXVvdGU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBO
ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5vZjxvOnA+PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0i
Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsgW0ktRC5p
ZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXNdLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5l
dyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZxdW90OzxvOnA+PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJD
b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPndoaWNoIEkgdGhpbmsg
aXMgdGhlIGNvcnJlY3QgZ3VpZGFuY2UgaW4gdGhlIGNvcnJlY3QgcGxhY2UuPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0i
YmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+
QSBxdWljayBsb29rIGF0IHRoZSByZWNlbnRseSBwdWJsaXNoZWQgUkZDODM0MywgUkZDODM0NCwg
UkZDODM0NSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9
IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij5SRkM4MzQ2IGNvbnRhaW4gbm8gdGV4dCBvZiB0aGUga2luZCB5b3Ugc3VnZ2Vz
dCBzbyBpZiBpdCBvY2N1cnMgaW48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Js
b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFj
ayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5vdGhl
ciBJLUQsIHRoZW48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48Zm9u
dCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdCI+SSB3b3VsZCByZWdhcmQgdGhvc2Ugb3RoZXIgSS1EIGFzIGJlaW5n
IGluIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6
ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+
PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQiPklmIEkgbG9vayBiYWNrIGF0IGEgdGhyZWFkIGZyb20gRWJi
ZW4gZm9yIGEgeWFuZyBkb2N0b3IgcmV2aWV3IG9mIGFuPG86cD48L286cD48L3NwYW4+PC9mb250
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48Zm9udCBzaXplPSIy
IiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdCI+ZWFybGllcjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl
Pjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0Ij52ZXJzaW9uIG9mIHRoaXMgSS1ELCB0aGUgdGV4dCBJIHNl
ZSBwcm9wb3NlZCBpczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQg
c2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxw
cmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIg
TmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7IEEgc2ltcGxpZmllZCBn
cmFwaGljYWwgcmVwcmVzZW50YXRpb24gb2YgdGhlIGRhdGEgbW9kZWwgaXMgdXNlZCBpbjxvOnA+
PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJs
YWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZu
YnNwOyB0aGlzIGRvY3VtZW50LiZuYnNwOyBUaGUgbWVhbmluZyBvZiB0aGUgc3ltYm9scyBpbiB0
aGVzZSBkaWFncmFtcyBpczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZv
bnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyBkZWZpbmVkIGluIFtJLUQuaWV0Zi1uZXRtb2QteWFu
Zy10cmVlLWRpYWdyYW1zXS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Jsb2Nr
cXVvdGU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBO
ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0i
Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij53aGljaCBJIHRoaW5r
IGlzIHJhdGhlciBkaWZmZXJlbnQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPC9i
bG9ja3F1b3RlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SW5kZWVkLCBt
eSBmYXVsdCwgSSBqdXN0IGNoZWNrZWQgRWJiZW4ncyBzdWdnZXN0aW9uLCBpdCdzIGFzIGFib3Zl
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48Zm9u
dCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdCI+cXVvdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m
b250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VG8gQWxpc3NhOjxvOnA+PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNr
IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPklmIGNo
YW5nZSB0byBmb2xsb3dpbmcgdGV4dCwgaXMgaXQgT0sgZm9yIHlvdT88bzpwPjwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0i
Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFj
ayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mcXVv
dDtBIHNpbXBsaWZpZWQgZ3JhcGhpY2FsIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBkYXRhIG1vZGVs
IGlzIHVzZWQgaW48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNp
emU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0Ij50aGlzIGRvY3VtZW50LiZuYnNwOyBUaGUgbWVhbmluZyBvZiB0aGUgc3lt
Ym9scyBpbiB0aGVzZSBkaWFncmFtcyBpczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4N
CjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmRlZmluZWQgaW4gW0ktRC5pZXRmLW5ldG1vZC15
YW5nLXRyZWUtZGlhZ3JhbXNdLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3Vy
aWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBm
YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlllcywgdGhh
bmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIg
Y29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQiPkFsaXNzYTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQg
c2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250
PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIg
TmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9
IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QmVzdCByZWdhcmRz
LDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29s
b3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQiPk1hY2g8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PGZvbnQgc2l6
ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+
PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRvbSBQZXRjaDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5l
dyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPihub3QgYSBZQU5HIGRvY3Rvcik8bzpw
PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJi
bGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48Zm9udCBzaXpl
PSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48
Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdCI+U2VjIDIuMTogQWdhaW4gaGVyZSBJJ20gY29uZnVzZWQgYWJv
dXQgdGhlIHVzZSBvZiBub3JtYXRpdmU8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJi
bGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5s
YW5ndWFnZS4gV2h5IGRvPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+
PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQiPnlvdSBuZWVkIHRvIHNwZWNpZnkgbm9ybWF0aXZlIHJlcXVp
cmVtZW50cyBmb3Igd2hhdCB0aGlzIHZlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9y
PSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij5kb2N1bWVudCBpczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxm
b250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0Ij5zcGVjaWZ5aW5nPyBPciBhcmUgdGhlc2Ugc3VwcG9zZWQgdG8g
YmUgcmVxdWlyZW1lbnRzIG9uPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPC9ibG9j
a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2si
IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aW1wbGVt
ZW50YXRpb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48Zm9udCBz
aXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHBy
ZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+T0ssIGhvdyBhYm91dCB0aGlzOjxvOnA+PC9vOnA+PC9z
cGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNl
PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJs
YWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZx
dW90Oy4uLmEgUklCIGRhdGEgbW9kZWwgbmVlZHMgdG8gc3BlY2lmeSBhIHdheSBmb3IgYW4gZXh0
ZXJuYWwgZW50aXR5PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xv
cj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dCI+dG88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48Zm9udCBzaXpl
PSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+bGVhcm4gYWJvdXQgdGhlIGZ1bmN0aW9uYWwgY2FwYWJpbGl0aWVzIG9mIGEg
bmV0d29yayBkZXZpY2UuJnF1b3Q7IEFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m
b250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JnF1b3Q7IFRoZSBSSUIgZGF0
YSBtb2RlbCBuZWVkcyBhIHdheSB0byBleHBvc2UgdGhlIG5leHRob3AgY2hhaW5pbmc8bzpwPjwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxmb250IHNpemU9
IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij5jYXBhYmlsaXR5IHN1cHBvcnRlZCBieSBhIGdpdmVuIG5ldHdvcmsgZGV2aWNl
LiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48Zm9udCBzaXpl
PSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl
Pjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
cmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXci
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5TZWMgMi41OiBzL2NhdXNlcy9jYXVzZWQv
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48Zm9u
dCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0K
PHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+RG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5l
dyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJD
b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoZSBhYm92ZSB1cGRh
dGVzIHdpbGwgYmUgcmVlbGVjdGVkIGluIHZlcnNpb24tMTEuPG86cD48L286cD48L3NwYW4+PC9m
b250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhhbmtzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9
ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi
Pk1hY2g8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PGZvbnQgc2l6ZT0i
MiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjwvYmxvY2tx
dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIg
Y29sb3I9ImJsYWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNl
PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCjxwcmU+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJs
YWNrIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZT48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aTJycyBtYWls
aW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9
IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij48YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwv
YT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlPjxmb250IHNpemU9IjIiIGNv
bG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJyczwvYT48bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2923AF85Ddggeml510mbxchi_--


From nobody Wed Apr 18 02:16:05 2018
Return-Path: 
X-Original-To: i2rs@ietf.org
Delivered-To: i2rs@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6499612D874; Wed, 18 Apr 2018 02:16:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: i2rs@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152404296035.31922.14877842482237709633@ietfa.amsl.com>
Date: Wed, 18 Apr 2018 02:16:00 -0700
Archived-At: 
Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-dc-fabric-network-topology-09.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2018 09:16:00 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to the Routing System WG of the IETF.

        Title           : A YANG Data Model for Fabric Topology in Data Center Networks
        Authors         : Yan Zhuang
                          Danian Shi
                          Rong Gu
                          Hariharan Ananthakrishnan
	Filename        : draft-ietf-i2rs-yang-dc-fabric-network-topology-09.txt
	Pages           : 31
	Date            : 2018-04-18

Abstract:
   This document defines a YANG data model for fabric topology in Data
   Center Networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2rs-yang-dc-fabric-network-topology-09
https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-yang-dc-fabric-network-topology-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-dc-fabric-network-topology-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 Wed Apr 18 02:20:53 2018
Return-Path: 
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B2F1241F8; Wed, 18 Apr 2018 02:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zosBJyZLsmo6; Wed, 18 Apr 2018 02:20:47 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 AAC4E12D86C; Wed, 18 Apr 2018 02:20:47 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9931248819797; Wed, 18 Apr 2018 10:20:44 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 18 Apr 2018 10:20:45 +0100
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Wed, 18 Apr 2018 17:20:42 +0800
From: "Zhuangyan (Yan)" 
To: Alexey Melnikov , The IESG 
CC: "draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org" , Susan Hares , "i2rs-chairs@ietf.org" , "shares@ndzh.com" , "i2rs@ietf.org" 
Thread-Topic: Alexey Melnikov's No Objection on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT)
Thread-Index: AQHTy1+6Kw5LVHLRV02xzsbNzxtLd6QGVc7g
Date: Wed, 18 Apr 2018 09:20:41 +0000
Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785A96BEA10@nkgeml513-mbs.china.huawei.com>
References: <152276900356.22779.183636309853823201.idtracker@ietfa.amsl.com>
In-Reply-To: <152276900356.22779.183636309853823201.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.135.170.230]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [i2rs] Alexey Melnikov's No Objection on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2018 09:20:50 -0000

SGkgQWxleGV5LA0KDQpUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50LiBJdCBoYXMgYmVlbiBmaXhl
ZCBpbiB2ZXJzaW9uLTA5Lg0KDQpCZXN0IFJlZ2FyZHMsDQoNCllhbg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWxleGV5IE1lbG5pa292IFttYWlsdG86YWFtZWxuaWtvdkBm
YXN0bWFpbC5mbV0gDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAwMywgMjAxOCAxMToyMyBQTQ0KVG86
IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZh
YnJpYy1uZXR3b3JrLXRvcG9sb2d5QGlldGYub3JnOyBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemgu
Y29tPjsgaTJycy1jaGFpcnNAaWV0Zi5vcmc7IHNoYXJlc0BuZHpoLmNvbTsgaTJyc0BpZXRmLm9y
Zw0KU3ViamVjdDogQWxleGV5IE1lbG5pa292J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYt
aTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5LTA4OiAod2l0aCBDT01NRU5UKQ0K
DQpBbGV4ZXkgTWVsbmlrb3YgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRp
b24gZm9yDQpkcmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29yay10b3BvbG9neS0w
ODogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl
Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQg
aW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3Rv
cnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBp
bmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoN
ClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg
Zm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt
aTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5Lw0KDQoNCg0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KTml0Og0KDQoxLiAgSW50cm9kdWN0aW9uDQoN
CiAgIFRoZXNlIGZhYnJpY3MgbWF5IGJlIGhldGVyb2dlbmVvdXMgZHVlIHRvIGltcGxlbWVudGF0
aW9uIG9mIGRpZmZlcmVudA0KICAgdGVjaG5vbG9naWVzIHdoZW4gYSBEQyBuZXR3b3JrIGlzIHVw
Z3JhZGVkIG9yIG5ldyB0ZWNobmlxdWVzIGFuZA0KICAgZmVhdHVyZXMgYXJlIGVucm9sbGVkLg0K
DQplbnJvbGxlZCAtLT4gcm9sbGVkIG91dD8NCg0KDQo=


From nobody Wed Apr 18 02:22:24 2018
Return-Path: 
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9E81241F8; Wed, 18 Apr 2018 02:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qyY_QM79HCvb; Wed, 18 Apr 2018 02:22:16 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 34A4C12D86C; Wed, 18 Apr 2018 02:22:16 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1B3E0A3A8373A; Wed, 18 Apr 2018 10:22:13 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 18 Apr 2018 10:21:28 +0100
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Wed, 18 Apr 2018 17:21:18 +0800
From: "Zhuangyan (Yan)" 
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG 
CC: "draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org" , Susan Hares , "i2rs-chairs@ietf.org" , "shares@ndzh.com" , "i2rs@ietf.org" 
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?B?LWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29yay10b3BvbG9neS0wODogKHdp?= =?utf-8?Q?th_COMMENT)?=
Thread-Index: AQHTzD61hBQD6GPsH0GDSTtg0j9R+6QGU6LQ
Date: Wed, 18 Apr 2018 09:21:17 +0000
Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785A96BEA1C@nkgeml513-mbs.china.huawei.com>
References: <152286477322.23998.1237380071004726529.idtracker@ietfa.amsl.com>
In-Reply-To: <152286477322.23998.1237380071004726529.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.135.170.230]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [i2rs]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-i2rs-yang-dc-fabric-network-topology-08=3A_=28with_COMMENT?= =?utf-8?q?=29?=
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2018 09:22:18 -0000

SGkgTWlyamEsDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuIFdlJ3ZlIHVwZGF0ZWQgaXQgaW4g
dmVyc2lvbi0wOS4NCg0KQmVzdCBSZWdhcmRzLA0KDQpZYW4gKG9uIGJlaGFsZiBvZiBjby1hdXRo
b3JzKQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWlyamEgS8O8aGxld2lu
ZCBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdIA0KU2VudDogVGh1cnNkYXksIEFwcmlsIDA1
LCAyMDE4IDI6MDAgQU0NClRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1p
ZXRmLWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29yay10b3BvbG9neUBpZXRmLm9yZzsgU3VzYW4g
SGFyZXMgPHNoYXJlc0BuZHpoLmNvbT47IGkycnMtY2hhaXJzQGlldGYub3JnOyBzaGFyZXNAbmR6
aC5jb207IGkycnNAaWV0Zi5vcmcNClN1YmplY3Q6IE1pcmphIEvDvGhsZXdpbmQncyBObyBPYmpl
Y3Rpb24gb24gZHJhZnQtaWV0Zi1pMnJzLXlhbmctZGMtZmFicmljLW5ldHdvcmstdG9wb2xvZ3kt
MDg6ICh3aXRoIENPTU1FTlQpDQoNCk1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZv
bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJy
aWMtbmV0d29yay10b3BvbG9neS0wODogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywg
cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFp
bCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0
byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2Ug
cmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0
ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENP
TU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxs
b3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5
Lw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KUGxlYXNl
IHVzZSBSRkMgODE3NCBib2lsZXJwbGF0ZSENCg0KDQo=


From nobody Wed Apr 18 02:23:31 2018
Return-Path: 
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860D11250B8; Wed, 18 Apr 2018 02:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qID7gUQ_Z4b6; Wed, 18 Apr 2018 02:23:24 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 E60661241F8; Wed, 18 Apr 2018 02:23:23 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D9EE5BFDC44C7; Wed, 18 Apr 2018 10:23:19 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 18 Apr 2018 10:23:21 +0100
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Wed, 18 Apr 2018 17:23:16 +0800
From: "Zhuangyan (Yan)" 
To: Ben Campbell , The IESG 
CC: "draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org" , Susan Hares , "i2rs-chairs@ietf.org" , "shares@ndzh.com" , "i2rs@ietf.org" 
Thread-Topic: Ben Campbell's No Objection on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT)
Thread-Index: AQHTy7xXFtd0xflEsU+Am0GsnHifaKQGVffA
Date: Wed, 18 Apr 2018 09:23:15 +0000
Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785A96BEA30@nkgeml513-mbs.china.huawei.com>
References: <152280878408.24068.18282293731508698195.idtracker@ietfa.amsl.com>
In-Reply-To: <152280878408.24068.18282293731508698195.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.135.170.230]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2018 09:23:25 -0000

SGkgQmVuLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gV2UndmUgZml4ZWQgdGhlbSBpbiB2
ZXJzaW9uLTA5LiANCkJlc3QgUmVnYXJkcywNCg0KWWFuIChvbiBiZWhhbGYgb2YgY28tYXV0aG9y
cykNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlbiBDYW1wYmVsbCBbbWFp
bHRvOmJlbkBub3N0cnVtLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA0LCAyMDE4IDEw
OjI2IEFNDQpUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi1pMnJz
LXlhbmctZGMtZmFicmljLW5ldHdvcmstdG9wb2xvZ3lAaWV0Zi5vcmc7IFN1c2FuIEhhcmVzIDxz
aGFyZXNAbmR6aC5jb20+OyBpMnJzLWNoYWlyc0BpZXRmLm9yZzsgc2hhcmVzQG5kemguY29tOyBp
MnJzQGlldGYub3JnDQpTdWJqZWN0OiBCZW4gQ2FtcGJlbGwncyBObyBPYmplY3Rpb24gb24gZHJh
ZnQtaWV0Zi1pMnJzLXlhbmctZGMtZmFicmljLW5ldHdvcmstdG9wb2xvZ3ktMDg6ICh3aXRoIENP
TU1FTlQpDQoNCkJlbiBDYW1wYmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBw
b3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9s
b2d5LTA4OiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUg
c3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNs
dWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJv
ZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczov
L3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBt
b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu
DQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNh
biBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt
aWV0Zi1pMnJzLXlhbmctZGMtZmFicmljLW5ldHdvcmstdG9wb2xvZ3kvDQoNCg0KDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJIHNoYXJlIElnbmFzJ3MgY29uY2Vy
biBhYm91dCB0aGUgZGVmaW5pdGlvbiBvZiAiZmFicmljIi4gT3RoZXJ3aXNlLCBJIGhhdmUgYSBj
b3VwbGUgb2Ygbml0czoNCg0KQWJzdHJhY3Q6IE1pc3NpbmcgYXJ0aWNsZSBiZWZvcmUgIkRhdGEg
Q2VudGVyIE5ldHdvcmsiLg0KDQrCpzI6IFBsZWFzZSB1c2UgdGhlIGJvaWxlcnBsYXRlIGZyb20g
UkZDIDgxNzQgcmF0aGVyIHRoYW4gcm9sbGluZyB5b3VyIG93biB0ZXh0IHRvIGNvbnN0cmFpbiB0
aGUga2V5d29yZHMgdG8gdGhlaXIgYWxsLWNhcHMgZm9ybXMuDQoNCg0K


From nobody Wed Apr 18 02:30:55 2018
Return-Path: 
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCC112D871; Wed, 18 Apr 2018 02:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level: 
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 QqgPmd2Nq8Sf; Wed, 18 Apr 2018 02:30:45 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 47EB2126BFD; Wed, 18 Apr 2018 02:30:45 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CA370D2932420; Wed, 18 Apr 2018 10:30:41 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 18 Apr 2018 10:30:43 +0100
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Wed, 18 Apr 2018 17:30:39 +0800
From: "Zhuangyan (Yan)" 
To: Ignas Bagdonas , Susan Hares , "'The IESG'" 
CC: "i2rs@ietf.org" , "draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org" , "i2rs-chairs@ietf.org" 
Thread-Topic: FW: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)
Thread-Index: AQHTy0CXrYtKx6W5YEyUq6ube+k3t6Pv+e9ggABe60D//9vygIAANqcAgAW1kRCAEDacgA==
Date: Wed, 18 Apr 2018 09:30:39 +0000
Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785A96BEA45@nkgeml513-mbs.china.huawei.com>
References: <152275562986.13946.4129194230664503798.idtracker@ietfa.amsl.com> <9B4BC45FDEDDD84F813E9E4A5BAF8785A96B7310@nkgeml513-mbs.china.huawei.com> <01d801d3cc28$b5e18410$21a48c30$@ndzh.com> <9d743d24-e4b5-0bcc-eb7e-cdce3f464888@gmail.com> 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.135.170.230]
Content-Type: multipart/alternative; boundary="_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96BEA45nkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [i2rs] FW: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2018 09:30:49 -0000

--_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96BEA45nkgeml513mbschi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSWduYXMsDQoNClRoZSB2ZXJzaW9uLTA5IGluY29ycG9yYXRlZCB0aGUgcmVzcG9uc2VzIGJl
bG93IGhhcyBiZWVuIHVwbG9hZGVkLiBDb3VsZCB5b3UgY2hlY2sgaWYgaXQgY2FuIHJlc29sdmUg
eW91ciBjb21tZW50cz8NCg0KVGhhbmsgeW91IHZlcnkgbXVjaC4NCg0KQmVzdCBSZWdhcmRzLA0K
DQpZYW4gKG9uIGJlaGFsZiBvZiBjby1hdXRob3JzKQ0KDQpGcm9tOiBaaHVhbmd5YW4gKFlhbikN
ClNlbnQ6IFN1bmRheSwgQXByaWwgMDgsIDIwMTggNTozNyBQTQ0KVG86ICdJZ25hcyBCYWdkb25h
cycgPGliYWdkb25hQGdtYWlsLmNvbT47IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+OyAn
VGhlIElFU0cnIDxpZXNnQGlldGYub3JnPg0KQ2M6IGkycnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt
aTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5QGlldGYub3JnOyBpMnJzLWNoYWly
c0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IEZXOiBJZ25hcyBCYWdkb25hcycgRGlzY3VzcyBvbiBk
cmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29yay10b3BvbG9neS0wODogKHdpdGgg
RElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KSGkgSWduYXMsDQoNClRoYW5rcyBmb3IgeW91ciByZXNw
b25zZXMgYW5kIHNvcnJ5IGZvciB0aGUgZGVsYXkgZHVlIHRvIGEgbG9jYWwgaG9saWRheS4gUGxl
YXNlIHNlZSByZXBsaWVzIGlubGluZS4NCg0KRnJvbTogSWduYXMgQmFnZG9uYXMgW21haWx0bzpp
YmFnZG9uYUBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDUsIDIwMTggMjozOCBB
TQ0KVG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNv
bT4+OyAnVGhlIElFU0cnIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPj4NCkNj
OiBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1pMnJzLXlh
bmctZGMtZmFicmljLW5ldHdvcmstdG9wb2xvZ3lAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt
aTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5QGlldGYub3JnPjsgaTJycy1jaGFp
cnNAaWV0Zi5vcmc8bWFpbHRvOmkycnMtY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEZX
OiBJZ25hcyBCYWdkb25hcycgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJy
aWMtbmV0d29yay10b3BvbG9neS0wODogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KDQoN
Cg0KT24gMDQvMDQvMjAxOCAxNjoyMiwgU3VzYW4gSGFyZXMgd3JvdGU6DQoNCklnbmFzOg0KDQoN
Cg0KSeKAmW0gZm9yd2FyZGluZyBZYW7igJlzIHNwZWNpZmljIGFuc3dlcnMgdG8gZWFjaCBvZiB5
b3VyIHF1ZXN0aW9ucy4gSSBoYWQgaGVsZCB0aGlzIHJlc3BvbnNlIGJhY2sgdW50aWwgSSB0cmll
ZCB0byBsZWFybiBtb3JlIGFib3V0IHdoYXQgc3BlY2lmaWMgcXVlc3Rpb25zIHdlcmUgdGFnIHdp
dGggc3BlY2lmaWMgRElTQ1VTUyBxdWFsaXR5IGNvbW1lbnRzDQoNCnBlciB0aGUgSUVTRyAyMDE0
IERJU0NVU1MgY3JpdGVyaWEgY29tbWVudHM6DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cv
ZGlzY3Vzcy1jcml0ZXJpYS1pZXNnLXJldmlldy8NCg0KDQoNCknigJltIHN1cmUgWWFuIHdpbGwg
YmUgZ2xhZCB0byBtYWtlIGFkanVzdG1lbnRzIGluIHRoZSBkcmFmdCAoc2VlIGJlbG93KS4NCg0K
VGhhbmsgeW91IFlhbiwgdGhpcyBzZWVtcyB0byBiZSBhIHByYWN0aWNhbCB3YXkgZm9yd2FyZCBp
biBicmluZ2luZyBjbGFyaXR5IHRvIHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQuDQoNCg0KDQoN
CllvdSB3aWxsIG5vdGUgdGhhdCB5b3UgYXJlIGFza2luZyB1cyB0byBwdXQgYmFjayBpbiBSUENz
IHRoYXQgb3RoZXJzIGhhZCB1cyB0YWtlIG91dC4NCg0KSSB3aWxsIG5vdGUgdGhhdCBJIGFtIG5v
dCBhc2tpbmcgZm9yIGFueXRoaW5nIGxpa2UgdGhhdC4gUGxlYXNlIHJlLXJlYWQgbXkgRElTQ1VT
UyBub3Rlcy4NCg0KDQoNCg0KVGhpcyBsZWFkcyBtZSB0byBiYWNrIHRvIG15IHF1ZXN0aW9ucyBh
cyBhIFNoZXBoZXJkLiBNeSBjb25jZXJuIGlzIHRoYXQgbWFueSBvZiB5b3VyIHJlcXVlc3RlZCBj
aGFuZ2VzDQoNCkkgcmVjYWxsIHJhaXNpbmcgcXVlc3Rpb25zLCBub3QgcmVxdWVzdGluZyBjaGFu
Z2VzLg0KDQoNCmFyZSBjb3VudGVyIHRvIGFncmVlbWVudHMgaW4gZGlzY3Vzc2lvbnMgd2l0aCBX
RywgVEUgV0csIE5FVENPTkYvTkVUTU9ELCBhbmQgcHJldmlvdXMgQURTIChPUFMsIFJURykgcmVn
YXJkaW5nIEkyUlMgZHJhZnRzLiAgIFNpbmNlIHRoZXNlIGRyYWZ0cyB3ZXJlIGRlbGF5ZWQgZHVl
IHRvIHRoZSByZWFkaW5nIGxvYWQgb2YgdGhlIElFU0csIGl0IHNlZW1zIHdlIGFyZSB3b3JraW5n
IHVuZGVyIGRpZmZlcmVudCBydWxlcy4gIFNvLCBwbGVhc2Ugc3BlY2lmeSBob3cgeW91ciBjb21t
ZW50cyBtYXRjaCB0aGUgRElTQ1VTUyBjcml0ZXJpYS4gIElmIHlvdSBhcmUgc2V0dGluZyBuZXcg
cnVsZXMgZm9yIEkyUlMgZG9jdW1lbnRzLCBwbGVhc2UgZGV0YWlsIHRoZSBuZXcgcnVsZXMgb2Yg
cmV2aWV3Lg0KDQoNCg0KSXQgaXMgdG9vIGJhZCB0aGF0IHdlIGNvdWxkIG5vdCBoYXZlIHJldmll
d2VkIHRoZXNlIGRvY3VtZW50cyBkdXJpbmcgdGhlaXIgb3JpZ2luYWxseSBzY2hlZHVsZWQgdGVs
ZWNoYXQgd2l0aCBwcmV2aW91cyAgQURzLg0KDQoNCg0KU3VzYW4gSGFyZXMNCg0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJZ25hcyBCYWdkb25hcyBbbWFpbHRvOmliYWdk
b25hQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDAzLCAyMDE4IDc6NDAgUE0NClRv
OiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+DQpDYzogZHJh
ZnQtaWV0Zi1pMnJzLXlhbmctZGMtZmFicmljLW5ldHdvcmstdG9wb2xvZ3lAaWV0Zi5vcmc8bWFp
bHRvOmRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5QGlldGYu
b3JnPjsgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29t
Pj47IGkycnMtY2hhaXJzQGlldGYub3JnPG1haWx0bzppMnJzLWNoYWlyc0BpZXRmLm9yZz47IHNo
YXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPjsgaTJyc0BpZXRmLm9yZzxtYWls
dG86aTJyc0BpZXRmLm9yZz4NClN1YmplY3Q6IElnbmFzIEJhZ2RvbmFzJyBEaXNjdXNzIG9uIGRy
YWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5LTA4OiAod2l0aCBE
SVNDVVNTIGFuZCBDT01NRU5UKQ0KDQoNCg0KSWduYXMgQmFnZG9uYXMgaGFzIGVudGVyZWQgdGhl
IGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQoNCmRyYWZ0LWlldGYtaTJycy15YW5nLWRj
LWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5LTA4OiBEaXNjdXNzDQoNCg0KDQpXaGVuIHJlc3BvbmRp
bmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwg
ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy
ZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KDQoN
Cg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp
c2N1c3MtY3JpdGVyaWEuaHRtbA0KDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJ
U0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNCg0KDQoNClRoZSBkb2N1bWVudCwgYWxv
bmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCg0KaHR0
cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctZGMtZmFi
cmljLW5ldHdvcmstdG9wb2xvZ3kvDQoNCg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KRElT
Q1VTUzoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KSSBoYXZlIGNvbmNlcm5zIGFib3V0IHRoZSBw
cmFjdGljYWwgdXNhYmlsaXR5IG9mIHRoaXMgcHJvcG9zZWQgbW9kZWwgYXMgaXQgaXMgc3BlY2lm
aWVkIG5vdy4NCg0KDQoNClRoZSBpbnRlbmRlZCBkZWNvdXBsaW5nIG9mIGZhYnJpYyBpbXBsZW1l
bnRhdGlvbiBwcm9wZXJ0aWVzICh3aGF0IGlzIHRlcm1lZCBhcyAidW5kZXJsYXkgbmV0d29yayBp
bmZyYXN0cnVjdHVyZSIgaW4gdGhlIGRvY3VtZW50KSBhbmQgaXRzIHRvcG9sb2d5IHNlZW1zIHRv
IGJlIGNvbnRyYWRpY3RpbmcgdG8gZ2VuZXJhbCBvcGVyYXRpb25hbCBwcmFjdGljZXMgb2YgZmFi
cmljIGJhc2VkIG5ldHdvcmtzLiBJdCBpcyBnZW5lcmFsbHkgdHJ1ZSBmb3IgdGhlIGNvbnRleHQg
b2YgdGhlIG92ZXJsYXkgYnV0IHRoYXQgaXMgbm90IHdoYXQgdGhlIGRvY3VtZW50IHNlZW1zIHRv
IGJlIGZvY3VzaW5nIG9uLiBGYWJyaWMgZGVmaW5lcyBhbmQgaW1wbGVtZW50cyB0aGUgdW5kZXJs
YXksIG5vdCB0aGUgb3RoZXIgd2F5IGFyb3VuZC4NCg0KW1ldIFRoZSBpbnRlbnRpb24gb2YgdGhp
cyBtb2RlbCBpcyB0byByZXByZXNlbnQgdGhlIGVudGlyZSB0b3BvbG9neSBvZiBhIGRhdGEgY2Vu
dGVyIGZhYnJpYyBuZXR3b3JrLg0KDQpZYW4sIGNhbiB5b3UgYmUgc3BlY2lmaWMgaGVyZSAtIHRo
ZSB0b3BvbG9neSBvZiB3aGF0PyBBcmUgd2UgdGFsa2luZyBhYm91dCB0aGUgdW5kZXJsYXkgdG9w
b2xvZ3ksIG9yIGFuIG92ZXJsYXkgaW5zdGFuY2UgdG9wb2xvZ3k/IFRoYXQgaXMgYSBtYWpvciBk
aWZmZXJlbmNlIGFuZCBtYW55IG90aGVyIGNvbW1lbnRzIHdpbGwgZGVwZW5kIG9uIHRoaXMgYW5z
d2VyLiBUaGUgdGVybWlub2xvZ3kgZG9lcyBub3QgaGVscCBoZXJlIHRvbyBtdWNoIC0gZGF0YSBj
ZW50ZXIgZmFicmljIG5ldHdvcmsgbWF5IG1lYW4gbWFueSBkaWZmZXJlbnQgdGhpbmdzIGlmIHZp
ZXdlZCBmcm9tIGRpZmZlcmVudCBjb250ZXh0cy4NCg0KW1ldIFdlIHByb3ZpZGUgYW4gZW50aXJl
IHRvcG9sb2d5IGZvciBhIGRjIGZhYnJpYy4gVGhpcyBmYWJyaWMgY29udGFpbnMgc2V2ZXJhbCBQ
T0RzIGFzIGl0cyDigJxub2Rl4oCdLCBlYWNoIG9mIHdoaWNoIGlzIGNvbXBvc2VkIG9mIGEgc2V0
IG9mIHVuZGVybGF5IG5vZGVzICh3aGljaCBhcmUgZGV2aWNlIG5vZGVzKSBhbmQgdGhlaXIgaW50
ZXJjb25uZWN0aW9uIGxpbmtzLCBhbmQgbWF5IGltcGxlbWVudCBkaWZmZXJlbnQgb3ZlcmxheXMu
IFRoZSBsaW5rcyBvZiB0aGlzIGZhYnJpYyBjYW4gYmUgY29ubmVjdGlvbnMgYmV0d2VlbiBQT0Rz
LCBpbnRlcmNvbm5lY3Rpb25zIHdpdGhpbiBhIFBPRCBvciBjb25uZWN0aW9ucyB0byBXQU5zLg0K
DQpUaGUgd2hvbGUgbmV0d29yayBjYW4gYmUgY29uc2lkZXJlZCBhcyBhIHNpbmdsZSBmYWJyaWMg
bmV0d29yayB3aGljaCBpcyBjb21wb3NlZCBieSBzZXZlcmFsIFBPRHMgZGVmaW5lZCBhcyDigJxu
b2Rl4oCdIGluIHRoaXMgbW9kdWxlLiBVbmRlciB0aGVzZSDigJxub2Rlc+KAnSwgdGhlcmUgYXJl
IHN1cHBvcnRpbmctbm9kZXMgKHJlZmVyZW5jZSB0byBkZXZpY2Utbm9kZXMgYmVsb25nZWQgdG8g
dGhlIFBPRCkgYW5kIGNvbm5lY3Rpb25zLg0KDQoNCg0KVGhlIHRlcm0gb2YgUE9EL2ZhYnJpYyBp
cyBhIGJpdCBjb25mdXNpbmcgaW4gdGhlIGRyYWZ0LiBIb3cgYWJvdXQgd2UgdXBkYXRpbmcgdGhl
IFRlcm1pbm9sb2d5IHNlY3Rpb24gYXMgYmVsb3c/DQoNClBPRDogYSBtb2R1bGUgb2YgbmV0d29y
aywgY29tcHV0ZSwgc3RvcmFnZSwgYW5kIGFwcGxpY2F0aW9uIGNvbXBvbmVudHMgdGhhdCB3b3Jr
IHRvZ2V0aGVyIHRvIGRlbGl2ZXIgbmV0d29ya2luZyBzZXJ2aWNlcy4gSXQgcmVwcmVzZW50cyBh
IHJlcGVhdGFibGUgZGVzaWduIHBhdHRlcm4uIEl0cyBjb21wb25lbnRzIG1heGltaXplIHRoZSBt
b2R1bGFyaXR5LCBzY2FsYWJpbGl0eSwgYW5kIG1hbmFnZWFiaWxpdHkgb2YgZGF0YSBjZW50ZXJz
Lg0KDQpGYWJyaWM6IGNvbXBvc2VkIG9mIHNldmVyYWwgUE9EcyB0byBmb3JtIGEgZGF0YSBjZW50
ZXIgbmV0d29yay4NCg0KDQoNCkRvZXMgaXQgbWFrZSBzZW5zZT8NCg0KDQpJdCBpcyBjbG9zZXIg
dG8gYm90aCB0aGUgdGVybWlub2xvZ3kgYW5kIGRlc2lnbiB1c2VkIGluIGFjdHVhbCBkZXBsb3lt
ZW50cy4NCltZXSBUaGFua3MuIFdlIHdpbGwgYWRkIHRoZXNlIHRvIHRoZSB0ZXJtaW5vbG9neSBw
YXJ0Lg0KDQoNClRoZSBkb2N1bWVudCBkb2VzIG5vdCBjb250YWluIGEgc3VmZmljaWVudCBkZXNj
cmlwdGlvbiBvZiB0aGUgbG9naWMgb2YgdGhlIG1vZGVsIGl0c2VsZiwgdGhlIHJlYXNvbnMgZm9y
IGNob2ljZXMgbWFkZSBmb3IgcmVwcmVzZW50YXRpb24gb2YgdHlwZXMgYW5kIGF0dHJpYnV0ZXMs
IGFuZCBhdCB0aGUgc2FtZSB0aW1lIGRlc2NyaXB0aW9ucyBpbiBtb2R1bGVzIGFyZSBzaW5nbGUg
bGluZXMgdGhhdCBkbyBub3QgYWRkIGNsYXJpZmljYXRpb24gYmV5b25kIGJlaW5nIGNvcGllcyBv
ZiBsZWFmIG5hbWVzLiBFaXRoZXIgdGhlcmUgbmVlZHMgdG8gYmUgYSBzZWN0aW9uIHRoYXQgZGVz
Y3JpYmVzIHRoZSBsb2dpYyBvZiB0aGUgbW9kZWwgYW5kIGhvdyBpdCByZWxhdGVzIHRvIG90aGVy
IG1vZGVscywgYWxzbyBpbmNsdWRpbmcgZXhhbXBsZXMsIG9yIG1vZHVsZSBkZXNjcmlwdGlvbiBm
aWVsZHMgbmVlZCB0byBoYXZlIGVub3VnaCBjb250ZW50IHRvIGJlIGFibGUgdG8gaGF2ZSBlcXVp
dmFsZW50IHVuZGVyc3RhbmRpbmcgb2YgbW9kZWwgaW50ZW50IGFuZCBvcGVyYXRpb24uIEJvdGgg
YXJlIHN0cm9uZ2x5IGVuY291cmFnZWQsIGFzIGRlc2NyaXB0aW9ucyBoYXZlIHZhbHVlIG9mIGl0
c2VsZiBmb3IgYmVpbmcgYSByZWZlcmVuY2UgZm9yIHVzZSwgYW5kIG1vZGVsIGRlc2NyaXB0aW9u
IGlzIG5lZWRlZCBmb3IgdW5kZXJzdGFuZGluZyBob3cgdGhpcyBwYXJ0aWN1bGFyIG1vZGVsIGZp
dHMgaW50byB0aGUgbGFyZ2VyIGhpZXJhcmNoeS4gTmV0d29yayBtYW5hZ2VtZW50IGRvZXMgbm90
IGVuZCBhdCB0aGUgYm91bmRhcnkgb2YgdGhlIHNpbmdsZSBkb21haW4tc3BlY2lmaWMgbW9kZWws
IGl0IGlzIGltcG9ydGFudCB0byBidWlsZCBpdCBpbnRvIGEgd2hvbGUgc3lzdGVtLg0KDQoNCg0K
V2h5IFRFIHRvcG9sb2d5IG1vZGVsIGlzIG5vdCBzdWZmaWNpZW50IGZvciBtb2RlbGxpbmcgdGhl
IHJlcHJlc2VudGF0aW9uIG9mIERDIGZhYnJpYz8gV2h5IGlzIERDIGZhYnJpYyBuZXR3b3JrIHRv
cG9sb2d5IHNwZWNpYWwgY29tcGFyZWQgdG8gYW55IGdlbmVyaWMgZmFicmljIGJhc2VkIHRvcG9s
b2d5Pw0KDQpbWV0gV2UgZGlzY3Vzc2VkIHdpdGggVEUgdG9wb2xvZ3kgbW9kZWwgYXV0aG9ycyBh
Ym91dCB0aGlzIHF1ZXN0aW9uLiBGb3IgVEUsIGl0IGlzIG1vcmUgZm9jdXNlZCBvbiBjb25uZWN0
aW9ucyBmb3IgVEUgYW5kIHN0YXRpY3MgZm9yIHRoZWlyIHBlcmZvcm1hbmNlLCB3aGlsZSB0aGlz
IG1vZGVsIGlzIHRvIHByZXNlbnQgaG93IGEgZGF0YSBjZW50ZXIgbmV0d29yayBsb29rIGxpa2Ug
d2l0aCBpdHMgc3BlY2lmaWMgbm9kZXMobGVhZi9zcGluZSkuDQoNCkxlYWYvc3BpbmUgaXMgYSBu
b2RlLCBub2RlcyBhcmUgaW50ZXJjb25uZWN0ZWQgYnkgbGlua3MuIERlcGVuZHMgb24gdGhlIGNv
bnRleHQgb2YgdGhlIGVhcmxpZXIgcXVlc3Rpb24gYWJvdXQgdGhlIHVuZGVybGF5IGFuZCBvdmVy
bGF5LiBMaW5rcyBhbmQgbm9kZXMgY2FuIGRlZmluaXRlbHkgYmUgcmVwcmVzZW50ZWQgYnkgVEUg
bW9kZWwuIFdoYXQgaXMgYSBsZWFmL3NwaW5lIG5vZGUgaW4gdGhlIG92ZXJsYXkgY29udGV4dD8N
CltZXSBMZWFmL3NwaW5lIGlzIHRoZSByb2xlIG9mIGEgZGV2aWNlIG5vZGUgd2l0aGluIGEgcG9k
LiBJdCBpbmRpY2F0ZXMgaXRzIGZ1bmN0aW9ucy4gU3VjaCBhcywgZm9yIGRpc3RyaWJ1dGVkIEdX
LCBpdCB3aWxsIGJlIGRlcGxveWVkIG9uIExFQUYgbm9kZS4NCg0KDQoNCkhvdyB0aGlzIG1vZGVs
IGNvdWxkIGJlIHVzZWQgZm9yIHJlcHJlc2VudGluZyBtb3JlIHRoYW4gdHdvIHN0YWdlIGZhYnJp
Y3MgdGhhdCBhcmUgaW4gd2lkZSBkZXBsb3ltZW50Pw0KDQpbWV0gSW4gdGhhdCBjYXNlLCBtb3Jl
IHJvbGVzIGZvciBpbnRlcmxheWVyIGRldmljZXMgY2FuIGJlIGFkZGVkLiBUaGUg4oCccm9sZeKA
nSBmb3IgZGV2aWNlIGlzIGRlZmluZWQgYXMgaWRlbnRpdHktcmVmLiBOZXcgcm9sZXMgY2FuIGJl
IGFkZGVkIGJ5IGRlZmluaW5nIG5ldyBpZGVudGl0aWVzLg0KVGhpcyBuZWVkcyB0byBiZSBkb2N1
bWVudGVkLiBPciwgaWYgeW91IGludGVuZCB0byBsaW1pdCB0aGUgc2NvcGUgdG8gdHdvIHN0YWdl
cyAoYXMgaXQgaXMgaW1wbGllZCBhdCB0aGUgbW9tZW50KSAtIHRoaXMgYWxzbyBuZWVkcyB0byBi
ZSBleHBsaWNpdGx5IHN0YXRlZCBpbiB0aGUgZG9jdW1lbnQuIFdoYXQgaXMgYW4gaW50ZXJsYXll
ciBkZXZpY2U/DQpbWV0gT2ssIGl0IHdpbGwgYmUgYWRkZWQgdG8gdGhlIGRlZmluaXRpb24gb2Yg
cm9sZS4gRXJy4oCmYW4gaW50ZXJsYXllciBkZXZpY2UgaXMgZm9yIG90aGVyIGxheWVycyBiZXNp
ZGVzIFNQSU5FL0xFQUYuDQoNCg0KDQpMaW1pdGluZyBwb3J0IGJhbmR3aWR0aCB0byBhIGZpeGVk
IHJhdGUgaXMgdG9vIHJlc3RyaWN0aXZlLiBUaGUgbW9kZWwgYXMgc3BlY2lmaWVkIGFscmVhZHkg
ZG9lcyBub3QgY292ZXIgYSBzZXQgb2YgcG9ydCBzcGVlZHMgdGhhdCBhcmUgaW4gZGVwbG95bWVu
dC4NCg0KW1ldIGJhbmR3aWR0aCBpcyBkZWZpbmVkIGFzIGlkZW50aXR5LXJlZi4gT3RoZXIgc3Bl
ZWRzIGNhbiBiZSBhZGRlZCBieSBkZWZpbmluZyBuZXcgaWRlbnRpdGllcy4NCg0KDQpOZWVkcyB0
byBiZSBkb2N1bWVudGVkLg0KW1ldIE9rLCBpdCB3aWxsIGJlIGFkZGVkIHRvIHRoZSBkZWZpbml0
aW9uIG9mIGJhbmR3aWR0aC4NCg0KDQpIb3cgd291bGQgYSBkZXZpY2UgdGhhdCBoYXMgbW9yZSB0
aGFuIGEgc2luZ2xlIHJvbGUgaW4gdGhlIGZhYnJpYyBiZSByZXByZXNlbnRlZD8NCg0KW1ldIFRo
ZSByb2xlIGZvciBhIGRldmljZS1ub2RlIGlzIGRlZmluZWQgYXMgbGVhZi1saXN0IHRvIHN1cHBv
cnQgYSBkZXZpY2Ugd2l0aCBtb3JlIHRoYW4gb25lIHJvbGVzLg0KDQoNCg0KU2VydmljZSBjYXBh
YmlsaXRpZXMgYXMgdGhleSBhcmUgZGVzY3JpYmVkIGJlbG9uZyB0byB0aGUgb3ZlcmxheSBjb250
ZXh0IHdoaWxlIHRoZXkgYXJlIGNhbGxlZCBkZXZpY2UgY2FwYWJpbGl0aWVzLiBBcmUgdGhvc2Ug
dGhlIG9ubHkgcG9zc2libGUgc2VydmljZSBjYXBhYmlsaXRpZXM/IFdoYXQgaXMgdGhlIGVmZmVj
dCBvZiBjb25maWd1cmluZyB0aG9zZSBjYXBhYmlsaXRpZXM/DQoNCltZXSBTZXJ2aWNlIGNhcGFi
aWxpdGllcyBpcyBmb3IgYSBmYWJyaWMgbm90IGEgZGV2aWNlLiBUaGUgZGVzY3JpcHRpb24gZm9y
IHRoZSBzZXJ2aWNlIGNhcGFiaWxpdGllcyB3aWxsIGJlIGNvcnJlY3RlZC4gRm9yIGJldHRlciBl
eHRlbnNpb24gZm9yIG90aGVyIHNlcnZpY2VzLCB3ZSB3aWxsIGNoYW5nZSBjdXJyZW50IGVudW1l
cmF0aW9uIHR5cGUgdG8gaWRlbnRpdHktcmVmLiBNb3JlIHNlcnZpY2UgaWRlbnRpdGllcyBjYW4g
YmUgZGVmaW5lZCBpbiB0aGUgZnV0dXJlIGJ5IHZlbmRvcnMuDQpUaGUgZXh0ZW5zaWJpbGl0eSBt
ZWNoYW5pc20gbmVlZHMgdG8gYmUgZG9jdW1lbnRlZC4NCltZXSBPaywgaXQgd2lsbCBiZSBhZGRl
ZCB0byB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgc2VydmljZSBjYXBhYmlsaXR5Lg0KDQoNCg0KV2hh
dCBpcyBjb21wb3NlLWZhYnJpYyBSUEM/IFRoZSBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgYW55
IFJQQ3MuDQoNCltZXSBycGNzIHdlcmUgcmVtb3ZlZCBpbiBwcmV2aW91cyB2ZXJzaW9uIHNpbmNl
IHBlb3BsZSBzYXkgaXQgd291bGQgbGVhdmUgZm9yIHZlbmRvci1zcGVjaWZpYyBpbXBsZW1lbnRh
dGlvbi4NCg0KVGhlIHJwY3MgdG8gY29tcG9zZSBhIGZhYnJpYyBpcyBhczoNCg0KICAgIHJwYyBj
b21wb3NlLWZhYnJpYyB7DQoNCiAgICAgICAgaW5wdXQgew0KDQogICAgICAgICAgICB1c2VzIGZh
YnJpYy1hdHRyaWJ1dGVzOw0KDQogICAgICAgIH0NCg0KICAgICAgICBvdXRwdXQgew0KDQogICAg
ICAgICAgICBsZWFmIGZhYnJpYy1pZCB7DQoNCiAgICAgICAgICAgICAgICB0eXBlIGZhYnJpYy1p
ZDsNCg0KICAgICAgICAgICAgfQ0KDQogICAgICAgIH0NCg0KfQ0KDQpUbyBhZGQgYSBub2RlIHRv
IGZhYnJpYzoNCg0KDQoNCiAgICBycGMgYWRkLW5vZGUtdG8tZmFicmljIHsNCg0KICAgICAgICBp
bnB1dCB7DQoNCiAgICAgICAgICAgIGxlYWYgZmFicmljLWlkIHsNCg0KICAgICAgICAgICAgICAg
IHR5cGUgZmFicmljLWlkOw0KDQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAgIHVzZXMgZGV2
aWNlLWF0dHJpYnV0ZXM7DQoNCiAgICAgICAgfQ0KDQogICAgfQ0KDQpEbyB5b3Ugc3VnZ2VzdCB3
ZSBicmluZyBpdCBiYWNrIHRvIHRoZSBkcmFmdD8NCkkgYW0gbm90IHN1Z2dlc3RpbmcgYW55dGhp
bmcsIEkgd2FzIGFza2luZyBhYm91dCB0aGUgY29tcG9zZS1mYWJyaWMgUlBDIHRoYXQgd2FzIG1l
bnRpb25lZCBpbiB0aGUgZG9jdW1lbnQuDQpbWV0gV2Ugd2lsbCBjbGFyaWZ5IGl0IGluIHYtMDku
DQoNCg0KDQoNCg0KV2hhdCBpcyBwb2xpY3kgZHJpdmVuIHRyYWZmaWMgYmVoYXZpb3I/IElzIHRo
ZXJlIHRoZSBvbmx5IG9uZSBwb2xpY3kgdGhhdCBmaXRzIGFsbCBwb3NzaWJsZSBkZXBsb3ltZW50
IHNjZW5hcmlvcz8NCg0KW1ldIFBvbGljeSBpcyBuZWVkZWQgZm9yIHRoZSB0cmFmZmljIG90aGVy
d2lzZSB0aGUgdHJhZmZpYyB3aWxsIGJlIGRpc2NhcmQuIFRoZXJlIGNhbiBhbHNvIGJlIG5vcm1h
bCwgd2hpY2ggbWVhbnMgbm8gcG9saWN5IGlzIG5lZWRlZCBmb3IgYWxsIHRyYWZmaWMuDQoNCg0K
SXQgbmVlZHMgdG8gYmUgZG9jdW1lbnRlZCBvbiB3aGF0IGlzIG1lYW50IGJ5IHBvbGljeSAtIHdo
YXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhhdCBwb2xpY3ksIHdoZXJlIGFuZCBob3cgaXQgc2hvdWxk
IGJlIGluc3RhbnRpYXRlZC4NCltZXUl0IHdpbGwgYmUgY2xhcmlmaWVkIGluIHYtMDkuDQoNCkxv
b2tpbmcgYXQgdGhlIGhpc3Rvcnkgb2YgdGhlIGRvY3VtZW50IGZyb20gdGhlIGluZGl2aWR1YWwg
c3VibWlzc2lvbiB0aW1lIGFuZCB0aGUgY29tbWVudHMgcmVjZWl2ZWQsIGl0IHNlZW1zIHRoYXQg
dGhlIHBvaW50IGZpeGVzIHRvIHRoZSB0ZXh0IHdlbnQgaW4gdG8gY292ZXIgdGhlIHNwZWNpZmlj
IGNvbW1lbnRzIGJ1dCBub3QgdG8gYWRkcmVzcyB0aGUgYnJvYWRlciBzY29wZSBvZiBjb21tZW50
cy4NCg0KVGhlIGRvY3VtZW50IHdvdWxkIGRlZmluaXRlbHkgYmVuZWZpdCBmcm9tIGEgbWFqb3Ig
cmV3cml0ZSBjbGFyaWZ5aW5nIHRoZSBsb2dpYyBiZWhpbmQgdGhlIGRlY2lzaW9ucyBtYWRlLCBh
bGlnbmluZyBtb3JlIHdpdGggdGhlIG9wZXJhdGlvbmFsIHByYWN0aWNlIG9mIGZhYnJpYyBiYXNl
ZCBuZXR3b3JrIGRlc2lnbiBhbmQgZGVwbG95bWVudCwgYW5kIGJyaW5naW5nIHRoZSBjb250ZW50
IGluIFlBTkcgbW9kdWxlcyB0byBiZSBzZWxmLWRlc2NyaWJpbmcuDQoNCg0KDQoNCg0KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KDQpDT01NRU5UOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpGYWJyaWMgYW5kIFBP
RCBhcmUgbm90IGVxdWl2YWxlbnQgdGVybXMuDQoNCg0KDQpJMlJTIHVzZSBjYXNlIHJlcXVpcmVt
ZW50cyBkb2N1bWVudCBoYXMgZXhwaXJlZCAxMSBtb250aHMgYWdvLiBVc2UgY2FzZXMgZG9jdW1l
bnRzIGFyZSBnb29kIGZvciB0cmFja2luZyB0aGUgd29yayBwcm9ncmVzcyBvZiBzcGVjaWZpY2F0
aW9uIGRvY3VtZW50cywgaXQgaXMgcXVlc3Rpb25hYmxlIHdoZXRoZXIgc3RhbmRhbG9uZSB1c2Ug
Y2FzZXMgZG9jdW1lbnRzIHByb3ZpZGUgdmFsdWUgYmV5b25kIGhpc3RvcmljIHJlY29yZC4gSXMg
dGhlIHJlZmVyZW5jZSB0byBJMlJTIHVzZSBjYXNlcyBkb2N1bWVudCByZWFsbHkgbmVlZGVkPw0K
DQpbWV0gVGhlIHJlZmVyZW5jZSB3aWxsIGJlIHJlbW92ZWQgaW4gdjA5Lg0KDQoNCg0KV2hhdCBp
cyBhdG9taWMgbmV0d29yaz8NCg0KW1ldIFRoZSBvcmlnaW5hbCBzZW50ZW5jZSBtaWdodCBiZSBj
b25mdXNpbmcuIEhvdyBhYm91dCB3ZSBjaGFuZ2luZyBpdCB0byDigJxhIFBPRCBjYW4gYmUgY29u
c2lkZXJlZCBhcyBhIGJhc2ljIHN0cnVjdHVyZSBmb3IgbWFuYWdlbWVudCBwdXJwb3Nlcy7igJ0/
DQoNCg0KV2hhdCBpcyBhIGJhc2ljIHN0cnVjdHVyZSB0aGVuPyBJZiB0aGlzIGlzIGluIG92ZXJs
YXkgY29udGV4dCB0aGVuIGl0IGlzIG5vdCBvYnZpb3VzIHdoYXQgUE9EIG1lYW5zIHRoZXJlLiBJ
ZiB0aGlzIGlzIGluIHVuZGVybGF5IGNvbnRleHQgdGhlbiBjb25jZXB0dWFsbHkgaXQgaXMgY2xl
YXIgYnV0IHF1aXRlIGZhciBhd2F5IGZyb20gb3BlcmF0aW9uYWwgcmVhbGl0eS4NCltZXSBJdCBp
cyBhIHNldCBvZiBub2RlcyBhbmQgbGlua3Mgd2hpY2ggY29tcG9zZXMgYSBQT0QgYW5kIGFsc28g
c3VwcG9ydHMgYW4gb3ZlcmxheSBpbnN0YW5jZS4NCg0KVkxBTiBpcyBub3QgYSBmYWJyaWMgYnVp
bGRpbmcgdGVjaG5vbG9neSBhcyBzdWNoLCB3aGlsZSBFdGhlcm5ldCBpcy4NCg0KDQoNCldoYXQg
aXMgdGhlIG5lZWQgZm9yIFZOSSBjYXBhY2l0eSBsZWF2ZXM/IFdoYXQgaXMgdGhlaXIgZWZmZWN0
IGlmIGNvbmZpZ3VyZWQ/DQoNCltZXSBJdCBpcyB1c2VkIHRvIHNheSB0aGUgcmFuZ2Ugb2YgdGhl
IFZOSXMgZm9yIGEgUE9ELiBXZSB3aWxsIHVwZGF0ZSB0aGUgZGVzY3JpcHRpb24gdG8gY2xhcmlm
eSBpdC4NCg0KDQoNClRoZSBkb2N1bWVudCBpbnRlcm1peGVzIGlldGYtZmFicmljLSogYW5kIGll
dGYtZGMtZmFicmljLSogbmFtZXNwYWNlcy4NCg0KW1ldIEFwb2xvZ2l6ZSBmb3IgdGhlIGluY29u
c2lzdGVudC4gSXQgd2lsbCBiZSBjaGFuZ2VkIHRvIGlldGYtZGMtZmFicmljLSogaW4gdjA5Lg0K
DQoNCg0KU2VyaWFsIHBvcnQtdHlwZSBpcyBwcmVzZW50IHdoaWxlIEluZmluaWJhbmQgaXMgbm90
IC0gSW5maW5pYmFuZCBiYXNlZCBmYWJyaWNzIGFyZSB3aWRlbHkgZGVwbG95ZWQuIFdoYXQgaXMg
dGhlIGV4dGVuc2liaWxpdHkgbWVjaGFuaXNtIGZvciBhZGRpbmcgaW4gbmV3IHBvcnQgdHlwZXM/
DQoNCltZXSBTaW5jZSB0aGUgcG9ydC10eXBlIGlzIGlkZW50aXR5cmVmLCBuZXcgcG9ydCB0eXBl
cyBjYW4gYmUgYWRkZWQgYnkgZGVmaW5pbmcgbmV3IGlkZW50aXRpZXMuDQpQbGVhc2UgZG9jdW1l
bnQgdGhlIGV4dGVuc2liaWxpdHkuDQpbWV0gT2ssIHdlIHdpbGwgZG9jdW1lbnQgaXQgaW4gdGhl
IGRlZmluaXRpb24gb2YgcG9ydC10eXBlLg0KDQoNCg0KSXMgdGhlcmUgYW55IGRlcGxveW1lbnQg
ZXhwZXJpZW5jZSB3aXRoIHRoaXMgbW9kZWw/IFRoZSBPREwgZmFhcyBwcm9qZWN0IGhhc24ndCBn
b3QgbXVjaCBhY3Rpdml0eSBvdmVyIGxhc3QgdHdvIHllYXJzLiBBcmUgeW91IGF3YXJlIG9mIGFu
eSBvdGhlciBpbXBsZW1lbnRhdGlvbnMgb3IgZGVwbG95bWVudHM/DQoNCltZXSBZZXMsIHRoZSBp
bXBsZW1lbnRhdGlvbiBpcyBpbiBPREwgRkFBUy4gQ3VycmVudCBtb2R1bGUgaXMgYSBwYXJ0IG9m
IGZhc3MgcHJvamVjdC4gSXQgaGFzIGJlZW4gZG9uZSBvdmVyIHR3byB5ZWFycyBhbmQgb25seSBt
YWludGVuYW5jZSBpcyBuZWVkZWQuIEFuZCB3ZSB0aGluayBpdCBpcyBzdGFibGUuDQoNCkdvb2Qu
IFNvIHRoaXMgaW4gZmFjdCBpcyBjbG9zZXIgdG8gRkFBUyBhbmQgdGhlcmVmb3JlIHRoZSBjb250
ZXh0IG9mIHRoZSBkb2N1bWVudCBpcyB0aGUgb3ZlcmxheS4gVGhlIGRvY3VtZW50IG5lZWRzIHRv
IHN0YXRlIHRoYXQgY2xlYXJseS4NCg0KT3ZlcmFsbCBpdCBzZWVtcyB0aGF0IHdoYXQgaXMgbWlz
c2luZyBpbiB0aGUgZG9jdW1lbnQgaXMgdGhlIGNvbnRleHQgY2xhcmlmaWNhdGlvbi4gT25jZSB0
aGUgY29udGV4dCBvZiB0aGlzIG1vZGVsIGlzIGNsZWFybHkgZGVmaW5lZCB0aGUgcmVzdCBvZiBj
b21tZW50cyB3aWxsIGJlIGVhc2llciB0byBhZGRyZXNzLg0KDQpUaGFuayB5b3UuDQoNCklnbmFz
DQoNCg==

--_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96BEA45nkgeml513mbschi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgWWFI
ZWkgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1
IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9z
ZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBN
aWNyb3NvZnQgWWFIZWkgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0O30NCi8q
IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv
Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6Ymxh
Y2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl
ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
Y29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5U
ZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLnuq/mlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpwDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt
Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwg
Q2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl
OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7
fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkNoYXIwDQoJe21zby1zdHlsZS1uYW1lOiLm
ibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseToiTWljcm9zb2Z0IFlhSGVpIFVJ
IixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28t
c3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
bXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAu
UGxhaW5UZXh0LCBsaS5QbGFpblRleHQsIGRpdi5QbGFpblRleHQNCgl7bXNvLXN0eWxlLW5hbWU6
IlBsYWluIFRleHQiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi
UGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN
Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJC
YWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0K
cC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRleHQsIGRpdi5CYWxsb29uVGV4dA0KCXttc28tc3R5
bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0
eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9
DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT
dHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w
cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBJZ25hcyw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSB2ZXJzaW9uLTA5IGluY29y
cG9yYXRlZCB0aGUgcmVzcG9uc2VzIGJlbG93IGhhcyBiZWVuIHVwbG9hZGVkLiBDb3VsZCB5b3Ug
Y2hlY2sgaWYgaXQgY2FuIHJlc29sdmUgeW91ciBjb21tZW50cz88bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSB2ZXJ5IG11Y2guPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjojMUY0OTdEIj5ZYW4gKG9uIGJlaGFsZiBvZiBjby1hdXRob3JzKTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj
bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv
d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IFpo
dWFuZ3lhbiAoWWFuKQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgQXByaWwgMDgsIDIwMTgg
NTozNyBQTTxicj4NCjxiPlRvOjwvYj4gJ0lnbmFzIEJhZ2RvbmFzJyAmbHQ7aWJhZ2RvbmFAZ21h
aWwuY29tJmd0OzsgU3VzYW4gSGFyZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDs7ICdUaGUgSUVT
RycgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBpMnJzQGlldGYub3JnOyBk
cmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29yay10b3BvbG9neUBpZXRmLm9yZzsg
aTJycy1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEZXOiBJZ25hcyBC
YWdkb25hcycgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29y
ay10b3BvbG9neS0wODogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3
RCI+SGkgSWduYXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3Mg
Zm9yIHlvdXIgcmVzcG9uc2VzIGFuZCBzb3JyeSBmb3IgdGhlIGRlbGF5IGR1ZSB0byBhIGxvY2Fs
IGhvbGlkYXkuIFBsZWFzZSBzZWUgcmVwbGllcyBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+
RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gSWduYXMgQmFn
ZG9uYXMgWzxhIGhyZWY9Im1haWx0bzppYmFnZG9uYUBnbWFpbC5jb20iPm1haWx0bzppYmFnZG9u
YUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAwNSwg
MjAxOCAyOjM4IEFNPGJyPg0KPGI+VG86PC9iPiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs7ICdUaGUgSUVTRycg
Jmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPiZndDs8
YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYu
b3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1u
ZXR3b3JrLXRvcG9sb2d5QGlldGYub3JnIj4NCmRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJp
Yy1uZXR3b3JrLXRvcG9sb2d5QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmkycnMtY2hh
aXJzQGlldGYub3JnIj4NCmkycnMtY2hhaXJzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6
PC9iPiBSZTogRlc6IElnbmFzIEJhZ2RvbmFzJyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtaTJycy15
YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5LTA4OiAod2l0aCBESVNDVVNTIGFuZCBDT01N
RU5UKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAw
NC8wNC8yMDE4IDE2OjIyLCBTdXNhbiBIYXJlcyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
SWduYXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5J4oCZbSBm
b3J3YXJkaW5nIFlhbuKAmXMgc3BlY2lmaWMgYW5zd2VycyB0byBlYWNoIG9mIHlvdXIgcXVlc3Rp
b25zLiBJIGhhZCBoZWxkIHRoaXMgcmVzcG9uc2UgYmFjayB1bnRpbCBJIHRyaWVkIHRvIGxlYXJu
IG1vcmUgYWJvdXQgd2hhdCBzcGVjaWZpYyBxdWVzdGlvbnMgd2VyZSB0YWcgd2l0aCBzcGVjaWZp
YyBESVNDVVNTIHF1YWxpdHkgY29tbWVudHMNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5wZXIgdGhlIElF
U0cgMjAxNCBESVNDVVNTIGNyaXRlcmlhIGNvbW1lbnRzOg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cvZGlzY3Vzcy1jcml0ZXJpYS1pZXNnLXJl
dmlldy8iPmh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cvZGlzY3Vzcy1jcml0ZXJpYS1pZXNnLXJl
dmlldy88L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5J4oCZ
bSBzdXJlIFlhbiB3aWxsIGJlIGdsYWQgdG8gbWFrZSBhZGp1c3RtZW50cyBpbiB0aGUgZHJhZnQg
KHNlZSBiZWxvdykuJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h
biZxdW90OyxzZXJpZiI+PGJyPg0KVGhhbmsgeW91IFlhbiwgdGhpcyBzZWVtcyB0byBiZSBhIHBy
YWN0aWNhbCB3YXkgZm9yd2FyZCBpbiBicmluZ2luZyBjbGFyaXR5IHRvIHRoZSBzY29wZSBvZiB0
aGUgZG9jdW1lbnQuDQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE
Ij5Zb3Ugd2lsbCBub3RlIHRoYXQgeW91IGFyZSBhc2tpbmcgdXMgdG8gcHV0IGJhY2sgaW4gUlBD
cyB0aGF0IG90aGVycyBoYWQgdXMgdGFrZSBvdXQuICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQpJIHdpbGwgbm90ZSB0aGF0IEkg
YW0gbm90IGFza2luZyBmb3IgYW55dGhpbmcgbGlrZSB0aGF0LiBQbGVhc2UgcmUtcmVhZCBteSBE
SVNDVVNTIG5vdGVzLg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMxRjQ5N0QiPlRoaXMgbGVhZHMgbWUgdG8gYmFjayB0byBteSBxdWVzdGlvbnMgYXMg
YSBTaGVwaGVyZC4gTXkgY29uY2VybiBpcyB0aGF0IG1hbnkgb2YgeW91ciByZXF1ZXN0ZWQgY2hh
bmdlcw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi
Pjxicj4NCkkgcmVjYWxsIHJhaXNpbmcgcXVlc3Rpb25zLCBub3QgcmVxdWVzdGluZyBjaGFuZ2Vz
LiA8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5hcmUgY291bnRlciB0byBhZ3JlZW1l
bnRzIGluIGRpc2N1c3Npb25zIHdpdGggV0csIFRFIFdHLCBORVRDT05GL05FVE1PRCwgYW5kIHBy
ZXZpb3VzIEFEUyAoT1BTLCBSVEcpIHJlZ2FyZGluZyBJMlJTIGRyYWZ0cy4mbmJzcDsgJm5ic3A7
U2luY2UgdGhlc2UgZHJhZnRzIHdlcmUgZGVsYXllZCBkdWUgdG8gdGhlIHJlYWRpbmcgbG9hZCBv
ZiB0aGUgSUVTRywgaXQgc2VlbXMgd2UNCiBhcmUgd29ya2luZyB1bmRlciBkaWZmZXJlbnQgcnVs
ZXMuICZuYnNwO1NvLCBwbGVhc2Ugc3BlY2lmeSBob3cgeW91ciBjb21tZW50cyBtYXRjaCB0aGUg
RElTQ1VTUyBjcml0ZXJpYS4mbmJzcDsgSWYgeW91IGFyZSBzZXR0aW5nIG5ldyBydWxlcyBmb3Ig
STJSUyBkb2N1bWVudHMsIHBsZWFzZSBkZXRhaWwgdGhlIG5ldyBydWxlcyBvZiByZXZpZXcuICZu
YnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SXQg
aXMgdG9vIGJhZCB0aGF0IHdlIGNvdWxkIG5vdCBoYXZlIHJldmlld2VkIHRoZXNlIGRvY3VtZW50
cyBkdXJpbmcgdGhlaXIgb3JpZ2luYWxseSBzY2hlZHVsZWQgdGVsZWNoYXQgd2l0aCBwcmV2aW91
cyAmbmJzcDtBRHMuJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPlN1c2FuIEhhcmVzIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLTxicj4NCkZyb206IElnbmFzIEJhZ2RvbmFzIFs8YSBocmVmPSJtYWlsdG86aWJhZ2RvbmFA
Z21haWwuY29tIj5tYWlsdG86aWJhZ2RvbmFAZ21haWwuY29tPC9hPl0NCjxicj4NClNlbnQ6IFR1
ZXNkYXksIEFwcmlsIDAzLCAyMDE4IDc6NDAgUE08YnI+DQpUbzogVGhlIElFU0cgJmx0OzxhIGhy
ZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPiZndDs8YnI+DQpDYzog
PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRv
cG9sb2d5QGlldGYub3JnIj5kcmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29yay10
b3BvbG9neUBpZXRmLm9yZzwvYT47IFN1c2FuIEhhcmVzICZsdDs8YSBocmVmPSJtYWlsdG86c2hh
cmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpp
MnJzLWNoYWlyc0BpZXRmLm9yZyI+aTJycy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt
YWlsdG86c2hhcmVzQG5kemguY29tIj4NCnNoYXJlc0BuZHpoLmNvbTwvYT47IDxhIGhyZWY9Im1h
aWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IElnbmFz
IEJhZ2RvbmFzJyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3
b3JrLXRvcG9sb2d5LTA4OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij5JZ25hcyBCYWdkb25hcyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n
IGJhbGxvdCBwb3NpdGlvbiBmb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPmRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1uZXR3b3JrLXRvcG9sb2d5LTA4OiBE
aXNjdXNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldoZW4gcmVzcG9uZGluZywgcGxl
YXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBh
ZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBj
dXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij5QbGVhc2UgcmVmZXIgdG8gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z
dGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k
b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0
YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBE
SVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgZG9j
dW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhl
cmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJy
aWMtbmV0d29yay10b3BvbG9neS8iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt
ZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p
ZXRmLWkycnMteWFuZy1kYy1mYWJyaWMtbmV0d29yay10b3BvbG9neS88L3NwYW4+PC9hPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+RElTQ1VTUzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBoYXZlIGNvbmNlcm5zIGFi
b3V0IHRoZSBwcmFjdGljYWwgdXNhYmlsaXR5IG9mIHRoaXMgcHJvcG9zZWQgbW9kZWwgYXMgaXQg
aXMgc3BlY2lmaWVkIG5vdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGludGVu
ZGVkIGRlY291cGxpbmcgb2YgZmFicmljIGltcGxlbWVudGF0aW9uIHByb3BlcnRpZXMgKHdoYXQg
aXMgdGVybWVkIGFzICZxdW90O3VuZGVybGF5IG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUmcXVvdDsg
aW4gdGhlIGRvY3VtZW50KSBhbmQgaXRzIHRvcG9sb2d5IHNlZW1zIHRvIGJlIGNvbnRyYWRpY3Rp
bmcgdG8gZ2VuZXJhbCBvcGVyYXRpb25hbCBwcmFjdGljZXMgb2YgZmFicmljIGJhc2VkIG5ldHdv
cmtzLiBJdA0KIGlzIGdlbmVyYWxseSB0cnVlIGZvciB0aGUgY29udGV4dCBvZiB0aGUgb3Zlcmxh
eSBidXQgdGhhdCBpcyBub3Qgd2hhdCB0aGUgZG9jdW1lbnQgc2VlbXMgdG8gYmUgZm9jdXNpbmcg
b24uIEZhYnJpYyBkZWZpbmVzIGFuZCBpbXBsZW1lbnRzIHRoZSB1bmRlcmxheSwgbm90IHRoZSBv
dGhlciB3YXkgYXJvdW5kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+W1ldIFRoZSBpbnRlbnRpb24gb2YgdGhpcyBtb2RlbCBp
cyB0byByZXByZXNlbnQgdGhlIGVudGlyZSB0b3BvbG9neSBvZiBhIGRhdGEgY2VudGVyIGZhYnJp
YyBuZXR3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl
cmlmIj48YnI+DQpZYW4sIGNhbiB5b3UgYmUgc3BlY2lmaWMgaGVyZSAtIHRoZSB0b3BvbG9neSBv
ZiB3aGF0PyBBcmUgd2UgdGFsa2luZyBhYm91dCB0aGUgdW5kZXJsYXkgdG9wb2xvZ3ksIG9yIGFu
IG92ZXJsYXkgaW5zdGFuY2UgdG9wb2xvZ3k/IFRoYXQgaXMgYSBtYWpvciBkaWZmZXJlbmNlIGFu
ZCBtYW55IG90aGVyIGNvbW1lbnRzIHdpbGwgZGVwZW5kIG9uIHRoaXMgYW5zd2VyLiBUaGUgdGVy
bWlub2xvZ3kgZG9lcyBub3QgaGVscCBoZXJlIHRvbyBtdWNoIC0gZGF0YQ0KIGNlbnRlciBmYWJy
aWMgbmV0d29yayBtYXkgbWVhbiBtYW55IGRpZmZlcmVudCB0aGluZ3MgaWYgdmlld2VkIGZyb20g
ZGlmZmVyZW50IGNvbnRleHRzLg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0
OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss
c2VyaWY7Y29sb3I6IzFGNDk3RCI+W1ldIFdlIHByb3ZpZGUgYW4gZW50aXJlIHRvcG9sb2d5IGZv
ciBhIGRjIGZhYnJpYy4gVGhpcyBmYWJyaWMgY29udGFpbnMgc2V2ZXJhbCBQT0RzIGFzIGl0cyDi
gJxub2Rl4oCdLCBlYWNoIG9mIHdoaWNoIGlzIGNvbXBvc2VkDQogb2YgYSBzZXQgb2YgdW5kZXJs
YXkgbm9kZXMgKHdoaWNoIGFyZSBkZXZpY2Ugbm9kZXMpIGFuZCB0aGVpciBpbnRlcmNvbm5lY3Rp
b24gbGlua3MsIGFuZCBtYXkgaW1wbGVtZW50IGRpZmZlcmVudCBvdmVybGF5cy4gVGhlIGxpbmtz
IG9mIHRoaXMgZmFicmljIGNhbiBiZSBjb25uZWN0aW9ucyBiZXR3ZWVuIFBPRHMsIGludGVyY29u
bmVjdGlvbnMgd2l0aGluIGEgUE9EIG9yIGNvbm5lY3Rpb25zIHRvIFdBTnMuPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h
biZxdW90OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5UaGUgd2hvbGUgbmV0d29yayBjYW4gYmUg
Y29uc2lkZXJlZCBhcyBhIHNpbmdsZSBmYWJyaWMgbmV0d29yayB3aGljaCBpcyBjb21wb3NlZCBi
eSBzZXZlcmFsIFBPRHMgZGVmaW5lZCBhcyDigJxub2Rl4oCdIGluIHRoaXMgbW9kdWxlLiBVbmRl
ciB0aGVzZSDigJxub2Rlc+KAnSwgdGhlcmUgYXJlIHN1cHBvcnRpbmctbm9kZXMgKHJlZmVyZW5j
ZSB0byBkZXZpY2Utbm9kZXMgYmVsb25nZWQNCiB0byB0aGUgUE9EKSBhbmQgY29ubmVjdGlvbnMu
IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0
eWxlPSJjb2xvcjpyZWQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90
ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+VGhl
IHRlcm0gb2YgUE9EL2ZhYnJpYyBpcyBhIGJpdCBjb25mdXNpbmcgaW4gdGhlIGRyYWZ0LiBIb3cg
YWJvdXQgd2UgdXBkYXRpbmcgdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24gYXMgYmVsb3c/PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOnJlZCI+UE9EOiBhIG1vZHVsZSBvZiBuZXR3b3JrLCBjb21wdXRlLCBzdG9yYWdlLCBhbmQg
YXBwbGljYXRpb24gY29tcG9uZW50cyB0aGF0IHdvcmsgdG9nZXRoZXIgdG8gZGVsaXZlciBuZXR3
b3JraW5nIHNlcnZpY2VzLiBJdCByZXByZXNlbnRzIGEgcmVwZWF0YWJsZSBkZXNpZ24gcGF0dGVy
bi4gSXRzIGNvbXBvbmVudHMgbWF4aW1pemUgdGhlIG1vZHVsYXJpdHksIHNjYWxhYmlsaXR5LA0K
IGFuZCBtYW5hZ2VhYmlsaXR5IG9mIGRhdGEgY2VudGVycy48L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5GYWJyaWM6
IGNvbXBvc2VkIG9mIHNldmVyYWwgUE9EcyB0byBmb3JtIGEgZGF0YSBjZW50ZXIgbmV0d29yay48
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls
ZT0iY29sb3I6cmVkIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5Eb2VzIGl0IG1ha2Ugc2Vuc2U/PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SXQgaXMgY2xvc2VyIHRvIGJv
dGggdGhlIHRlcm1pbm9sb2d5IGFuZCBkZXNpZ24gdXNlZCBpbiBhY3R1YWwgZGVwbG95bWVudHMu
DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPltZXSBUaGFu
a3MuIFdlIHdpbGwgYWRkIHRoZXNlIHRvIHRoZSB0ZXJtaW5vbG9neSBwYXJ0Ljwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t
YW4mcXVvdDssc2VyaWYiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGRvY3VtZW50IGRvZXMgbm90IGNvbnRhaW4gYSBzdWZm
aWNpZW50IGRlc2NyaXB0aW9uIG9mIHRoZSBsb2dpYyBvZiB0aGUgbW9kZWwgaXRzZWxmLCB0aGUg
cmVhc29ucyBmb3IgY2hvaWNlcyBtYWRlIGZvciByZXByZXNlbnRhdGlvbiBvZiB0eXBlcyBhbmQg
YXR0cmlidXRlcywgYW5kIGF0IHRoZSBzYW1lIHRpbWUgZGVzY3JpcHRpb25zIGluIG1vZHVsZXMg
YXJlIHNpbmdsZSBsaW5lcyB0aGF0IGRvIG5vdA0KIGFkZCBjbGFyaWZpY2F0aW9uIGJleW9uZCBi
ZWluZyBjb3BpZXMgb2YgbGVhZiBuYW1lcy4gRWl0aGVyIHRoZXJlIG5lZWRzIHRvIGJlIGEgc2Vj
dGlvbiB0aGF0IGRlc2NyaWJlcyB0aGUgbG9naWMgb2YgdGhlIG1vZGVsIGFuZCBob3cgaXQgcmVs
YXRlcyB0byBvdGhlciBtb2RlbHMsIGFsc28gaW5jbHVkaW5nIGV4YW1wbGVzLCBvciBtb2R1bGUg
ZGVzY3JpcHRpb24gZmllbGRzIG5lZWQgdG8gaGF2ZSBlbm91Z2ggY29udGVudCB0byBiZSBhYmxl
IHRvDQogaGF2ZSBlcXVpdmFsZW50IHVuZGVyc3RhbmRpbmcgb2YgbW9kZWwgaW50ZW50IGFuZCBv
cGVyYXRpb24uIEJvdGggYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQsIGFzIGRlc2NyaXB0aW9ucyBo
YXZlIHZhbHVlIG9mIGl0c2VsZiBmb3IgYmVpbmcgYSByZWZlcmVuY2UgZm9yIHVzZSwgYW5kIG1v
ZGVsIGRlc2NyaXB0aW9uIGlzIG5lZWRlZCBmb3IgdW5kZXJzdGFuZGluZyBob3cgdGhpcyBwYXJ0
aWN1bGFyIG1vZGVsIGZpdHMgaW50byB0aGUgbGFyZ2VyDQogaGllcmFyY2h5LiBOZXR3b3JrIG1h
bmFnZW1lbnQgZG9lcyBub3QgZW5kIGF0IHRoZSBib3VuZGFyeSBvZiB0aGUgc2luZ2xlIGRvbWFp
bi1zcGVjaWZpYyBtb2RlbCwgaXQgaXMgaW1wb3J0YW50IHRvIGJ1aWxkIGl0IGludG8gYSB3aG9s
ZSBzeXN0ZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldoeSBURSB0b3BvbG9neSBt
b2RlbCBpcyBub3Qgc3VmZmljaWVudCBmb3IgbW9kZWxsaW5nIHRoZSByZXByZXNlbnRhdGlvbiBv
ZiBEQyBmYWJyaWM/IFdoeSBpcyBEQyBmYWJyaWMgbmV0d29yayB0b3BvbG9neSBzcGVjaWFsIGNv
bXBhcmVkIHRvIGFueSBnZW5lcmljIGZhYnJpYyBiYXNlZCB0b3BvbG9neT88bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPltZXSBX
ZSBkaXNjdXNzZWQgd2l0aCBURSB0b3BvbG9neSBtb2RlbCBhdXRob3JzIGFib3V0IHRoaXMgcXVl
c3Rpb24uIEZvciBURSwgaXQgaXMgbW9yZSBmb2N1c2VkIG9uIGNvbm5lY3Rpb25zIGZvciBURSBh
bmQgc3RhdGljcyBmb3IgdGhlaXIgcGVyZm9ybWFuY2UsIHdoaWxlIHRoaXMgbW9kZWwgaXMgdG8g
cHJlc2VudCBob3cgYSBkYXRhIGNlbnRlciBuZXR3b3JrDQogbG9vayBsaWtlIHdpdGggaXRzIHNw
ZWNpZmljIG5vZGVzKGxlYWYvc3BpbmUpLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l
dyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KTGVhZi9zcGluZSBpcyBhIG5vZGUsIG5vZGVzIGFy
ZSBpbnRlcmNvbm5lY3RlZCBieSBsaW5rcy4gRGVwZW5kcyBvbiB0aGUgY29udGV4dCBvZiB0aGUg
ZWFybGllciBxdWVzdGlvbiBhYm91dCB0aGUgdW5kZXJsYXkgYW5kIG92ZXJsYXkuIExpbmtzIGFu
ZCBub2RlcyBjYW4gZGVmaW5pdGVseSBiZSByZXByZXNlbnRlZCBieSBURSBtb2RlbC4gV2hhdCBp
cyBhIGxlYWYvc3BpbmUgbm9kZSBpbiB0aGUgb3ZlcmxheSBjb250ZXh0Pw0KPGJyPg0KPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l
dyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEIj5bWV0gTGVhZi9zcGluZSBpcyB0aGUg
cm9sZSBvZiBhIGRldmljZSBub2RlIHdpdGhpbiBhIHBvZC4gSXQgaW5kaWNhdGVzIGl0cyBmdW5j
dGlvbnMuIFN1Y2ggYXMsIGZvciBkaXN0cmlidXRlZCBHVywgaXQgd2lsbCBiZSBkZXBsb3llZCBv
biBMRUFGIG5vZGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPkhvdyB0aGlzIG1vZGVsIGNvdWxkIGJlIHVzZWQgZm9yIHJl
cHJlc2VudGluZyBtb3JlIHRoYW4gdHdvIHN0YWdlIGZhYnJpY3MgdGhhdCBhcmUgaW4gd2lkZSBk
ZXBsb3ltZW50PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
c3R5bGU9ImNvbG9yOnJlZCI+W1ldIEluIHRoYXQgY2FzZSwgbW9yZSByb2xlcyBmb3IgaW50ZXJs
YXllciBkZXZpY2VzIGNhbiBiZSBhZGRlZC4gVGhlIOKAnHJvbGXigJ0gZm9yIGRldmljZSBpcyBk
ZWZpbmVkIGFzIGlkZW50aXR5LXJlZi4gTmV3IHJvbGVzIGNhbiBiZSBhZGRlZCBieSBkZWZpbmlu
ZyBuZXcgaWRlbnRpdGllcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx
dW90OyxzZXJpZiI+VGhpcyBuZWVkcyB0byBiZSBkb2N1bWVudGVkLiBPciwgaWYgeW91IGludGVu
ZCB0byBsaW1pdCB0aGUgc2NvcGUgdG8gdHdvIHN0YWdlcyAoYXMgaXQgaXMgaW1wbGllZCBhdCB0
aGUgbW9tZW50KSAtIHRoaXMgYWxzbyBuZWVkcyB0byBiZSBleHBsaWNpdGx5DQogc3RhdGVkIGlu
IHRoZSBkb2N1bWVudC4gV2hhdCBpcyBhbiBpbnRlcmxheWVyIGRldmljZT8gPGJyPg0KPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l
dyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEIj5bWV0gT2ssIGl0IHdpbGwgYmUgYWRk
ZWQgdG8gdGhlIGRlZmluaXRpb24gb2Ygcm9sZS4gRXJy4oCmYW4gaW50ZXJsYXllciBkZXZpY2Ug
aXMgZm9yIG90aGVyIGxheWVycyBiZXNpZGVzIFNQSU5FL0xFQUYuPC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkxpbWl0aW5n
IHBvcnQgYmFuZHdpZHRoIHRvIGEgZml4ZWQgcmF0ZSBpcyB0b28gcmVzdHJpY3RpdmUuIFRoZSBt
b2RlbCBhcyBzcGVjaWZpZWQgYWxyZWFkeSBkb2VzIG5vdCBjb3ZlciBhIHNldCBvZiBwb3J0IHNw
ZWVkcyB0aGF0IGFyZSBpbiBkZXBsb3ltZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+W1ldIGJhbmR3aWR0aCBpcyBkZWZp
bmVkIGFzIGlkZW50aXR5LXJlZi4gT3RoZXIgc3BlZWRzIGNhbiBiZSBhZGRlZCBieSBkZWZpbmlu
ZyBuZXcgaWRlbnRpdGllcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm
Ij5OZWVkcyB0byBiZSBkb2N1bWVudGVkLjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7
Y29sb3I6IzFGNDk3RCI+W1ldIE9rLCBpdCB3aWxsIGJlIGFkZGVkIHRvIHRoZSBkZWZpbml0aW9u
IG9mIGJhbmR3aWR0aC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQo8YnI+DQo8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhvdyB3b3VsZCBh
IGRldmljZSB0aGF0IGhhcyBtb3JlIHRoYW4gYSBzaW5nbGUgcm9sZSBpbiB0aGUgZmFicmljIGJl
IHJlcHJlc2VudGVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gc3R5bGU9ImNvbG9yOnJlZCI+W1ldIFRoZSByb2xlIGZvciBhIGRldmljZS1ub2RlIGlzIGRl
ZmluZWQgYXMgbGVhZi1saXN0IHRvIHN1cHBvcnQgYSBkZXZpY2Ugd2l0aCBtb3JlIHRoYW4gb25l
IHJvbGVzLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPlNlcnZpY2UgY2FwYWJpbGl0aWVzIGFzIHRoZXkgYXJlIGRlc2NyaWJlZCBiZWxvbmcg
dG8gdGhlIG92ZXJsYXkgY29udGV4dCB3aGlsZSB0aGV5IGFyZSBjYWxsZWQgZGV2aWNlIGNhcGFi
aWxpdGllcy4gQXJlIHRob3NlIHRoZSBvbmx5IHBvc3NpYmxlIHNlcnZpY2UgY2FwYWJpbGl0aWVz
PyBXaGF0IGlzIHRoZSBlZmZlY3Qgb2YgY29uZmlndXJpbmcgdGhvc2UgY2FwYWJpbGl0aWVzPzxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y
OnJlZCI+W1ldIFNlcnZpY2UgY2FwYWJpbGl0aWVzIGlzIGZvciBhIGZhYnJpYyBub3QgYSBkZXZp
Y2UuIFRoZSBkZXNjcmlwdGlvbiBmb3IgdGhlIHNlcnZpY2UgY2FwYWJpbGl0aWVzIHdpbGwgYmUg
Y29ycmVjdGVkLiBGb3IgYmV0dGVyIGV4dGVuc2lvbiBmb3Igb3RoZXIgc2VydmljZXMsIHdlIHdp
bGwgY2hhbmdlIGN1cnJlbnQgZW51bWVyYXRpb24gdHlwZSB0byBpZGVudGl0eS1yZWYuDQogTW9y
ZSBzZXJ2aWNlIGlkZW50aXRpZXMgY2FuIGJlIGRlZmluZWQgaW4gdGhlIGZ1dHVyZSBieSB2ZW5k
b3JzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5U
aGUgZXh0ZW5zaWJpbGl0eSBtZWNoYW5pc20gbmVlZHMgdG8gYmUgZG9jdW1lbnRlZC4NCjxicj4N
Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU
aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1ldIE9rLCBpdCB3aWxs
IGJlIGFkZGVkIHRvIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBzZXJ2aWNlIGNhcGFiaWxpdHkuDQo8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt
ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+V2hhdCBpcyBjb21wb3NlLWZhYnJpYyBSUEM/IFRoZSBkb2N1bWVudCBkb2VzIG5v
dCBkZWZpbmUgYW55IFJQQ3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bWV0gcnBjcyB3ZXJlIHJlbW92ZWQgaW4gcHJldmlv
dXMgdmVyc2lvbiBzaW5jZSBwZW9wbGUgc2F5IGl0IHdvdWxkIGxlYXZlIGZvciB2ZW5kb3Itc3Bl
Y2lmaWMgaW1wbGVtZW50YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+VGhlIHJwY3MgdG8gY29tcG9zZSBh
IGZhYnJpYyBpcyBhczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsgcnBjIGNvbXBv
c2UtZmFicmljIHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgaW5wdXQgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1c2VzIGZhYnJpYy1h
dHRyaWJ1dGVzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IG91dHB1dCB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgZmFicmlj
LWlkIHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlw
ZSBmYWJyaWMtaWQ7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0LWluZGVudDo5LjBwdCI+
PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0LWluZGVudDo5LjBwdCI+PHNwYW4gc3R5bGU9ImNv
bG9yOnJlZCI+VG8gYWRkIGEgbm9kZSB0byBmYWJyaWM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9InRleHQtaW5kZW50OjkuMHB0Ij48c3BhbiBz
dHlsZT0iY29sb3I6cmVkIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0IiBzdHlsZT0idGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJjb2xv
cjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyBycGMgYWRkLW5vZGUtdG8tZmFicmljIHs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0idGV4dC1pbmRl
bnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBpbnB1dCB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9InRleHQtaW5kZW50OjkuMHB0Ij48c3BhbiBzdHlsZT0i
Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBmYWJyaWMtaWQgezwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0LWluZGVudDo5LjBwdCI+PHNw
YW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5
cGUgZmFicmljLWlkOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiIHN0eWxlPSJ0ZXh0LWluZGVudDo5LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz
dHlsZT0idGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB1c2VzIGRldmljZS1hdHRyaWJ1dGVzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiIHN0eWxlPSJ0ZXh0LWluZGVudDo5LjBwdCI+PHNwYW4gc3R5bGU9ImNv
bG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0idGV4dC1p
bmRlbnQ6OS4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyB9
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5
bGU9ImNvbG9yOnJlZCI+RG8geW91IHN1Z2dlc3Qgd2UgYnJpbmcgaXQgYmFjayB0byB0aGUgZHJh
ZnQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt
ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5JIGFtIG5vdCBzdWdnZXN0aW5nIGFueXRoaW5nLCBJ
IHdhcyBhc2tpbmcgYWJvdXQgdGhlIGNvbXBvc2UtZmFicmljIFJQQyB0aGF0IHdhcyBtZW50aW9u
ZWQgaW4gdGhlIGRvY3VtZW50Lg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0
OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6IzFGNDk3RCI+W1ldIFdlIHdpbGwgY2xhcmlmeSBpdCBpbiB2LTA5LjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2hhdCBpcyBwb2xpY3kgZHJpdmVuIHRyYWZmaWMg
YmVoYXZpb3I/IElzIHRoZXJlIHRoZSBvbmx5IG9uZSBwb2xpY3kgdGhhdCBmaXRzIGFsbCBwb3Nz
aWJsZSBkZXBsb3ltZW50IHNjZW5hcmlvcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPltZXSBQb2xpY3kgaXMgbmVlZGVkIGZv
ciB0aGUgdHJhZmZpYyBvdGhlcndpc2UgdGhlIHRyYWZmaWMgd2lsbCBiZSBkaXNjYXJkLiBUaGVy
ZSBjYW4gYWxzbyBiZSBub3JtYWwsIHdoaWNoIG1lYW5zIG5vIHBvbGljeSBpcyBuZWVkZWQgZm9y
IGFsbCB0cmFmZmljLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+
SXQgbmVlZHMgdG8gYmUgZG9jdW1lbnRlZCBvbiB3aGF0IGlzIG1lYW50IGJ5IHBvbGljeSAtIHdo
YXQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhhdCBwb2xpY3ksIHdoZXJlIGFuZCBob3cgaXQgc2hvdWxk
IGJlIGluc3RhbnRpYXRlZC4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6
IzFGNDk3RCI+W1ldSXQgd2lsbCBiZSBjbGFyaWZpZWQgaW4gdi0wOS48L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1
b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPkxvb2tpbmcgYXQgdGhlIGhpc3Rvcnkgb2YgdGhlIGRvY3VtZW50IGZyb20gdGhlIGluZGl2
aWR1YWwgc3VibWlzc2lvbiB0aW1lIGFuZCB0aGUgY29tbWVudHMgcmVjZWl2ZWQsIGl0IHNlZW1z
IHRoYXQgdGhlIHBvaW50IGZpeGVzIHRvIHRoZSB0ZXh0IHdlbnQgaW4gdG8gY292ZXIgdGhlIHNw
ZWNpZmljIGNvbW1lbnRzIGJ1dCBub3QgdG8gYWRkcmVzcyB0aGUgYnJvYWRlciBzY29wZSBvZiBj
b21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBkb2N1
bWVudCB3b3VsZCBkZWZpbml0ZWx5IGJlbmVmaXQgZnJvbSBhIG1ham9yIHJld3JpdGUgY2xhcmlm
eWluZyB0aGUgbG9naWMgYmVoaW5kIHRoZSBkZWNpc2lvbnMgbWFkZSwgYWxpZ25pbmcgbW9yZSB3
aXRoIHRoZSBvcGVyYXRpb25hbCBwcmFjdGljZSBvZiBmYWJyaWMgYmFzZWQgbmV0d29yayBkZXNp
Z24gYW5kIGRlcGxveW1lbnQsIGFuZCBicmluZ2luZyB0aGUgY29udGVudCBpbiBZQU5HIG1vZHVs
ZXMNCiB0byBiZSBzZWxmLWRlc2NyaWJpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q09NTUVOVDo8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RmFicmljIGFuZCBQT0QgYXJlIG5vdCBlcXVpdmFsZW50
IHRlcm1zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JMlJTIHVzZSBjYXNlIHJlcXVp
cmVtZW50cyBkb2N1bWVudCBoYXMgZXhwaXJlZCAxMSBtb250aHMgYWdvLiBVc2UgY2FzZXMgZG9j
dW1lbnRzIGFyZSBnb29kIGZvciB0cmFja2luZyB0aGUgd29yayBwcm9ncmVzcyBvZiBzcGVjaWZp
Y2F0aW9uIGRvY3VtZW50cywgaXQgaXMgcXVlc3Rpb25hYmxlIHdoZXRoZXIgc3RhbmRhbG9uZSB1
c2UgY2FzZXMgZG9jdW1lbnRzIHByb3ZpZGUgdmFsdWUgYmV5b25kIGhpc3RvcmljDQogcmVjb3Jk
LiBJcyB0aGUgcmVmZXJlbmNlIHRvIEkyUlMgdXNlIGNhc2VzIGRvY3VtZW50IHJlYWxseSBuZWVk
ZWQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i
Y29sb3I6cmVkIj5bWV0gVGhlIHJlZmVyZW5jZSB3aWxsIGJlIHJlbW92ZWQgaW4gdjA5Ljwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2hhdCBpcyBhdG9taWMgbmV0d29yaz88
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv
cjpyZWQiPltZXSBUaGUgb3JpZ2luYWwgc2VudGVuY2UgbWlnaHQgYmUgY29uZnVzaW5nLiBIb3cg
YWJvdXQgd2UgY2hhbmdpbmcgaXQgdG8g4oCcYSBQT0QgY2FuIGJlIGNvbnNpZGVyZWQgYXMgYSBi
YXNpYyBzdHJ1Y3R1cmUgZm9yIG1hbmFnZW1lbnQgcHVycG9zZXMu4oCdPzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206
MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU
aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPldoYXQgaXMgYSBiYXNpYyBzdHJ1Y3R1cmUgdGhl
bj8gSWYgdGhpcyBpcyBpbiBvdmVybGF5IGNvbnRleHQgdGhlbiBpdCBpcyBub3Qgb2J2aW91cyB3
aGF0IFBPRCBtZWFucyB0aGVyZS4gSWYgdGhpcyBpcyBpbiB1bmRlcmxheSBjb250ZXh0IHRoZW4N
CiBjb25jZXB0dWFsbHkgaXQgaXMgY2xlYXIgYnV0IHF1aXRlIGZhciBhd2F5IGZyb20gb3BlcmF0
aW9uYWwgcmVhbGl0eS4gPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMUY0
OTdEIj5bWV0gSXQgaXMgYSBzZXQgb2Ygbm9kZXMgYW5kIGxpbmtzIHdoaWNoIGNvbXBvc2VzIGEg
UE9EIGFuZCBhbHNvIHN1cHBvcnRzIGFuIG92ZXJsYXkgaW5zdGFuY2UuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5WTEFOIGlzIG5vdCBhIGZhYnJpYyBi
dWlsZGluZyB0ZWNobm9sb2d5IGFzIHN1Y2gsIHdoaWxlIEV0aGVybmV0IGlzLjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij5XaGF0IGlzIHRoZSBuZWVkIGZvciBWTkkgY2FwYWNpdHkgbGVh
dmVzPyBXaGF0IGlzIHRoZWlyIGVmZmVjdCBpZiBjb25maWd1cmVkPzxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+W1ldIEl0IGlz
IHVzZWQgdG8gc2F5IHRoZSByYW5nZSBvZiB0aGUgVk5JcyBmb3IgYSBQT0QuIFdlIHdpbGwgdXBk
YXRlIHRoZSBkZXNjcmlwdGlvbiB0byBjbGFyaWZ5IGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1
b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgZG9jdW1lbnQgaW50ZXJtaXhlcyBp
ZXRmLWZhYnJpYy0qIGFuZCBpZXRmLWRjLWZhYnJpYy0qIG5hbWVzcGFjZXMuPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bWV0g
QXBvbG9naXplIGZvciB0aGUgaW5jb25zaXN0ZW50LiBJdCB3aWxsIGJlIGNoYW5nZWQgdG8gaWV0
Zi1kYy1mYWJyaWMtKiBpbiB2MDkuPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv
dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VyaWFsIHBvcnQtdHlwZSBpcyBwcmVzZW50IHdoaWxlIElu
ZmluaWJhbmQgaXMgbm90IC0gSW5maW5pYmFuZCBiYXNlZCBmYWJyaWNzIGFyZSB3aWRlbHkgZGVw
bG95ZWQuIFdoYXQgaXMgdGhlIGV4dGVuc2liaWxpdHkgbWVjaGFuaXNtIGZvciBhZGRpbmcgaW4g
bmV3IHBvcnQgdHlwZXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bWV0gU2luY2UgdGhlIHBvcnQtdHlwZSBpcyBpZGVudGl0
eXJlZiwgbmV3IHBvcnQgdHlwZXMgY2FuIGJlIGFkZGVkIGJ5IGRlZmluaW5nIG5ldyBpZGVudGl0
aWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Q
bGVhc2UgZG9jdW1lbnQgdGhlIGV4dGVuc2liaWxpdHkuDQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1
b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPltZXSBPaywgd2Ugd2lsbCBkb2N1bWVudCBpdCBpbiB0
aGUgZGVmaW5pdGlvbiBvZiBwb3J0LXR5cGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklzIHRoZXJlIGFueSBkZXBsb3lt
ZW50IGV4cGVyaWVuY2Ugd2l0aCB0aGlzIG1vZGVsPyBUaGUgT0RMIGZhYXMgcHJvamVjdCBoYXNu
J3QgZ290IG11Y2ggYWN0aXZpdHkgb3ZlciBsYXN0IHR3byB5ZWFycy4gQXJlIHlvdSBhd2FyZSBv
ZiBhbnkgb3RoZXIgaW1wbGVtZW50YXRpb25zIG9yIGRlcGxveW1lbnRzPzxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+W1ldIFll
cywgdGhlIGltcGxlbWVudGF0aW9uIGlzIGluIE9ETCBGQUFTLiBDdXJyZW50IG1vZHVsZSBpcyBh
IHBhcnQgb2YgZmFzcyBwcm9qZWN0LiBJdCBoYXMgYmVlbiBkb25lIG92ZXIgdHdvIHllYXJzIGFu
ZCBvbmx5IG1haW50ZW5hbmNlIGlzIG5lZWRlZC4gQW5kIHdlIHRoaW5rIGl0IGlzIHN0YWJsZS4N
Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+
DQpHb29kLiBTbyB0aGlzIGluIGZhY3QgaXMgY2xvc2VyIHRvIEZBQVMgYW5kIHRoZXJlZm9yZSB0
aGUgY29udGV4dCBvZiB0aGUgZG9jdW1lbnQgaXMgdGhlIG92ZXJsYXkuIFRoZSBkb2N1bWVudCBu
ZWVkcyB0byBzdGF0ZSB0aGF0IGNsZWFybHkuDQo8YnI+DQo8YnI+DQpPdmVyYWxsIGl0IHNlZW1z
IHRoYXQgd2hhdCBpcyBtaXNzaW5nIGluIHRoZSBkb2N1bWVudCBpcyB0aGUgY29udGV4dCBjbGFy
aWZpY2F0aW9uLiBPbmNlIHRoZSBjb250ZXh0IG9mIHRoaXMgbW9kZWwgaXMgY2xlYXJseSBkZWZp
bmVkIHRoZSByZXN0IG9mIGNvbW1lbnRzIHdpbGwgYmUgZWFzaWVyIHRvIGFkZHJlc3MuPGJyPg0K
PGJyPg0KVGhhbmsgeW91Ljxicj4NCjxicj4NCklnbmFzPGJyPg0KJm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96BEA45nkgeml513mbschi_--


From nobody Wed Apr 18 09:18:21 2018
Return-Path: 
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032AC127869 for ; Wed, 18 Apr 2018 09:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.845
X-Spam-Level: **
X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] 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 6oSYB-Bu85aZ for ; Wed, 18 Apr 2018 09:18:18 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 981081275AB for ; Wed, 18 Apr 2018 09:18:18 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.120.167; 
From: "Susan Hares" 
To: 
Cc: "'Mach Chen'" , "'Amit Dass'" 
Date: Wed, 18 Apr 2018 12:18:08 -0400
Message-ID: <01cd01d3d730$d76d4160$8647c420$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CE_01D3D70F.505C1690"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdPXMMj/xC3TISIpSHyL2CddDBN4Cw==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: [i2rs] Advice requested -  Regarding I2RS Rib YANG model
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Apr 2018 16:18:20 -0000

This is a multipart message in MIME format.

------=_NextPart_000_01CE_01D3D70F.505C1690
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Greetings: 

 

The I2RS WG chair would like some advice.  

 

Is there ever a case when doing label swap you would ever want to decrease
the TTL at the same time?  Our initial I2RS RIB
(draft-ietf-i2rs-rib-data-model-10) had added this 3 years ago due to
comments.  However, we are question now whether this is valid. 

 

Thank you, Susan Hares 

Co-chair I2RS WG

 


------=_NextPart_000_01CE_01D3D70F.505C1690
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Greetings: =

 
The I2RS WG chair would like some advice. =
 
 
Is there ever a case when doing label swap you would =
ever want to decrease the TTL at the same time?  Our initial I2RS =
RIB (draft-ietf-i2rs-rib-data-model-10) had added this 3 years =
ago due to comments.  However, we are question now whether this is =
valid. 
 
Thank you, =
Susan Hares 
Co-chair =
I2RS WG
 

------=_NextPart_000_01CE_01D3D70F.505C1690--


From nobody Sat Apr 21 01:00:21 2018
Return-Path: 
X-Original-To: i2rs@ietf.org
Delivered-To: i2rs@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D32C2129C5D; Sat, 21 Apr 2018 01:00:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: i2rs@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152429761482.20652.14179667131277249091@ietfa.amsl.com>
Date: Sat, 21 Apr 2018 01:00:14 -0700
Archived-At: 
Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-11.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Apr 2018 08:00:15 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to the Routing System WG of the IETF.

        Title           : A YANG Data Model for Routing Information Base (RIB)
        Authors         : Lixing Wang
                          Mach(Guoyi) Chen
                          Amit Dass
                          Hariharan Ananthakrishnan
                          Sriganesh Kini
                          Nitin Bahadur
	Filename        : draft-ietf-i2rs-rib-data-model-11.txt
	Pages           : 69
	Date            : 2018-04-21

Abstract:
   This document defines a YANG data model for Routing Information Base
   (RIB) that aligns with the I2RS RIB information model.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-11
https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-rib-data-model-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-data-model-11


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 Sat Apr 21 01:24:45 2018
Return-Path: 
X-Original-To: i2rs@ietf.org
Delivered-To: i2rs@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D6E120721; Sat, 21 Apr 2018 01:24:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: i2rs@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152429908417.20532.12973932099586376104@ietfa.amsl.com>
Date: Sat, 21 Apr 2018 01:24:44 -0700
Archived-At: 
Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-12.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Apr 2018 08:24:44 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to the Routing System WG of the IETF.

        Title           : A YANG Data Model for Routing Information Base (RIB)
        Authors         : Lixing Wang
                          Mach(Guoyi) Chen
                          Amit Dass
                          Hariharan Ananthakrishnan
                          Sriganesh Kini
                          Nitin Bahadur
	Filename        : draft-ietf-i2rs-rib-data-model-12.txt
	Pages           : 69
	Date            : 2018-04-21

Abstract:
   This document defines a YANG data model for the Routing Information
   Base (RIB) that aligns with the I2RS RIB information model.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-12
https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-rib-data-model-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-data-model-12


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 Sat Apr 21 01:36:04 2018
Return-Path: 
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33174126C89; Sat, 21 Apr 2018 01:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAch-BTwq-5R; Sat, 21 Apr 2018 01:36:00 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 F027D126DC2; Sat, 21 Apr 2018 01:35:59 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6A2824FE10207; Sat, 21 Apr 2018 09:35:56 +0100 (IST)
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 21 Apr 2018 09:35:57 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.73]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0361.001; Sat, 21 Apr 2018 16:35:53 +0800
From: Mach Chen 
To: IESG 
CC: "i2rs@ietf.org" , "draft-ietf-i2rs-rib-data-model@ietf.org" , "i2rs-chairs@ietf.org" , "rtg-ads@ietf.org" , t.petch , Benoit Claise 
Thread-Topic: IESG comments resolved//FW: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-12.txt
Thread-Index: AdPZSq5GHSEWzp8TThq5U/mbHvOwfw==
Date: Sat, 21 Apr 2018 08:35:52 +0000
Message-ID: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.194.201]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [i2rs] IESG comments resolved//FW: I-D Action: draft-ietf-i2rs-rib-data-model-12.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Apr 2018 08:36:02 -0000

Hi,=20

Most of the IESG comments are addressed in version 11, below is the diff fr=
om version 10

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-11

Some nits fixed in version 12, below is the diff from version 11.

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-12

Best regards,
Mach

> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Saturday, April 21, 2018 4:25 PM
> To: i-d-announce@ietf.org
> Cc: i2rs@ietf.org
> Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-data-model-12.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Interface to the Routing System WG of th=
e IETF.
>=20
>         Title           : A YANG Data Model for Routing Information Base =
(RIB)
>         Authors         : Lixing Wang
>                           Mach(Guoyi) Chen
>                           Amit Dass
>                           Hariharan Ananthakrishnan
>                           Sriganesh Kini
>                           Nitin Bahadur
> 	Filename        : draft-ietf-i2rs-rib-data-model-12.txt
> 	Pages           : 69
> 	Date            : 2018-04-21
>=20
> Abstract:
>    This document defines a YANG data model for the Routing Information
>    Base (RIB) that aligns with the I2RS RIB information model.
>=20
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-i2rs-rib-data-model-12
> https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-rib-data-model-12
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-data-model-12
>=20
>=20
> Please note that it may take a couple of minutes from the time of submiss=
ion
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs


From nobody Sun Apr 22 09:24:52 2018
Return-Path: 
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4C6126BFD for ; Sun, 22 Apr 2018 09:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 HEONl_x8meph for ; Sun, 22 Apr 2018 09:24:49 -0700 (PDT)
Received: from sonic303-22.consmr.mail.gq1.yahoo.com (sonic303-22.consmr.mail.gq1.yahoo.com [98.137.64.203]) (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 13BD01241FC for ; Sun, 22 Apr 2018 09:24:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1524414288; bh=Zhd8W9PMUDEKpYCXKHoAxSVdR1rHXAZPTOMMfVZWA1E=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=CV1fdjdTbcs38YfGSJdwp6sQBdn8YGnek+bVlOZG/tuMjHSvzNudZyCEFp9sx+N5Cp1cXK/pEmcPOoifCTfi2+XFe5EoOTPurt3XS9eobMxHNX72h9tWZ7jix9Mt2jR/RKYL95/+Ss4tCOtFcluRgYnrZYvmC3oLCfyWm9jjpeNHuzwBGozylyD3Z4mT3xRnov9Ij17VpSjzGJJMvMz50QDC/I1uDhC1ZulmMTL59VBzkpYI37Vkdsx2pCjqmZdgvuppM2dFl7H7FAzjMy3q7Bg7TXeIsEwsX/nTdfHtIVduc30b8tBt/dFIazR5VRZUNC6Kv0XgTWY2T7mt6czPfQ==
X-YMail-OSG: CpSbqA0VM1mZV.3i.Fh0L1Ke5JkV1mKmX8.UGv1pU1HuS_q5Szy8hCvkABQmFLi sWzcuSA.9qU6dsCytWUPWN3H_K840YW1n1AeA6lmE9MdlAcJTrozAdAJ1xF6OQFCLj6YfXxd_SRP IvJyr8t8QvuqgCLx26hMyT9z7iBv3crzo70eDYAq41YELhbY1W82jTo8nzlD6DcvS8iQ1IHuM6dM VTuncoT3lG1jCXWwkhX6.UXkjiTP4Zm1HGrW.dpovzeD4FzjzonrdWcLsIkpmU0aDIY4uiM99emc foetiNq_MSpEm5rAsU42iSx7PemLN5LzbMBprxs0wykJ6iOhXvQEn9X3mDBowfVWGKwu6fiSs0vQ ETgu1kYu.ZKACqBrCiUSq.WH3vpKbgyeX6kcqhR6VmKr.KP_L.UJynB2Q6P8sp8Pv7SRKF8ygwVl NHtikFoX5pJONuQ3tg4MgtWqP2rWHxuQNspo0D7lwiq.C27qt.go3k7JQVAcn8ADhT9QnBZxFgXH JIIU42XbTQckKSacUA95WWDQZdwUiAlVU_NpYkB.jXhH..g3nObcVwjuHY_kGtawWNxI-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Apr 2018 16:24:48 +0000
Received: from 98.sub-174-215-1.myvzw.com (EHLO [172.20.10.8]) ([174.215.1.98]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ab09bbbe2e0518ac8241ae590d48aa04;  Sun, 22 Apr 2018 16:24:45 +0000 (UTC)
User-Agent: Microsoft-MacOutlook/10.9.0.180116
Date: Sun, 22 Apr 2018 09:24:41 -0700
From: Nitin Bahadur 
To: Ignas Bagdonas , The IESG 
CC: , Susan Hares ,  , 
Message-ID: 
Thread-Topic: Ignas Bagdonas' No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)
References: <152292967776.25948.4861433804412654905.idtracker@ietfa.amsl.com>
In-Reply-To: <152292967776.25948.4861433804412654905.idtracker@ietfa.amsl.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: Re: [i2rs] Ignas Bagdonas' No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Apr 2018 16:24:51 -0000

Hi Ignas,

  Thanks for the review. Please see NB> below for responses.

    A few nits:
    
    Terminology: rib family vs address family. Address family term is more widely
    used in the industry.

NB> You are right. Updating the draft.

 VPLS is a subset of L2VPN.
 
NB> Yes indeed. Given how prevalent VPLS is in the industry now, it was felt necessary to call it out specifically.

    ROUTER_ID usage is orthogonal to router virtualization. MUST restriction for
    the domain is factually incorrect - it is typically per source protocol, not
    per domain.
    
 NB> Source protocols (like OSPF) indeed do have their own router-id. In the context of the RIB model, we are calling out ROUTER_ID as an identifier for a virtual router. It will be used by a RIB client to uniquely ID a routing instance (across multiple network devices).



From nobody Sun Apr 22 10:58:08 2018
Return-Path: 
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FC21241FC for ; Sun, 22 Apr 2018 10:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 ZJgv4mqKrz81 for ; Sun, 22 Apr 2018 10:57:57 -0700 (PDT)
Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (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 CCBAC126C0F for ; Sun, 22 Apr 2018 10:57:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1524419877; bh=6ziUkG5EbQgX2gKNJuaH0ofdlKYuA1gkKOADS6BJK4Q=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=aleuVyepqR81G4rr/v+1Xl7bC317e5q4xPDV4GRZDe213/YYEDqRHV8eKUtxpztamMfgtGRWX9DSg9YRCG1tPFvDl0SmfKeZ3rQUi3Y9iMRXDZBzLDEq8yUqJVsvIIku4WS0MCUNkLdO5raifMRJJAmxILbVhTd7nmVryOjGMj8o68fcNlpsPBog6mee1xlIC4Y2H/+cfEZY2C+ROutCxDwHg2FyAod51MYMQ9kRygzjO3ic5Psxpqgfnu2J0uF6h8w3gcfSgPcpipT3NcrRex91YHAyPji9ShI2Ek8O4F9yU8sQ+b6nAnBIOHWx7mS/BjEjiX9s8yHGhvAuo5TMoA==
X-YMail-OSG: lpBaKN8VM1lYJju4iVipVB6qdecR1QKDB9gCHusdDetHfzO0OvNDtrwi_0j9zl4 fdy6m3lC7kDrqts_xAV7edJyvyTw7TVHZIBCLnVD4jeuHDvl4brDcjheCLqryhUKbU2I1Vc87iP7 gP_vw6_xdXOR6HxfwYK11lDGD2b.dWchWeasvLMj4JwciayQjrbu64T4d7XNj3p5FdACfvE7OJmD _oXrCK776XaOd6.7BMrUjgYbkTIqqBQZqQdWkf7Q_HuQLuHTXAEaisnJVbE4ZSMLRSxM7IjWKEkz XpY4oX2STwr2UQqch2qHw3ha7xE_ld9mukATyQXEEwNBmkumZtCUO2uhJAcQ4GL0f103gB0IyJoT yGuCndtIBWsKgLtanX5zPo5eRunUEwndwGWkE1TW95i_3tJtTHFklp4yY6rwh26N9W8YLysIGch7 K.P5oV13.H1pI54HSQyuh1lbZi.kdD8ZARwBswksT4bXooAz7Q4wPPsYDbjo5O4sUjNvJoV0yuSq oHrjOMne1V5TSfNEpifHcFY2UQ7ffjPcNLK1oGWV9nv5YA_KhgTtXFyTF2W0_XmmRRzUwEvl5cQb bGQ4CJv1M
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Apr 2018 17:57:57 +0000
Received: from c-73-158-191-172.hsd1.ca.comcast.net (EHLO [192.168.0.109]) ([73.158.191.172]) by smtp401.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c0fee7a67cb76257dbcdb85b1e6c3f67;  Sun, 22 Apr 2018 17:57:55 +0000 (UTC)
User-Agent: Microsoft-MacOutlook/10.9.0.180116
Date: Sun, 22 Apr 2018 10:57:54 -0700
From: Nitin Bahadur 
To: Susan Hares , 'Alvaro Retana' , 'The IESG' 
CC: , , 
Message-ID: 
Thread-Topic: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)
References: <152273965001.13971.7531466101349529801.idtracker@ietfa.amsl.com> <344B4088-7547-4479-8745-99DFBCD3A224@yahoo.com> <016301d3d341$0f4c4cf0$2de4e6d0$@ndzh.com>
In-Reply-To: <016301d3d341$0f4c4cf0$2de4e6d0$@ndzh.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Apr 2018 17:58:01 -0000

>From a process perspective I disagree with this. Just because the 2 drafts =
will end up going to RFC-ed queue at the same time does not mean we should b=
e adding circular references.

But if that's what the IESG would like me to, I'd be happy to put in a sent=
ence. Please provide me specifics of where I should add the sentence and wha=
t the sentence should look like.

Thanks
Nitin

=EF=BB=BFOn 4/13/18, 9:04 AM, "Susan Hares"  wrote:

    Nitin:=20
   =20
    On #1) -  These drafts will work through the process at the same time.
    There will be a "MISREF" - but it should be cleared.  =20
   =20
    Originally we were concerned about this fact because we wanted to send =
the
    I2RS Info model earlier.  However, due to the network management datast=
ore
    model work in netmod/netconf - this work has been held up.=20
   =20
    Please put the reference in and spin it as -16.txt.=20
   =20
    Thanks!
   =20
    Sue Hares=20
   =20
   =20
    -----Original Message-----
    From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur
    Sent: Friday, April 13, 2018 2:09 AM
    To: Alvaro Retana; The IESG
    Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; Susan Hares;
    draft-ietf-i2rs-rib-info-model@ietf.org
    Subject: Re: [i2rs] Alvaro Retana's No Objection on
    draft-ietf-i2rs-rib-info-model-15: (with COMMENT)
   =20
    Hi Alvaro,
   =20
       Thanks for the review. Please see NB> below   =20
   =20
        (1) Even if just Informative, it would be nice to have a reference =
to
        draft-ietf-i2rs-rib-data-model.
   =20
    NB> I'm not sure how referencing works. If I understand correctly,
    rib-info-model then can't be published until data-model is published...=
and
    then there is circular referencing.
       =20
        (2) I think that the use of some Normative Language is not as expec=
ted.
       =20
        (2.1) For example, in S2.1 (RIB definition): "There MAY be many rou=
ting
        instances and each routing instance MAY contain RIBs."  In both cas=
es
    "MAY"
        seems to be a statement of fact, and not a normative statement to
    indicate that
        a routing instance can optionally include RIBs. =20
   =20
    NB> Rewording to " A network device MAY contain routing instances and e=
ach
    routing instance MAY contain RIBs."
   =20
    Note that S2.2 (Routing
        instance) identifies a rib-list as a mandatory component of a routi=
ng
    instance,
        and there's no clear indication that the list may be empty.
       =20
    NB> Good point. I'll fix that.
   =20
        (2.2) S2.1: "A routing instance MAY even have two or more RIBs of t=
he
    same rib
        family (e.g., IPv6)."  This use of "MAY" also seems to be stating a
    fact.
     =20
    NB> Yes it is a fact. So removed use of "MAY".
     =20
        (2.3) "MAY be optionally", "MAY contain the following optional fiel=
ds"
    are
        redundant phrases as MAY already means optional.
       =20
     NB> Good point. Fixed.
   =20
    Thanks
    Nitin  =20
      =20
   =20
   =20
    _______________________________________________
    i2rs mailing list
    i2rs@ietf.org
    https://www.ietf.org/mailman/listinfo/i2rs
   =20
   =20