From nobody Mon Jun 5 20:25:07 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FC3127444; Mon, 5 Jun 2017 20:24:59 -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-netmod-yang-model-classification@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149671949959.3984.3647471702123309969.idtracker@ietfa.amsl.com> Date: Mon, 05 Jun 2017 20:24:59 -0700 Archived-At: Subject: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 03:25:00 -0000 Ben Campbell has entered the following ballot position for draft-ietf-netmod-yang-model-classification-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: -4: That seems almost a challenge :-) But seriously, I dont know if it makes sense to discuss this sort of thing in this document-- but it seems like sensitivity of content might be a consideration when "typing" models. For example, models that include security credentials or keys. (An answer of "that's not what we are talking about" would be perfectly sensible.) Editorial: -1, " A number of module types have created substantial discussion during the development of this document including those concerned with topologies." I'm not sure I understand that sentence. Is the antecedent of "those" "module types", or "discussions"? Are we talking about network topologies? The section ends with "See figure 1". But that figure seems more related to section 2. Is the reference out of place? From nobody Tue Jun 6 08:03:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2A3129516; Tue, 6 Jun 2017 08:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnubMtPAWRrH; Tue, 6 Jun 2017 08:03:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27F712949F; Tue, 6 Jun 2017 08:03:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DON62696; Tue, 06 Jun 2017 15:03:09 +0000 (GMT) Received: from DGGEMA401-HUB.china.huawei.com (10.3.20.42) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 6 Jun 2017 16:02:28 +0100 Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.207]) by DGGEMA401-HUB.china.huawei.com ([10.3.20.42]) with mapi id 14.03.0301.000; Tue, 6 Jun 2017 23:02:21 +0800 From: Rohit R Ranade To: "netconf@ietf.org" CC: "netmod@ietf.org" , Rohit pobbathi Thread-Topic: Output of /netconf-state/schemas in RFC 6022 Thread-Index: AdLe1d1Bsq+7wVbQQrm6fLRLB7cJrA== Date: Tue, 6 Jun 2017 15:02:21 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B094071@DGGEMA502-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.150.121] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6B094071DGGEMA502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5936C42D.023F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 37f10b4d62f0d4d48333ae03af1f45c2 Archived-At: Subject: [netmod] Output of /netconf-state/schemas in RFC 6022 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 15:03:15 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A6B094071DGGEMA502MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, In RFC 6022 : 2.1.3. The /netconf-state/schemas Subtree The list of supported schema for the NETCONF server. In RFC 7950: Section 5.6.4 Announcing Conformance Information in NETCONF With this mechanism, a client can cache the supported modules for a server and only update the cache if the "module-set-id" value in the message changes. Whether "supported schema" , "supported module", "implemented module" all m= ean the same thing for YANG? RFC 6022 need to list both modules and sub-modules. So whether we need to e= xtend this rule to sub-modules? We need to list only those sub-modules of i= mplemented modules ? With Regards, Rohit --_000_991B70D8B4112A4699D5C00DDBBF878A6B094071DGGEMA502MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

In RFC 6022 :

 

2.1.3. = ; The /netconf-state/schemas Subtree

 

   The list of supported schema for the NETCONF server.

 

In RFC 7950:

      Section 5.6.4 Announcing Conformance Information in NETCONF

 

   Wit= h this mechanism, a client can cache the supported modules for a

   ser= ver and only update the cache if the "module-set-id" value in the=

   <hello> message changes.

 

Whether “supported schema” , “supp= orted module”, “implemented module” all mean the same thi= ng for YANG?

 

RFC 6022 need to list both modules and sub-modules. = So whether we need to extend this rule to sub-modules? We need to list only= those sub-modules of implemented modules ?

 

With Regards,

Rohit

--_000_991B70D8B4112A4699D5C00DDBBF878A6B094071DGGEMA502MBXchi_-- From nobody Tue Jun 6 09:01:59 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AF31293E8 for ; Tue, 6 Jun 2017 09:01:58 -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, 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=yumaworks-com.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 1yNxBdmAwSnS for ; Tue, 6 Jun 2017 09:01:56 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A70C1292F5 for ; Tue, 6 Jun 2017 09:01:56 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id v104so56275646wrb.0 for ; Tue, 06 Jun 2017 09:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xYvWi6SboeditucMUQlfhJITlYlq3CsMPG24ySMVu30=; b=aeTsO1iVX1gNOYJ4UDm/6Z8Wwd5wBGRteU316+J5MJXbYsnaS5jz9SAwGWbFGQvanB 1dMnc9M55h5HeuS8LYsQBarobsX3EJIeuME0FBkm/lsTV36iJIVVzrjsdXOEue+6krWj GV6bNCg03rSKnI5EYB2+a0p7HwBzLkrDTv6mLAsAcRWlEBrLl2A1mVYWQbK0SsnkVnZ2 mwRvaP28tWYRCst2X+2MDEE6b0iD5eb3psQG4RB6Dijcm/uY8ftyUQsH5vkcN2igYTyV Ua229ktElZZjqYLGb2eE/sgI4W2rT4xTp8w7+yk6aK7xFmksgIvfpJ1lSYjunl68nMQB jfDg== 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; bh=xYvWi6SboeditucMUQlfhJITlYlq3CsMPG24ySMVu30=; b=Pot4rhS3KUwvf2ZHduBna8Br9/RBe8kcAKDcKy+4gnit9Z3Bf+J4peTjYRYD+gpRT2 lC/jVpGWSg8EPMMCbRmWJKH5x2qDxuEzN/rtH8UP/REUH4vStBA8yfjcj4Q+1hT9EXOd ApFrkW7LBqkym8iuriFUJWAydt7SS9J1+V4GZKnEKiuLTS5Q0uQy1Wtk6Av0dq/+QrYX cOw/kADR7Cj/8q+UgltZBYfALHXosGN5klOQ94pq4X6mHm1LUUkTTsUWGCKz9nRFym17 kwxpNZbFaKKI9VKFet9lXNPO+PferhUF0rejEWyhRTj4SX2M0Cy4SYEHQihHTE6C3GG2 XhXg== X-Gm-Message-State: AODbwcBzCOXMayCMN38Omu5sTU+gfuH3Y1ILVIkrK+Dwkcu7Ff0Qjxei OcSvIzddgng3dt1PYx1IOciRrj8f1GoS X-Received: by 10.223.176.205 with SMTP id j13mr4566341wra.65.1496764914706; Tue, 06 Jun 2017 09:01:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.155.2 with HTTP; Tue, 6 Jun 2017 09:01:54 -0700 (PDT) In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B094071@DGGEMA502-MBX.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6B094071@DGGEMA502-MBX.china.huawei.com> From: Andy Bierman Date: Tue, 6 Jun 2017 09:01:54 -0700 Message-ID: To: Rohit R Ranade Cc: "netconf@ietf.org" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a1141c6c00dc8fb05514cbdf1" Archived-At: Subject: Re: [netmod] Output of /netconf-state/schemas in RFC 6022 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 16:01:59 -0000 --001a1141c6c00dc8fb05514cbdf1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 6, 2017 at 8:02 AM, Rohit R Ranade wrote: > Hi All, > > > > In RFC 6022 : > > > > *2.1.3. The /netconf-state/schemas Subtree* > > > > The list of *supported schema* for the NETCONF server. > this usage is general meaning all modules used by the server -- not the same as YANG > > > In RFC 7950: > > Section 5.6.4 *Announcing Conformance Information in NETCONF* > > > > With this mechanism, a client can cache *the supported modules* for a > > server and only update the cache if the "module-set-id" value in the > > message changes. > > > > Whether =E2=80=9Csupported schema=E2=80=9D , =E2=80=9Csupported module=E2= =80=9D, =E2=80=9Cimplemented module=E2=80=9D all > mean the same thing for YANG? > This probably means all modules used by the server -- not the same as implemented vs. imported. > > RFC 6022 need to list both modules and sub-modules. So whether we need to > extend this rule to sub-modules? We need to list only those sub-modules o= f > implemented modules ? > list all modules and submodules > > > With Regards, > > Rohit > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a1141c6c00dc8fb05514cbdf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 6, 2017 at 8:02 AM, Rohit R Ranade <rohitrranade@hua= wei.com> wrote:

Hi All,

=C2=A0

In RFC 6022 :

=C2=A0

2.1.3.=C2= =A0 The /netconf-state/schemas Subtree

=C2=A0=

=C2=A0=C2=A0 The list of supported schema for the NETCONF server.



this usage is general mea= ning all modules used by the server -- not the same as YANG

<= /div>
=C2=A0

=C2=A0

In RFC 7950:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 5.6.4 Announcing Conformance Information in NETCONF<= /p>

=C2=A0

=C2=A0=C2=A0 Wit= h this mechanism, a client can cache the supported modules for a

=C2=A0=C2=A0 ser= ver and only update the cache if the "module-set-id" value in the=

=C2=A0=C2=A0 <hello> message changes.

=C2=A0

Whether =E2=80=9Csupported schema=E2=80=9D , =E2=80= =9Csupported module=E2=80=9D, =E2=80=9Cimplemented module=E2=80=9D all mean= the same thing for YANG?


<= br>
This probably means all modules used by the server -- not the= same as implemented vs. imported.


<= u>

=C2=A0

RFC 6022 need to list both modules and sub-modules. = So whether we need to extend this rule to sub-modules? We need to list only= those sub-modules of implemented modules ?



list all modules and submodules
= =C2=A0

=C2=A0

With Regards,

Rohit



Andy
=C2=A0
_______________________________________________ netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--001a1141c6c00dc8fb05514cbdf1-- From nobody Tue Jun 6 12:30:50 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB0F1242EA; Tue, 6 Jun 2017 12:30:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-netmod-yang-model-classification@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149677744855.4002.15427399247421427034.idtracker@ietfa.amsl.com> Date: Tue, 06 Jun 2017 12:30:48 -0700 Archived-At: Subject: [netmod] Alia Atlas' Yes on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 19:30:49 -0000 Alia Atlas has entered the following ballot position for draft-ietf-netmod-yang-model-classification-07: Yes 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-netmod-yang-model-classification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- If there is a desire to change from "module types", which I agree is likely to be overused, an alternate term might be "module pedigree". Thank you for an excellent, clear, and useful document; I remember the confusion that generated this. From nobody Tue Jun 6 15:13:55 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C621B126E01; Tue, 6 Jun 2017 15:13:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-netmod-yang-model-classification@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149678722780.26802.16584624234006988117.idtracker@ietfa.amsl.com> Date: Tue, 06 Jun 2017 15:13:47 -0700 Archived-At: Subject: [netmod] Adam Roach's No Objection on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 22:13:48 -0000 Adam Roach has entered the following ballot position for draft-ietf-netmod-yang-model-classification-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not going to pick out a bike shed color, but I do support the assertions that "module type" is a bit too ambiguous. When I got to section 3, I had to go back to see what section 2 called its things, because "type" is so generic. There are some places where the unexpanded acronyms lost me (VRF, MEF, UNI) -- consider expanding these on first use. From nobody Tue Jun 6 16:43:23 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD1B128B4E for ; Tue, 6 Jun 2017 16:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZdwjWRmlPC6 for ; Tue, 6 Jun 2017 16:43:20 -0700 (PDT) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0C5120721 for ; Tue, 6 Jun 2017 16:43:20 -0700 (PDT) From: Alex Campbell To: "netmod@ietf.org" Thread-Topic: Question about ietf-routing Thread-Index: AQHS3x5Bkeeb5JjXkkKedeZMDHRzCg== Date: Tue, 6 Jun 2017 23:43:19 +0000 Message-ID: <1496792599527.55133@Aviatnet.com> Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.9] Content-Type: multipart/alternative; boundary="_000_149679259952755133Aviatnetcom_" MIME-Version: 1.0 Archived-At: Subject: [netmod] Question about ietf-routing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 23:43:22 -0000 --_000_149679259952755133Aviatnetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I noticed that the ietf-routing YANG (published in RFC 8022) allows for mul= tiple instances of each control plane protocol, as well as multiple RIBs pe= r address family. However I don't see any way to associate one with the other. Without additi= onal configuration, protocols will only place their routes in default RIBs. Is it intended that this will be left to vendor-specific modules and/or fut= ure standards? Alex --_000_149679259952755133Aviatnetcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,

I noticed that the ietf-routing YANG (published in RFC 8022) allows for mul= tiple instances of each control plane protocol, as well as multiple RIBs pe= r address family.
However I don't see any way to associate one with the other. Without a= dditional configuration, protocols will only place their routes in default = RIBs.
Is it intended that this will be left to vendor-specific modules and/or fut= ure standards?

Alex
--_000_149679259952755133Aviatnetcom_-- From nobody Tue Jun 6 20:16:50 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E821E129B48 for ; Tue, 6 Jun 2017 20:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 5Sm8r-IsyrAv for ; Tue, 6 Jun 2017 20:16:46 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 1E01C129B5F for ; Tue, 6 Jun 2017 20:16:46 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id 202so223881ybd.0 for ; Tue, 06 Jun 2017 20:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g0rTpqemPMn22v78qImX29qAvuLJDpOa+XtJEcwn1oE=; b=VuoDpvN/krBghQI6N4HxZLNAaoJDXU6beOOXz45xnm+GlSjvulBUNwrRcNkQfdSHe3 BsGJWOLc/Aemgk8l2X84bQ1+0Yxu3CnxicLtXwYTAzUchs2U5UBl1Kt9ygBSMqlA5Sxw H4h0ZwVpHPnND7zgOusd8GDTR7yIPrPZ9VJhHCLCIF0c+H62mEWJoH8GsLpoVpEYz68Y lo2QusgfU9cnoEbbpPR48SidXhVNDAQfIe5beZPT/dnfc9hHzc1g+ghk4NTuWNj4gT/p CfcP+Cn2S3NSoeQ4SLcNxvtXeRq9o9f/IpyqkGUyV6peI91bCPkCn/YjsEqxx7bITcDP wpcg== 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; bh=g0rTpqemPMn22v78qImX29qAvuLJDpOa+XtJEcwn1oE=; b=Hhnxtx04R7VeiUNjVWXffqXim8MNRmTZCSlOYg9zYV1jMCU3wUnDFm7N87wRHCtPnp L49XLGzQiBW2UI4+4Ylqy+ib/KEm2YOLTxMkqBo1p5S3wyjdXoC/QUg6vDY7zHIarqVG 2odGBFcW4yxeikFVILXr0jmF59xG/e3CGB803VH6T2xS4/oQAE5Emx/pCYG0AKSnJpBY MeE8H+DikglkYd5hlqjUIicwyBoVb/qI94Lj0voH3mKu5AY8emctlreDbOrQleiLZ3mD kJ3+34TuF2nTAu1jhK5v7vb+Q60Wa1oP/tB8I46y5hieaWBWZqYq6E0xETtj/Gcpu4jS n7yw== X-Gm-Message-State: AODbwcD2N1Z9guhm7pwqqnmwI2dGgyR6RfnW/HtSpt0rb08BQ9N9hFfq uXbGm1KBn7+KRB6p+Z1ZItTcb+LWTDvU X-Received: by 10.37.162.100 with SMTP id b91mr5241258ybi.29.1496805405464; Tue, 06 Jun 2017 20:16:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.4 with HTTP; Tue, 6 Jun 2017 20:16:05 -0700 (PDT) In-Reply-To: <149677744855.4002.15427399247421427034.idtracker@ietfa.amsl.com> References: <149677744855.4002.15427399247421427034.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 7 Jun 2017 05:16:05 +0200 Message-ID: To: Alia Atlas Cc: The IESG , netmod-chairs@ietf.org, lberger@labn.net, draft-ietf-netmod-yang-model-classification@ietf.org, netmod@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19f3b47db6df0551562a06" Archived-At: Subject: Re: [netmod] Alia Atlas' Yes on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 03:16:49 -0000 --94eb2c19f3b47db6df0551562a06 Content-Type: text/plain; charset="UTF-8" Module pedigree seems good. Other alternatives might be "module ownership" or "module origin" On Tue, Jun 6, 2017 at 9:30 PM, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-ietf-netmod-yang-model-classification-07: Yes > > 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-netmod-yang- > model-classification/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > If there is a desire to change from "module types", which I agree is > likely to > be overused, an alternate term might be "module pedigree". Thank you for > an > excellent, clear, and useful document; I remember the confusion that > generated > this. > > > --94eb2c19f3b47db6df0551562a06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Module pedigree seems good. Other alternatives might = be "module ownership" or "module origin"

=

On Tu= e, Jun 6, 2017 at 9:30 PM, Alia Atlas <akatlas@gmail.com> wr= ote:
Alia Atlas has entered the following= ballot position for
draft-ietf-netmod-yang-model-classification-07: Yes

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/<= wbr>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.iet= f.org/doc/draft-ietf-netmod-yang-model-classification/



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

If there is a desire to change from "module types", which I agree= is likely to
be overused,=C2=A0 an alternate term might be "module pedigree". = Thank you for an
excellent, clear, and useful document; I remember the confusion that genera= ted
this.



--94eb2c19f3b47db6df0551562a06-- From nobody Tue Jun 6 23:25:37 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEB7129BF9 for ; Tue, 6 Jun 2017 23:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-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_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 YKFob_BjUymO for ; Tue, 6 Jun 2017 23:25:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 78E96129B63 for ; Tue, 6 Jun 2017 23:25:34 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:d152:5fec:7f77:38cb] (unknown [IPv6:2001:718:1a02:1:d152:5fec:7f77:38cb]) by mail.nic.cz (Postfix) with ESMTPSA id 9D83B60149; Wed, 7 Jun 2017 08:25:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1496816732; bh=TxXyOK5zPsmUM+dcvgCTN9Me8ge44afIfLKTkxEWyrQ=; h=From:Date:To; b=ddpDpo+Wsisht6SZ2SvBoCR/0h7189CaNcmUZ2BrOaIsNV1+rdCloAtKU/AT3ReOb L769qgfxR74hixgII1o8QdrDVT8P/aaeX7a+RX3y35/R4ac04SZ5AMS3x/KJOyNTtG ySWa+hO8DOr9HiFMIxVWL6oitD5mMM/mNfDNeJAg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka In-Reply-To: <1496792599527.55133@Aviatnet.com> Date: Wed, 7 Jun 2017 08:25:32 +0200 Cc: "netmod@ietf.org" , "Acee Lindem (acee)" Content-Transfer-Encoding: quoted-printable Message-Id: <64B138D8-929F-43AA-8246-DD1AB8793274@nic.cz> References: <1496792599527.55133@Aviatnet.com> To: Alex Campbell X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Question about ietf-routing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 06:25:36 -0000 Hi Alex, in earlier revisions of the ietf-routing module (up to = draft-ietf-netmod-routing-cfg-17), we had a configuration item = ("recipient-ribs") that allowed for assigning RIBs to routing protocol = instances. The reason for removing it is summarized in my presentation = from IETF 92, slides 10 and 11: https://www.ietf.org/proceedings/92/slides/slides-92-netmod-9.pdf (and yes, I wasn't a big fan of this change). Maybe Acee can give additional background. Lada=20 > On 7 Jun 2017, at 01:43, Alex Campbell = wrote: >=20 > Hi, >=20 > I noticed that the ietf-routing YANG (published in RFC 8022) allows = for multiple instances of each control plane protocol, as well as = multiple RIBs per address family. > However I don't see any way to associate one with the other. Without = additional configuration, protocols will only place their routes in = default RIBs. > Is it intended that this will be left to vendor-specific modules = and/or future standards? >=20 > Alex > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jun 7 05:50:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D6612EC16; Wed, 7 Jun 2017 05:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGS5aBfbLa1m; Wed, 7 Jun 2017 05:50:48 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE2D129459; Wed, 7 Jun 2017 05:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7144; q=dns/txt; s=iport; t=1496839847; x=1498049447; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=mwMfbO3ennvVWhNOKacJHyQ4DJW237UU1MBeNSnAGuc=; b=GzHdEZ62W5QS0H/hZBXVm01JvRv1H/n3sDYFJc0I+YaKpUG+cxjmq+RZ fUVJZz+FiklCb44OhNA7VbuTzs4sUSgvaOJYxpf4F34LJYxrGZ/jXnAjP XQM6rMRHXwAsCdxCHwAkY/8Xq/fXrlXHygJVB1IxzJBo+ErZNOgnIdp2H Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQBk9TdZ/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhDqBDYNzihhzkHWQR4U5ghAuhXYCgy4YAQIBAQEBAQEBayiFGQEEASN?= =?us-ascii?q?WEAtCAgJXBgEMCAEBih8IEK5SgiYri1IBAQEBAQEBAQEBAQEBAQEBAQEBAQEYB?= =?us-ascii?q?YZhgguCdYQ7EgGDLoJhBYlNlGyHJowSggaFPoNLhnGMKog9Hzh/CzAhCBsVhgK?= =?us-ascii?q?BTj42AYchgjABAQE?= X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208,217";a="694974931" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 12:50:42 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v57CofvF025089; Wed, 7 Jun 2017 12:50:42 GMT To: Ben Campbell , The IESG Cc: draft-ietf-netmod-yang-model-classification@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <149671949959.3984.3647471702123309969.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <5ff62d49-9b3b-9fe2-9f34-bf4660009302@cisco.com> Date: Wed, 7 Jun 2017 14:50:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149671949959.3984.3647471702123309969.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------8A3242BB47E0419367AF2503" Content-Language: en-US Archived-At: Subject: Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 12:50:50 -0000 This is a multi-part message in MIME format. --------------8A3242BB47E0419367AF2503 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ben, Thanks for your review. See in-line. > Ben Campbell has entered the following ballot position for > draft-ietf-netmod-yang-model-classification-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive: > > -4: That seems almost a challenge :-) But seriously, I dont know if it makes > sense to discuss this sort of thing in this document-- but it seems like > sensitivity of content might be a consideration when "typing" models. For > example, models that include security credentials or keys. (An answer of > "that's not what we are talking about" would be perfectly sensible.) Actually, the security considerations related to the YANG module should not influence the YANG module classification. I wrote "should" because I can't think of a single case. To complete the Security Considerations section, here is a proposal. OLD: This document doesn't have any Security Considerations. NEW: The document specifying the YANG module to-be-classified already contains a Security Considerations section. This document doesn't add to or modify this Security Considerations section. > > Editorial: > > -1, " A number of module types have created substantial discussion during the > development of this document including those concerned with topologies." > > I'm not sure I understand that sentence. Is the antecedent of "those" "module > types", or "discussions"? Are we talking about network topologies? OLD: A number of module types have created substantial discussion during the development of this document including those concerned with topologies. NEW: A number of module types have created substantial discussion during the development of this document: for example, those concerned with topologies. > > The section ends with "See figure 1". But that figure seems more related to > section 2. Is the reference out of place? The reference is right. Positioning the YANG modules from a location point of view (equipment vendor, controller, orchestrator) helps people grasp the concepts of Network Element YANG Modules versus Network Service YANG Modules Regards, Benoit > > > . > --------------8A3242BB47E0419367AF2503 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Ben,

Thanks for your review. See in-line.
Ben Campbell has entered the following ballot position for
draft-ietf-netmod-yang-model-classification-07: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/



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

Substantive:

-4: That seems almost a challenge :-) But seriously, I dont know if it makes
sense to discuss this sort of thing in this document-- but it seems like
sensitivity of content might be a consideration when "typing" models. For
example, models that include security credentials or keys. (An answer of
"that's not what we are talking about" would be perfectly sensible.)
Actually, the security considerations related to the YANG module should not influence the YANG module classification.
I wrote "should" because I can't think of a single case.
To complete the Security Considerations section, here is a proposal.
OLD: 
   This document doesn't have any Security Considerations.

NEW:
   The document specifying the YANG module to-be-classified already contains a Security Considerations
   section. This document doesn't add to or modify this Security Considerations section.  


Editorial:

-1, " A number of module types have created substantial discussion during   the
development of this document including those concerned with   topologies."

I'm not sure I understand that sentence. Is the antecedent of "those" "module
types", or "discussions"? Are we talking about network topologies?
OLD:
   A number of module types have created substantial discussion during
   the development of this document including those concerned with
   topologies. 

NEW:
   A number of module types have created substantial discussion during
   the development of this document: for example, those concerned with
   topologies. 

The section ends with "See figure 1". But that figure seems more related to
section 2. Is the reference out of place?
The reference is right. Positioning the YANG modules from a location point of view (equipment vendor, controller, orchestrator) helps people grasp the concepts of Network Element YANG Modules versus Network Service YANG Modules

Regards, Benoit


.

--------------8A3242BB47E0419367AF2503-- From nobody Wed Jun 7 05:55:45 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB627127868; Wed, 7 Jun 2017 05:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv6-OUVQxgWL; Wed, 7 Jun 2017 05:55:36 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C86412EC10; Wed, 7 Jun 2017 05:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4221; q=dns/txt; s=iport; t=1496840134; x=1498049734; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=JDSdC8f1lCUG3b2gQkE2ksJy9GliK28hVsW1aXu2hag=; b=bYvgnlnPOYVkcmMPT20JoDc/gbgH8wfm1l58yUqGfed9iJD+Ff3H+BuM 3sO+pIZFxCiWF4iG4Adnb6LMJVp12ldErm4i1TnWCygsNpMW9G5UMh+S4 S+yOgzBDXN7+QwfKJaQxe1sWaTNXDUhYEpGrRBVzUCnEdqvCyPLJDPlaC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAADX9jdZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqBDYNzihhzkHWQR4U5ghAuhXYCgy8YAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?FI1YQCwQUKgICVwYBDAgBAYonEK5QgiYri1IBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEYBYZhgguCdYQ7EgGDLoJhAQSJTZRshyaMEoIGhT6DS4ZxjCqIPR84fwswIQg?= =?us-ascii?q?bFYYCgU4+NgGHIYIwAQEB?= X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208,217";a="655251440" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 12:55:29 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v57CtOAT008966; Wed, 7 Jun 2017 12:55:24 GMT To: Adam Roach , The IESG Cc: netmod-chairs@ietf.org, lberger@labn.net, draft-ietf-netmod-yang-model-classification@ietf.org, netmod@ietf.org References: <149678722780.26802.16584624234006988117.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: Date: Wed, 7 Jun 2017 14:55:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149678722780.26802.16584624234006988117.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------A4E17F48C99BE964D6DAB47E" Content-Language: en-US Archived-At: Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 12:55:38 -0000 This is a multi-part message in MIME format. --------------A4E17F48C99BE964D6DAB47E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 6/7/2017 12:13 AM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-netmod-yang-model-classification-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm not going to pick out a bike shed color, but I do support the assertions > that "module type" is a bit too ambiguous. When I got to section 3, I had to go > back to see what section 2 called its things, because "type" is so generic. What about OLD: 3. Second Dimension: Module Types NEW: 3. Second Dimension: Module Origin Types > > There are some places where the unexpanded acronyms lost me (VRF, MEF, UNI) -- Ack. Note: MEF is not an acronym any longer since they want to move away from the narrow scope of Metro Ethernet Regards, B. > consider expanding these on first use. > > > . > --------------A4E17F48C99BE964D6DAB47E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 6/7/2017 12:13 AM, Adam Roach wrote:
Adam Roach has entered the following ballot position for
draft-ietf-netmod-yang-model-classification-07: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/



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

I'm not going to pick out a bike shed color, but I do support the assertions
that "module type" is a bit too ambiguous. When I got to section 3, I had to go
back to see what section 2 called its things, because "type" is so generic.
What about
OLD: 3. Second Dimension: Module Types
NEW: 3. Second Dimension: Module Origin Types

There are some places where the unexpanded acronyms lost me (VRF, MEF, UNI) --
Ack.
Note: MEF is not an acronym any longer since they want to move away from the narrow scope of Metro Ethernet

Regards, B.
consider expanding these on first use.


.

--------------A4E17F48C99BE964D6DAB47E-- From nobody Wed Jun 7 05:56:32 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94745127868; Wed, 7 Jun 2017 05:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk-cyTsepXp1; Wed, 7 Jun 2017 05:56:23 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0091129464; Wed, 7 Jun 2017 05:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5262; q=dns/txt; s=iport; t=1496840183; x=1498049783; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=fj1kxBwAZtcnNgM+v4gPBglKgvn7zzpOgmHxisqOWL8=; b=l/tMEXde4ZOpEEcE7Fukb4sI3H9Lx/YUv5gl+T7hUS54Ocuc9LO0OTYz VLgpQUNjSQeS9D+iDi3Pyr/GGzGA1Jg+WilvkFIrCiokAr1XipRAb7MTr hkcJlRb5SXYh4vq1Eyg/Yk9IrsNREqhmvgI6Mpv0XsJuFb8B7hUkCFyBq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAAC/9jdZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqBDYNzihhzkHWIKogdhTmCEC6FdgKDLxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?ZAQUjVhALDgonAwICISURBgEMBgIBAYoPAxUQrlCCJiuHEw2EMgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhmGCC4J1gliBYxIBgy6CYQWJTZQxO4cmhzWEXYIGhT6?= =?us-ascii?q?DS4Zxi0JoiD0fOH8LMCEIGxWFFG6BTj42AYchgjABAQE?= X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208,217";a="694975024" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 12:56:18 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v57CuI1e015893; Wed, 7 Jun 2017 12:56:18 GMT To: Eric Rescorla , Alia Atlas Cc: The IESG , netmod-chairs@ietf.org, lberger@labn.net, draft-ietf-netmod-yang-model-classification@ietf.org, netmod@ietf.org References: <149677744855.4002.15427399247421427034.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <3ff323af-2b76-4e94-2d8e-09f9970cf884@cisco.com> Date: Wed, 7 Jun 2017 14:56:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E893C74F29A39C1067177636" Content-Language: en-US Archived-At: Subject: Re: [netmod] Alia Atlas' Yes on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 12:56:26 -0000 This is a multi-part message in MIME format. --------------E893C74F29A39C1067177636 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 6/7/2017 5:16 AM, Eric Rescorla wrote: > Module pedigree seems good. Other alternatives might be "module > ownership" or "module origin" Seeing this now, I agree with "module origin" :-) Regards, B. > > > On Tue, Jun 6, 2017 at 9:30 PM, Alia Atlas > wrote: > > Alia Atlas has entered the following ballot position for > draft-ietf-netmod-yang-model-classification-07: Yes > > 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-netmod-yang-model-classification/ > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > If there is a desire to change from "module types", which I agree > is likely to > be overused, an alternate term might be "module pedigree". Thank > you for an > excellent, clear, and useful document; I remember the confusion > that generated > this. > > > --------------E893C74F29A39C1067177636 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/7/2017 5:16 AM, Eric Rescorla wrote:
Module pedigree seems good. Other alternatives might be "module ownership" or "module origin"
Seeing this now, I agree with "module origin" :-)

Regards, B.


On Tue, Jun 6, 2017 at 9:30 PM, Alia Atlas <akatlas@gmail.com> wrote:
Alia Atlas has entered the following ballot position for
draft-ietf-netmod-yang-model-classification-07: Yes

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-netmod-yang-model-classification/



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

If there is a desire to change from "module types", which I agree is likely to
be overused,  an alternate term might be "module pedigree". Thank you for an
excellent, clear, and useful document; I remember the confusion that generated
this.




--------------E893C74F29A39C1067177636-- From nobody Wed Jun 7 06:11:33 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C075E1270AC; Wed, 7 Jun 2017 06:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 qXoh9Cjw_L8x; Wed, 7 Jun 2017 06:11:30 -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 3C2441272E1; Wed, 7 Jun 2017 06:11:30 -0700 (PDT) Received: from [10.0.2.125] (ip-100-232-239-173.texas.us.northamericancoax.com [173.239.232.100]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v57DBOUA033741 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 7 Jun 2017 08:11:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-100-232-239-173.texas.us.northamericancoax.com [173.239.232.100] claimed to be [10.0.2.125] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (14F89) In-Reply-To: <5ff62d49-9b3b-9fe2-9f34-bf4660009302@cisco.com> Date: Wed, 7 Jun 2017 09:11:23 -0400 Cc: The IESG , netmod-chairs@ietf.org, Lou Berger , draft-ietf-netmod-yang-model-classification@ietf.org, netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5831EE80-4EA7-4846-91EF-CA56CF0BA4A4@nostrum.com> References: <149671949959.3984.3647471702123309969.idtracker@ietfa.amsl.com> <5ff62d49-9b3b-9fe2-9f34-bf4660009302@cisco.com> To: Benoit Claise Archived-At: Subject: Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 13:11:32 -0000 Thanks for the response. Also in-line: > On Jun 7, 2017, at 8:50 AM, Benoit Claise wrote: >=20 > Hi Ben, >=20 > Thanks for your review. See in-line. >> Ben Campbell has entered the following ballot position for >> draft-ietf-netmod-yang-model-classification-07: No Objection >>=20 >>=20 [...] >> Substantive: >>=20 >> -4: That seems almost a challenge :-) But seriously, I dont know if it ma= kes >> sense to discuss this sort of thing in this document-- but it seems like >> sensitivity of content might be a consideration when "typing" models. For= >> example, models that include security credentials or keys. (An answer of >> "that's not what we are talking about" would be perfectly sensible.) > Actually, the security considerations related to the YANG module should no= t influence the YANG module classification. > I wrote "should" because I can't think of a single case. I'm fine with that, as long as people have thought about it--and this shows e= vidence that they have. > To complete the Security Considerations section, here is a proposal. > OLD:=20 > This document doesn't have any Security Considerations. >=20 > NEW: > The document specifying the YANG module to-be-classified already contai= ns a Security Considerations > section. This document doesn't add to or modify this Security Considera= tions section. =20 I'm okay with either version at this point. >> Editorial: >>=20 >> -1, " A number of module types have created substantial discussion during= the >> development of this document including those concerned with topologies.= " >>=20 >> I'm not sure I understand that sentence. Is the antecedent of "those" "mo= dule >> types", or "discussions"? Are we talking about network topologies? > OLD: > A number of module types have created substantial discussion during > the development of this document including those concerned with > topologies.=20 >=20 > NEW: > A number of module types have created substantial discussion during > the development of this document: for example, those concerned with > topologies.=20 Would it make sense to say "... for example, modules concerned with topologi= es."? >> The section ends with "See figure 1". But that figure seems more related t= o >> section 2. Is the reference out of place? > The reference is right. Positioning the YANG modules from a location point= of view (equipment vendor, controller, orchestrator) helps people grasp the= concepts of Network Element YANG Modules versus Network Service YANG Module= s So this was just an editorial comment, so feel free to ignore, but the bulle= t point containing the reference is not obviously about the concepts of elem= ent vs service modules. It does talk about relationships between models. The= idea of service vs element models has not yet been explained at that point,= and the figure is not sufficient by itself to explain that idea. Maybe sayi= ng "relationships between types of models" would tie the ideas together more= closely. Or maybe consider changing the reference to Figure 1 to a referenc= e to Section 2 in it's entirety. >=20 > Regards, Benoit >>=20 >>=20 >> . >>=20 >=20 From nobody Wed Jun 7 07:27:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87E112EC73; Wed, 7 Jun 2017 07:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgOmqIKkhXqM; Wed, 7 Jun 2017 07:27:14 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68B3129466; Wed, 7 Jun 2017 07:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2394; q=dns/txt; s=iport; t=1496845634; x=1498055234; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pS2axgnh+/Va+WveOzA7w/fGMWp15Yj4gG6dajCZHH4=; b=Timlt6zZnXZCJPlohb+dJwZZyzZR27JSUwKFNFvzWClIi/R1R/p6/TzA X1RIkPOmMHh7A9nUa2+up95+JfWv08+wL2GCF29wSk1OdUuP6aW7sg+KJ Xdbgi4GMCsWtCrPjMoGAhLR1USckgWKarr9M72qtTFm1Yq1XHVFpImfRB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAAClDDhZ/4cNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0Hg2yKGKdoghAhC4UuSgIaglo/GAECAQEBAQEBAWsohRk?= =?us-ascii?q?CAQECAQEhEToLEAIBCBoCJgICAiULFRACBAENBYorEK5WgiaLfwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFgQuKVoRqOoJYgmEFkDOOBgKTNpIAlGYBHziBCnQVRoc?= =?us-ascii?q?IdgGIRIENAQEB?= X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208";a="437022063" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jun 2017 14:27:13 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v57ERDuj016938 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Jun 2017 14:27:13 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Jun 2017 10:27:12 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 7 Jun 2017 10:27:12 -0400 From: "Acee Lindem (acee)" To: Ladislav Lhotka , Alex Campbell CC: "netmod@ietf.org" , RTG YANG Design Team Thread-Topic: [netmod] Question about ietf-routing Thread-Index: AQHS3x5Bkeeb5JjXkkKedeZMDHRzCqIZMowAgABDgAA= Date: Wed, 7 Jun 2017 14:27:12 +0000 Message-ID: References: <1496792599527.55133@Aviatnet.com> <64B138D8-929F-43AA-8246-DD1AB8793274@nic.cz> In-Reply-To: <64B138D8-929F-43AA-8246-DD1AB8793274@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Question about ietf-routing X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 14:27:17 -0000 K1lBTkcgUm91dGluZyBEZXNpZ24gVGVhbQ0KDQpPbiA2LzcvMTcsIDI6MjUgQU0sICJMYWRpc2xh diBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCg0KPkhpIEFsZXgsDQo+DQo+aW4gZWFy bGllciByZXZpc2lvbnMgb2YgdGhlIGlldGYtcm91dGluZyBtb2R1bGUgKHVwIHRvDQo+ZHJhZnQt aWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMTcpLCB3ZSBoYWQgYSBjb25maWd1cmF0aW9uIGl0ZW0N Cj4oInJlY2lwaWVudC1yaWJzIikgdGhhdCBhbGxvd2VkIGZvciBhc3NpZ25pbmcgUklCcyB0byBy b3V0aW5nIHByb3RvY29sDQo+aW5zdGFuY2VzLiBUaGUgcmVhc29uIGZvciByZW1vdmluZyBpdCBp cyBzdW1tYXJpemVkIGluIG15IHByZXNlbnRhdGlvbg0KPmZyb20gSUVURiA5Miwgc2xpZGVzIDEw IGFuZCAxMToNCj4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9zbGlkZXMv c2xpZGVzLTkyLW5ldG1vZC05LnBkZg0KPg0KPihhbmQgeWVzLCBJIHdhc24ndCBhIGJpZyBmYW4g b2YgdGhpcyBjaGFuZ2UpLg0KPg0KPk1heWJlIEFjZWUgY2FuIGdpdmUgYWRkaXRpb25hbCBiYWNr Z3JvdW5kLg0KDQpUaGUgUklCcyB3aGljaCB0aGUgY29udHJvbCBwbGFuZSBwcm90b2NvbHMgcG9w dWxhdGVkIGFyZSBub3JtYWxseSBkaWN0YXRlZA0KYnkgdGhlIGFkZHJlc3MgZmFtaWx5LiBJbiB0 aGUgY2FzZSBvZiBtdWx0aXBsZSB0b3BvbG9naWVzLCBhIHNwZWNpZmljIFJJQg0KKGFzIGlkZW50 aWZpZWQgYnkgbmFtZSkgd2lsbCBuZWVkIHRvIGJlIGV4cGxpY2l0bHkgYXNzb2NpYXRlZCB3aXRo IHRoZQ0KdG9wb2xvZ3kgaW4gdGhlIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgYXMgb3Bwb3NlZCB0 byBiZWluZyBjb25uZWN0ZWQgdG8NCnRoZSBjb250cm9sIHBsYW5lIHByb3RvY29sIGF0IGEgaGln aGVyIGxldmVsLg0KDQpUaGFua3MsDQpBY2VlIA0KDQoNCg0KDQo+DQo+TGFkYSANCj4NCj4+IE9u IDcgSnVuIDIwMTcsIGF0IDAxOjQzLCBBbGV4IENhbXBiZWxsIDxBbGV4LkNhbXBiZWxsQEF2aWF0 bmV0LmNvbT4NCj4+d3JvdGU6DQo+PiANCj4+IEhpLA0KPj4gDQo+PiBJIG5vdGljZWQgdGhhdCB0 aGUgaWV0Zi1yb3V0aW5nIFlBTkcgKHB1Ymxpc2hlZCBpbiBSRkMgODAyMikgYWxsb3dzIGZvcg0K Pj5tdWx0aXBsZSBpbnN0YW5jZXMgb2YgZWFjaCBjb250cm9sIHBsYW5lIHByb3RvY29sLCBhcyB3 ZWxsIGFzIG11bHRpcGxlDQo+PlJJQnMgcGVyIGFkZHJlc3MgZmFtaWx5Lg0KPj4gSG93ZXZlciBJ IGRvbid0IHNlZSBhbnkgd2F5IHRvIGFzc29jaWF0ZSBvbmUgd2l0aCB0aGUgb3RoZXIuIFdpdGhv dXQNCj4+YWRkaXRpb25hbCBjb25maWd1cmF0aW9uLCBwcm90b2NvbHMgd2lsbCBvbmx5IHBsYWNl IHRoZWlyIHJvdXRlcyBpbg0KPj5kZWZhdWx0IFJJQnMuDQo+PiBJcyBpdCBpbnRlbmRlZCB0aGF0 IHRoaXMgd2lsbCBiZSBsZWZ0IHRvIHZlbmRvci1zcGVjaWZpYyBtb2R1bGVzIGFuZC9vcg0KPj5m dXR1cmUgc3RhbmRhcmRzPw0KPj4gDQo+PiBBbGV4DQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0 bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0KPg0KPi0tDQo+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6 IDB4QjhGOTJCMDhBOUY3NkM2Nw0KPg0KPg0KPg0KPg0KPg0KDQo= From nobody Wed Jun 7 11:13:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD641294FA for ; Wed, 7 Jun 2017 11:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 dXJHbnDFa-gi for ; Wed, 7 Jun 2017 11:13:29 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0122.outbound.protection.outlook.com [104.47.41.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986CB128D3E for ; Wed, 7 Jun 2017 11:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EBq7VGtHnj3iKE25EkgkuTO4MxX0O9omksJeJSubG3E=; b=iykgaAmRCeqZ3g0/X+WwpRrdniHkBArf6+qyTYiwHYM8cuC1TyZEbCpaVNZEPYRU17v/Mod1uZundhrnIVGpb9u7VBvftVCYOgPm4Kbxq7ohLLm4Qo6lZsOjE+cPopQSISGtB3h1vq7EN+SNpPXsQrkY6q0MmX2CppJia0c1v0c= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1315.namprd05.prod.outlook.com (10.160.183.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.3; Wed, 7 Jun 2017 18:13:28 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1157.010; Wed, 7 Jun 2017 18:13:28 +0000 From: Kent Watsen To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" Thread-Topic: [netmod] draft-ietf-netmod-syslog-model-14 Signing Options Thread-Index: AQHS37nDXcXoaZtbs0+6sWnK2+6P1A== Date: Wed, 7 Jun 2017 18:13:28 +0000 Message-ID: <64ACB130-D685-4A54-AD28-92A7E908AB30@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1315; 7:FGu51nf/bowQAmJNZ9GrmBcy1jiAuWdcn/hsKAieDmgpmmRV8XZIvN2D/4EswOTLzeYVWvGvshIhn2WbMGs05/Sdf3/RclN0wPWcNzKFMP+LOT/o75v6MqgCpNT4zpnEmschX7LW7Wb2AU3AdxrolNX2lsNaoGXkzmtdzj7CuMFh0vrdkkVEYCBD/3wOLIVUrRZZ3c8043a63Yrgg19GMi0klM1X/7s9LXn8+OHT/lLs0ysbuxPhXPCm3NT7km/vg4YovQxGFWlALwMLkpuQFHwTXHTyN4UBuhXq9kCGfFsKonYNP7zNScdQifMowtHmn3l+i+wALikDXenbxvS3qA== x-ms-traffictypediagnostic: BN3PR0501MB1315: x-ms-office365-filtering-correlation-id: f0a742fa-f0d0-4505-8f75-08d4add0e5c8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0501MB1315; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1315; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1315; x-forefront-prvs: 03319F6FEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39450400003)(39860400002)(39410400002)(305945005)(966005)(66066001)(3846002)(53936002)(82746002)(6512007)(25786009)(189998001)(38730400002)(102836003)(6116002)(2900100001)(6246003)(6306002)(83716003)(99286003)(229853002)(14454004)(83506001)(4001350100001)(2501003)(230783001)(2906002)(86362001)(5660300001)(81166006)(6506006)(478600001)(7736002)(77096006)(3280700002)(8936002)(50986999)(122556002)(6436002)(6486002)(36756003)(3660700001)(54356999)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1315; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2017 18:13:28.3790 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1315 Archived-At: Subject: Re: [netmod] draft-ietf-netmod-syslog-model-14 Signing Options X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 18:13:32 -0000 SGkgQ2x5ZGUsDQoNClNpbmNlIG5vIGNvbmNlcm5zIGhhdmUgYmVlbiByYWlzZWQsIHNob3VsZCB3 ZSBiZSBleHBlY3RpbmcgYW4gdXBkYXRlZCBzeXNsb2cgZHJhZnQgc2hvcnRseT8NCg0KS2VudCAv LyBhcyBzaGVwaGVyZA0KDQotLQ0KDQpIaSwNCg0KQXMgcGFydCBvZiB0aGUgbGFzdCBmZXcgc3Rl cHMgYmVmb3JlIGFnYWluIGNhbGxpbmcgZm9yIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1uZXRt b2Qtc3lzbG9nLW1vZGVsLTE0LCB3ZSBhcmUgYWRkaW5nIGNlcnRpZmljYXRlIHN1cHBvcnQgdG8g dGhlIHNpZ25pbmctb3B0aW9ucyBjb250YWluZXIuIFJGQyA1ODQ4OiBTaWduZWQgU3lzbG9nIE1l c3NhZ2VzIGlzIHRoZSBSRkMgdGhhdCBnb3Zlcm5zIHRoaXMgc2VjdGlvbi4NCg0KVGhlIHNpZ25p bmctb3B0aW9ucyBjb250YWluZXIgcmVzaWRlcyB3aXRoaW4gdGhlIHJlbW90ZSBhY3Rpb24gZGVz dGluYXRpb24gbGlzdCBzZWN0aW9uIG9mIHRoZSBtb2RlbC4gVGhpcyBtZWFucyBzaWduaW5nLW9w dGlvbnMgd2lsbCBiZSBjb25maWd1cmFibGUgZm9yIGVhY2ggcmVtb3RlIGRlc3RpbmF0aW9uLg0K DQpSRkMgNTg0OCBzdXBwb3J0cyBmb3VyIHNpZ25hdHVyZSBncm91cHMgYXMgZGVmaW5lZCBpbiBz ZWN0aW9uIDQuMi4zIFNpZ25hdHVyZSBHcm91cCBhbmQgU2lnbmF0dXJlIFByaW9yaXR5IG9mIHRo ZSBSRkM6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg0OCNzZWN0aW9uLTQuMi4z DQoNCldlIGFyZSBwcm9wb3NpbmcgdG8gbGltaXQgb3VyIHN1cHBvcnQgdG8gU2lnbmF0dXJlIEdy b3VwIDAgd2hpY2ggY292ZXJzIHRoZSBjYXNlIGZvciBhZG1pbmlzdHJhdG9ycyB3aG8gd2FudCBh bGwgbWVzc2FnZXMgb2YgYSBzeXNsb2cgc3RyZWFtIHRvIGJlIHNpZ25lZCBhbmQgU2lnbmF0dXJl IEJsb2NrcyB0byBiZSBzZW50IHRvIGEgc2luZ2xlIGRlc3RpbmF0aW9uLiAgV2UgYmVsaWV2ZSB0 aGlzIGNhc2UgY292ZXJzIGFsbCBkZXBsb3ltZW50IHNjZW5hcmlvcyB0aGF0IGFyZSBjb21tb25s eSBlbmNvdW50ZXJlZC4gIA0KDQpTdXBwb3J0IGZvciBTaWduYXR1cmUgR3JvdXBzIDEgKGVhY2gg UFJJIHZhbHVlIGlzIGFzc29jaWF0ZWQgd2l0aCBpdHMgb3duIFNpZ25hdHVyZSBHcm91cCksIDIg KGVhY2ggU2lnbmF0dXJlIEdyb3VwIGNvbnRhaW5zIGEgcmFuZ2Ugb2YgUFJJIHZhbHVlcyksIGFu ZCAzIChTaWduYXR1cmUgR3JvdXBzIGFyZSBuZWdvdGlhdGVkIHRocm91Z2ggYSBwcml2YXRlIGFy cmFuZ2VtZW50KSBjb3VsZCBiZSBhZGRlZCB0byB0aGUgbW9kZWwgbGF0ZXIgdGhyb3VnaCBhdWdt ZW50YXRpb24uDQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgY29uY2VybnMg YWJvdXQgdGhpcy4NCg0KVGhhbmtzLA0KDQpDbHlkZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoN Cg0K From nobody Wed Jun 7 12:50:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717D3129B38 for ; Wed, 7 Jun 2017 12:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf2430xT71sa for ; Wed, 7 Jun 2017 12:50:31 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8BA127241 for ; Wed, 7 Jun 2017 12:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2464; q=dns/txt; s=iport; t=1496865031; x=1498074631; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=G+cf1Q9FatzqH4OcZMTVt9dMwonwg9gp0VXQi2XrUkI=; b=FLtCpzJh6wCUzRbrojnGHoVldFigoX4eRn7mScWE9FMXNLbo0+t6mbj8 FB/SZtC6lkQs8ATIfuCu1DDSB50JGL5AxWS9MGrIKARJ0Uwm0n9la1ZbT lGlxA8zzsU8ngAhV668eNkcVhn7sfPF/sAGUqM8x7MW1YeSfGf2X3tyTq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAABhWDhZ/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgystYoENB4NsihiRR5YhghAhC4UuSgIagls/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRkCAQMBARsGETobAgEIDgwCJgICAiULFRACBAESiisQrmqCJot/AQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWBC4VWggsLgmqER4M1MIIxBZ45AockjBKCBoU+ijy?= =?us-ascii?q?UZgEfOIEKdBVGEgGEb4IGdgEBh0GBMYENAQEB?= X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208";a="436508174" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 19:50:30 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v57JoUgj023110 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Jun 2017 19:50:30 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Jun 2017 14:50:30 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Wed, 7 Jun 2017 14:50:30 -0500 From: "Clyde Wildes (cwildes)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] draft-ietf-netmod-syslog-model-14 Signing Options Thread-Index: AQHS37nDXcXoaZtbs0+6sWnK2+6P1KIZraaA Date: Wed, 7 Jun 2017 19:50:30 +0000 Message-ID: <1B851597-5BC1-4992-8644-A5CB7D289CDD@cisco.com> References: <64ACB130-D685-4A54-AD28-92A7E908AB30@juniper.net> In-Reply-To: <64ACB130-D685-4A54-AD28-92A7E908AB30@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.145.4] Content-Type: text/plain; charset="utf-8" Content-ID: <2FA69DEEFBC44D4FB0DB63075C73985B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] draft-ietf-netmod-syslog-model-14 Signing Options X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 19:50:33 -0000 S2VudCwNCg0KWWVzISBTb3JyeSBmb3IgdGhlIGRlbGF5Lg0KDQpDbHlkZQ0KDQpPbiA2LzcvMTcs IDExOjEzIEFNLCAiS2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCg0K ICAgIEhpIENseWRlLA0KICAgIA0KICAgIFNpbmNlIG5vIGNvbmNlcm5zIGhhdmUgYmVlbiByYWlz ZWQsIHNob3VsZCB3ZSBiZSBleHBlY3RpbmcgYW4gdXBkYXRlZCBzeXNsb2cgZHJhZnQgc2hvcnRs eT8NCiAgICANCiAgICBLZW50IC8vIGFzIHNoZXBoZXJkDQogICAgDQogICAgLS0NCiAgICANCiAg ICBIaSwNCiAgICANCiAgICBBcyBwYXJ0IG9mIHRoZSBsYXN0IGZldyBzdGVwcyBiZWZvcmUgYWdh aW4gY2FsbGluZyBmb3IgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9k ZWwtMTQsIHdlIGFyZSBhZGRpbmcgY2VydGlmaWNhdGUgc3VwcG9ydCB0byB0aGUgc2lnbmluZy1v cHRpb25zIGNvbnRhaW5lci4gUkZDIDU4NDg6IFNpZ25lZCBTeXNsb2cgTWVzc2FnZXMgaXMgdGhl IFJGQyB0aGF0IGdvdmVybnMgdGhpcyBzZWN0aW9uLg0KICAgIA0KICAgIFRoZSBzaWduaW5nLW9w dGlvbnMgY29udGFpbmVyIHJlc2lkZXMgd2l0aGluIHRoZSByZW1vdGUgYWN0aW9uIGRlc3RpbmF0 aW9uIGxpc3Qgc2VjdGlvbiBvZiB0aGUgbW9kZWwuIFRoaXMgbWVhbnMgc2lnbmluZy1vcHRpb25z IHdpbGwgYmUgY29uZmlndXJhYmxlIGZvciBlYWNoIHJlbW90ZSBkZXN0aW5hdGlvbi4NCiAgICAN CiAgICBSRkMgNTg0OCBzdXBwb3J0cyBmb3VyIHNpZ25hdHVyZSBncm91cHMgYXMgZGVmaW5lZCBp biBzZWN0aW9uIDQuMi4zIFNpZ25hdHVyZSBHcm91cCBhbmQgU2lnbmF0dXJlIFByaW9yaXR5IG9m IHRoZSBSRkM6DQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4NDgjc2VjdGlv bi00LjIuMw0KICAgIA0KICAgIFdlIGFyZSBwcm9wb3NpbmcgdG8gbGltaXQgb3VyIHN1cHBvcnQg dG8gU2lnbmF0dXJlIEdyb3VwIDAgd2hpY2ggY292ZXJzIHRoZSBjYXNlIGZvciBhZG1pbmlzdHJh dG9ycyB3aG8gd2FudCBhbGwgbWVzc2FnZXMgb2YgYSBzeXNsb2cgc3RyZWFtIHRvIGJlIHNpZ25l ZCBhbmQgU2lnbmF0dXJlIEJsb2NrcyB0byBiZSBzZW50IHRvIGEgc2luZ2xlIGRlc3RpbmF0aW9u LiAgV2UgYmVsaWV2ZSB0aGlzIGNhc2UgY292ZXJzIGFsbCBkZXBsb3ltZW50IHNjZW5hcmlvcyB0 aGF0IGFyZSBjb21tb25seSBlbmNvdW50ZXJlZC4gIA0KICAgIA0KICAgIFN1cHBvcnQgZm9yIFNp Z25hdHVyZSBHcm91cHMgMSAoZWFjaCBQUkkgdmFsdWUgaXMgYXNzb2NpYXRlZCB3aXRoIGl0cyBv d24gU2lnbmF0dXJlIEdyb3VwKSwgMiAoZWFjaCBTaWduYXR1cmUgR3JvdXAgY29udGFpbnMgYSBy YW5nZSBvZiBQUkkgdmFsdWVzKSwgYW5kIDMgKFNpZ25hdHVyZSBHcm91cHMgYXJlIG5lZ290aWF0 ZWQgdGhyb3VnaCBhIHByaXZhdGUgYXJyYW5nZW1lbnQpIGNvdWxkIGJlIGFkZGVkIHRvIHRoZSBt b2RlbCBsYXRlciB0aHJvdWdoIGF1Z21lbnRhdGlvbi4NCiAgICANCiAgICBQbGVhc2UgbGV0IHVz IGtub3cgaWYgeW91IGhhdmUgYW55IGNvbmNlcm5zIGFib3V0IHRoaXMuDQogICAgDQogICAgVGhh bmtzLA0KICAgIA0KICAgIENseWRlDQogICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQog ICAgbmV0bW9kQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCiAgICANCiAgICANCiAgICANCg0K From nobody Wed Jun 7 13:28:29 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D88129AC7; Wed, 7 Jun 2017 13:28:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149686730863.2679.14876996352292119933@ietfa.amsl.com> Date: Wed, 07 Jun 2017 13:28:28 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-15.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 20:28:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : A YANG Data Model for Syslog Configuration Authors : Clyde Wildes Kiran Koushik Filename : draft-ietf-netmod-syslog-model-15.txt Pages : 29 Date : 2017-06-07 Abstract: This document describes a data model for the configuration of syslog. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-15 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-15 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 Jun 7 13:45:01 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E5A1205F0 for ; Wed, 7 Jun 2017 13:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9OxjWGuaGHp for ; Wed, 7 Jun 2017 13:44:58 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64671131491 for ; Wed, 7 Jun 2017 13:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=432; q=dns/txt; s=iport; t=1496868297; x=1498077897; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3t0Aaz5FrGaRIkbaFACWJrQy+q3+sFx5v0Hgko91Wjk=; b=PyKz7QAIm/2qy9m/fSRKI/kxX/XSgj5fIkBwjEV6pYGnMroRKUN0dQqN EYt70bCldhJKKHiG7dFK/NgKrghWWwRMaCXbMkn9tK2d+PezNBzeku8af OeoRZqtDn0QfLO7+nF7nBVlIPucoqGIk1vuU8UpMGQKA7Cjk66UgzNqD+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAQDoZDhZ/4cNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1higRSDbIoYp2mCEDCFdAIagls/GAECAQEBAQEBAWsdC4UZBiMRVQI?= =?us-ascii?q?BCBoCJgICAjAVEAIEij4QrneCJot/AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC?= =?us-ascii?q?4VWgguCdYMmgUSDEjCCMQWeOQKTNguBYwGQEZRmAR84P0t0FVgBhnWJaoENAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208";a="432183049" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jun 2017 20:44:56 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v57KiunL025056 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 Jun 2017 20:44:56 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Jun 2017 15:44:55 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Wed, 7 Jun 2017 15:44:55 -0500 From: "Clyde Wildes (cwildes)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-15.txt Thread-Index: AQHS38ynAiEWAedgQUCGtpB7dSe986IZvLaA Date: Wed, 7 Jun 2017 20:44:55 +0000 Message-ID: References: <149686730863.2679.14876996352292119933@ietfa.amsl.com> In-Reply-To: <149686730863.2679.14876996352292119933@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.145.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-15.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 20:45:00 -0000 SGksDQoNClRoZSBsYXRlc3QgZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTE1IGNvbnRh aW5zIHVwZGF0ZXMgdG8gdGhlIHNpZ25pbmctb3B0aW9ucyBjb250YWluZXIgYXMgYSByZXN1bHQg b2YgYSByZXZpZXcgYnkgS2VudCBXYXRzZW4gYW5kIEFsZXggQ2xlbW0uDQoNCkRpZmZzIGNhbiBi ZSBzZWVuIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYt bmV0bW9kLXN5c2xvZy1tb2RlbC0xNCZ1cmwyPWRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2Rl bC0xNQ0KDQpUaGFua3MsDQoNCkNseWRlIA0KDQo= From nobody Wed Jun 7 14:24:27 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 712FB127180; Wed, 7 Jun 2017 14:24:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Deborah Brungard To: "The IESG" Cc: draft-ietf-netmod-yang-model-classification@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149687066636.2550.12242336741129714948.idtracker@ietfa.amsl.com> Date: Wed, 07 Jun 2017 14:24:26 -0700 Archived-At: Subject: [netmod] Deborah Brungard's Yes on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 21:24:26 -0000 Deborah Brungard has entered the following ballot position for draft-ietf-netmod-yang-model-classification-07: Yes 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-netmod-yang-model-classification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My 2cents on the "type" discussion: The sentence in Section 1 Introduction does cause confusion "A number of module types have created substantial discussion" as it's describing the possible name duplication of a module in two different "layers", not types. Will read better if remove "types". I'm very surprised that Adrian on his reading did not question the use of "layers" to distinguish between services and network element modules. To me, with my layer hat on, this is very confusing. My suggestion would be to use the generic word "types" for "layers" and use "class" to distinguish modules which are standard, vendor, user. Vendor/user modules may/may not overlap with standard modules functionality-wise, they also may be modules with no interest to be standardized, so they are not necessarily associated with maturity/finer aging:-) From nobody Wed Jun 7 15:51:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA311200FC; Wed, 7 Jun 2017 15:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=noFn+uQ3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L5YLV2UQ 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 ZxWLn7ITnAVs; Wed, 7 Jun 2017 15:51:31 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9BB120454; Wed, 7 Jun 2017 15:51:28 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B7B7920B8E; Wed, 7 Jun 2017 18:51:27 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 07 Jun 2017 18:51:27 -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:x-sasl-enc; s=fm1; bh=J1hYc4Rb7YFFR5jWYo gEbdVrw4o+nakW32md4nFf6uk=; b=noFn+uQ3viY+48ZYYahQTrfof/BZZ+gHaG OmAsPrcbaZMGNve3JPG8T8HlX9ril//yZYz1M+HS/BRep0iDcJaue7eC/8caZ/CI FYsgW3dvvjMATEoq9uJvIs+/SNEn2/zJc+rELvZQwnDf2YsHvJMj1NPcZDJz6Xb7 qZmBWE6uc4uKV2V/TBugLzNg7DUohdJ9cXTh70d7j0wt5xAbSXD5OxWTPP5up1eG t67GxpEaFRDoUMxTW1Q+21g+VWgjTzCl5wIxPsjiBMb4KarR970UOmrbkT8U4toY hxnRVWox4hpol/SmRPBlH/4/plh+rKW9x0mBD9yXZmAAdbdWC5qA== 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:x-sasl-enc; s= fm1; bh=J1hYc4Rb7YFFR5jWYogEbdVrw4o+nakW32md4nFf6uk=; b=L5YLV2UQ arafe9F9NDALndirGr+mRw0CmH2fVzYXesqWNh7tsCSvr4p0izVe5ovsDlxe2rOL e1WxUtfwtkjWzfWRYjAJOalyBVvyy0nB03O454UG8YVkN8rX+YDt2pRPOWX6kbXM 05Ed/iX42Yz72TGkQKwirUnJxioS9uEaH7t9Oap5vK+zM+xKAOF0b4FOZK9LIzO/ vS2LuCzdTo22EVG1g32BkM9opcO5DgvLq6gRqWLgW3416XagnfrAFmzGxbc8Wwed qco1WU5/yFxIGxmwzBMcRTY70/48DbxLMtjFPXqTasdju+3kpPVoPSUac2QjrwNo DPZ2tVjk2I8d9w== X-ME-Sender: X-Sasl-enc: ZG04CSqyUUjt+DgoSuPK+JyZZBZ0T1x8LWvkMhTak7AY 1496875887 Received: from [10.24.33.193] (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id B65AF2479C; Wed, 7 Jun 2017 18:51:26 -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: <149546571178.4974.504818721239081419@ietfa.amsl.com> Date: Wed, 7 Jun 2017 18:51:24 -0400 Cc: "gen-art >> General area reviewing team" , draft-ietf-netmod-yang-model-classification.all@ietf.org, netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149546571178.4974.504818721239081419@ietfa.amsl.com> To: Pete Resnick X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] [Gen-art] Genart telechat review of draft-ietf-netmod-yang-model-classification-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 22:51:33 -0000 Pete, thanks for your review. I entered a No Objection ballot. Alissa > On May 22, 2017, at 11:08 AM, Pete Resnick = wrote: >=20 > Reviewer: Pete Resnick > 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-netmod-yang-model-classification-07 > Reviewer: Pete Resnick > Review Date: 2017-05-22 > IETF LC End Date: 2017-05-14 > IESG Telechat date: 2017-06-08 >=20 > Summary: Ready >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: None >=20 > Thanks for addressing my comments in the Last Call review. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Jun 8 05:20:41 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DED541201F2; Thu, 8 Jun 2017 05:20:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Deborah Brungard To: "The IESG" Cc: draft-ietf-netmod-yang-model-classification@ietf.org, Lou Berger , netmod-chairs@ietf.org, lberger@labn.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149692443990.25640.5053663018813151380.idtracker@ietfa.amsl.com> Date: Thu, 08 Jun 2017 05:20:39 -0700 Archived-At: Subject: [netmod] Deborah Brungard's Yes on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 12:20:40 -0000 Deborah Brungard has entered the following ballot position for draft-ietf-netmod-yang-model-classification-07: Yes 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-netmod-yang-model-classification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [Added comment on definition of SDO] My 2cents on the "type" discussion: The sentence in Section 1 Introduction does cause confusion "A number of module types have created substantial discussion" as it's describing the possible name duplication of a module in two different "layers", not types. Will read better if remove "types". I'm very surprised that Adrian on his reading did not question the use of "layers" to distinguish between services and network element modules. To me, with my layer hat on, this is very confusing. My suggestion would be to use the generic word "types" for "layers" and use "class" to distinguish modules which are standard, vendor, user. Vendor/user modules may/may not overlap with standard modules functionality-wise, they also may be modules with no interest to be standardized, so they are not necessarily associated with maturity/finer aging:-) I find the definition of SDO and vendor confusing. In the draft, it defines an SDO as published by a standards development organization. It provides the example of IETF, IEEE, MEF. It defines a vendor-specific module as "..industry consortia and opensource projects".."openly published". This is blurring the lines of SDO and industry consortia, e.g. MEF is a forum (industry consortia) whereas IETF and IEEE (and ITU) are SDOs. It's based on organizational criteria, and it's in the organization's description of their product e.g. standards, specifications. Some users don't care, others do. To prevent IETF from being pulled into the hornet's nest, suggest SDO be defined as only IETF, and separate labels for vendor and industry consortia (includes opensource/openly published). From nobody Thu Jun 8 06:52:39 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC6F126BF6; Thu, 8 Jun 2017 06:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOXV1bfkBTX2; Thu, 8 Jun 2017 06:52:30 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A13412441E; Thu, 8 Jun 2017 06:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2708; q=dns/txt; s=iport; t=1496929949; x=1498139549; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/g8S7KMOJdgxmG0HKlYr22zKA2t6mTuDFzknWAcBqtU=; b=eDPIG16uefenW+kWyk2cZFNLeXtCFJNM7SjmFI2gmbAyK/Y1rqqLfAXZ /Mrtlc17hEpaySSXCOS9Zc8SDOq6EVA5ETMKO7bEBascQGPxsUue/zF+d H5WyL/N0FAbnCDedot4+xpwTSB4vSZ/KC2u/I6okS+b0UVKFJYq7mIt6q A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAQBGVjlZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqBDYNzihhzkFYhlgKCES6FdgKDORgBAgEBAQEBAQFrKIUZAQU?= =?us-ascii?q?jFUEQCw4KAgImAgJXBgEMCAEBiicQsF6CJowAAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEZBYELhVaCCwuCaoQ7EgGDLoJhAQSJTYZmjgeHKIwUggaFPoNLI4ZPjCuIPR8?= =?us-ascii?q?4fwswIQgbFUeFChwZgU4+NgGHUIIwAQEB?= X-IronPort-AV: E=Sophos;i="5.39,315,1493683200"; d="scan'208";a="655277908" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2017 13:52:24 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v58DqOIP019634; Thu, 8 Jun 2017 13:52:24 GMT To: Deborah Brungard , The IESG Cc: draft-ietf-netmod-yang-model-classification@ietf.org, Lou Berger , netmod-chairs@ietf.org, netmod@ietf.org References: <149692443990.25640.5053663018813151380.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: Date: Thu, 8 Jun 2017 15:52:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149692443990.25640.5053663018813151380.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Deborah Brungard's Yes on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 13:52:32 -0000 On 6/8/2017 2:20 PM, Deborah Brungard wrote: > Deborah Brungard has entered the following ballot position for > draft-ietf-netmod-yang-model-classification-07: Yes > > 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-netmod-yang-model-classification/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [Added comment on definition of SDO] > > My 2cents on the "type" discussion: > > The sentence in Section 1 Introduction does cause confusion "A number of module > types have created substantial discussion" as it's describing the possible name > duplication of a module in two different "layers", not types. Will read better > if remove "types". That makes sense. > > I'm very surprised that Adrian on his reading did not question the use of > "layers" to distinguish between services and network element modules. To me, > with my layer hat on, this is very confusing. > > My suggestion would be to use the generic word "types" for "layers" and use > "class" to distinguish modules which are standard, vendor, user. Vendor/user > modules may/may not overlap with standard modules functionality-wise, they also > may be modules with no interest to be standardized, so they are not necessarily > associated with maturity/finer aging:-) > > I find the definition of SDO and vendor confusing. In the draft, it defines an > SDO as published by a standards development organization. It provides the > example of IETF, IEEE, MEF. It defines a vendor-specific module as "..industry > consortia and opensource projects".."openly published". This is blurring the > lines of SDO and industry consortia, e.g. MEF is a forum (industry consortia) > whereas IETF and IEEE (and ITU) are SDOs. It's based on organizational > criteria, and it's in the organization's description of their product e.g. > standards, specifications. Some users don't care, others do. To prevent IETF > from being pulled into the hornet's nest, suggest SDO be defined as only IETF, > and separate labels for vendor and industry consortia (includes > opensource/openly published). Alliteratively, I propose to remove MEF from the list of examples. Regards, Benoit > > > . > From nobody Thu Jun 8 07:14:22 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5F61287A5; Thu, 8 Jun 2017 07:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 cn7t0Ewth2ZW; Thu, 8 Jun 2017 07:14:13 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BBE126D74; Thu, 8 Jun 2017 07:14:12 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v58ECU6p037123; Thu, 8 Jun 2017 10:14:09 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 2ay84y81rm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Jun 2017 10:14:09 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v58EE8uj000875; Thu, 8 Jun 2017 10:14:08 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v58EDvbt000669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Jun 2017 10:14:03 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 8 Jun 2017 14:13:42 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.182]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0319.002; Thu, 8 Jun 2017 10:13:15 -0400 From: "BRUNGARD, DEBORAH A" To: Benoit Claise , The IESG CC: "draft-ietf-netmod-yang-model-classification@ietf.org" , Lou Berger , "netmod-chairs@ietf.org" , "netmod@ietf.org" Thread-Topic: Deborah Brungard's Yes on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) Thread-Index: AQHS4FGqcZ82OlWdHkCe23v8wEd57aIbP1WA///CajA= Date: Thu, 8 Jun 2017 14:13:14 +0000 Message-ID: References: <149692443990.25640.5053663018813151380.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.254.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080253 Archived-At: Subject: Re: [netmod] Deborah Brungard's Yes on draft-ietf-netmod-yang-model-classification-07: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 14:14:14 -0000 DQoNCj4gQWxsaXRlcmF0aXZlbHksIEkgcHJvcG9zZSB0byByZW1vdmUgTUVGIGZyb20gdGhlIGxp c3Qgb2YgZXhhbXBsZXMuDQo+IA0KPiBSZWdhcmRzLCBCZW5vaXQNCltkZWJvcmFoXSANClNvdW5k cyBnb29kLQ0KRGVib3JhaA0KDQo+ID4NCj4gPg0KPiA+IC4NCj4gPg0KDQo= From nobody Fri Jun 9 03:55:27 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4661293EC for ; Fri, 9 Jun 2017 03:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 hxQ8UN0chUFv for ; Fri, 9 Jun 2017 03:55:24 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0130.outbound.protection.outlook.com [104.47.2.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434A5124217 for ; Fri, 9 Jun 2017 03:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xYvM9ynJvDCPZC6I2A22vCkhX3XwpBfSUTU4hl4WFCM=; b=EUCJLKsYeTCrijQg2P2L36deDpPv9N86j0tfQfwRe9xvFVPHwcV3r08+PFysVF+T9ejYvYNmcem7naEMDEC3iFiO091cXPhgxEExbgMeqDj3JZzwm1Ix28fOh79hkclNNR1vSql0PztZUALrnY2Bvj6iCRhSAZMkUZvSg4GoUkc= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0803.eurprd07.prod.outlook.com (10.161.71.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.3; Fri, 9 Jun 2017 10:55:21 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::655e:1682:2089:a05c]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::655e:1682:2089:a05c%16]) with mapi id 15.01.1178.006; Fri, 9 Jun 2017 10:55:21 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "netmod@ietf.org" Thread-Topic: Question on intefaces-state model Thread-Index: AdLhDRC34rNQajuWS5+4b+qYQggHyQ== Date: Fri, 9 Jun 2017 10:55:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0803; 7:FJ1mGu1xYDVD2nPH2wWXx3L0mLwTviTcB/wkNlIXMG3z5QodDjvVcSb3KNU/eVs7rfMhpuSgZL2lHz5StBpSd7wBDQWvG4h616ciy8ZFibrlGdV2k4Ax4aAaCv7IFeJ0aM1ckxmkv1TzpWyjFESlRHZvd3AS5/KSgPPwXc6XmSPtpneTI79NPNmeLzet3zQcg48OHNAkbbLn6QqSDA+rzgmarhDtiKXB4QOReJvQKXz0duMezmRxG1xKxn7rIhDhM59VZOa0Jq6LxtZLumGQCOQ8LJue6gQghu5xg0sb7fG9JLQ9T3e4JNWe/aPsCLhGbvIpN6zGkkIjDmlxLs/ZxA== x-ms-traffictypediagnostic: AM2PR07MB0803: x-ms-office365-filtering-correlation-id: 38cfd28d-1403-4ae9-cb42-08d4af260618 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM2PR07MB0803; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0803; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0803; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39850400002)(39400400002)(39410400002)(39450400003)(39860400002)(2906002)(189998001)(5640700003)(2351001)(14454004)(9326002)(6506006)(6436002)(86362001)(55016002)(54896002)(6306002)(9686003)(33656002)(38730400002)(110136004)(53936002)(25786009)(3480700004)(99936001)(66066001)(54356999)(99286003)(50986999)(8936002)(2900100001)(1730700003)(8676002)(81166006)(3280700002)(6916009)(7696004)(5630700001)(5250100002)(2501003)(3660700001)(3846002)(6116002)(102836003)(790700001)(478600001)(7736002)(5660300001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0803; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02E2_01D2E11F.A4DD0670" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2017 10:55:20.9801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0803 Archived-At: Subject: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 10:55:26 -0000 ------=_NextPart_000_02E2_01D2E11F.A4DD0670 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02E3_01D2E11F.A4DD2D80" ------=_NextPart_001_02E3_01D2E11F.A4DD2D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We have a question regarding the statistics container as defined in the interfaces-state model. This container defines one mandatory leaf (discontinuity-time) while all other leafs are optional. What is the rationale behind this leaf being mandatory and not an optional field? It does not make a lot of sense to return a discontinuity-time value and no counters if none of the counters are relevant for a specific interface. Another alternative could be to add, via a deviation, a when clause to the container indicating for which ifType(s) the container is (or is not) present. But that would lead to not supporting the IETF interfaces model to the full extent. Regards, Bart ------=_NextPart_001_02E3_01D2E11F.A4DD2D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have a question regarding the statistics container as = defined in the interfaces-state model.  This container defines one = mandatory leaf (discontinuity-time) while all other leafs are = optional.  What is the rationale behind this leaf being mandatory = and not an optional field?

It does not make a lot of sense to = return a discontinuity-time value and no counters if none of the = counters are relevant for a specific interface.

Another alternative could be to = add, via a deviation, a when clause to the container indicating for = which ifType(s) the container is (or is not) present. But that would = lead to not supporting the IETF interfaces model to the full = extent.

 

Regards, Bart

 

------=_NextPart_001_02E3_01D2E11F.A4DD2D80-- ------=_NextPart_000_02E2_01D2E11F.A4DD0670 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA2MDkxMDU1MTdaMCMGCSqGSIb3DQEJBDEWBBTGuVZI WVSV1epFDO7fCAwVJs4XIjCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAEW0WXdderPkdfB3kfTqgUruGzHkt7F5FzyrEu76SmjxZnQKG+0QHIG/cA0R UM17xAOFbVSWoHN+K4KeStG2+c7nMr0cgrTlOQTlfYdIwh+wlfG6872NHzYaG5JCr+GZa4zfmqyO k648QB7+IHoBAyD7ufcDOHk3JBDpmVvImMOkycOjDTVtucRRA9Gept6w18b2c1hEvDzz1vv40Egh v9hI3fYN/N73VZoZSSg0LwZxanTlxhq6lnvD1fsAA0/f9QuAml96AvPm3lP0r8PCw3y4E2iq7+bF px3AuYCXpkO0qm9Zm7IA49THbVABstIqgOx3zRiU2miYY3mDJoSSw0MAAAAAAAA= ------=_NextPart_000_02E2_01D2E11F.A4DD0670-- From nobody Fri Jun 9 06:56:47 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED5712441E for ; Fri, 9 Jun 2017 06:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXSXgdsuY5eB for ; Fri, 9 Jun 2017 06:56:42 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7FA1241FC for ; Fri, 9 Jun 2017 06:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6269; q=dns/txt; s=iport; t=1497016602; x=1498226202; h=to:from:subject:message-id:date:mime-version; bh=L0JRrsaGIy/GsVc19/SXZ1aKFc6/l/msAwLjUkEDyyw=; b=BEfekNn8rBS5tHO0v7d9dY8jHTYXwwqj2YqsQGtu4LHpSFpP17YEWiPD DwVlf/P93nn/RiDTlpGdlpG6S7UCsCfFdeH4IP4Sks0O+Srir3DVqv9qb moVcEyMCeXqU1kPRI9yi93akEm//Ike6pPxS20bS/A29ljwqjUY2LYGPr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAgDIqDpZ/xbLJq1cHAEBBAEBCgEBg?= =?us-ascii?q?yyBD4UBihhzkFiQa4U5ghEsiToYAQIBAQEBAQEBayiFQoEDMAJLFA0IAQEXihA?= =?us-ascii?q?QsCmCJiuLQAEBAQcBAQEBHwWGYYFgKwuKZoJhBZB2jUaHKFuLPoIGhUODS4Zyj?= =?us-ascii?q?C2DU4RqHziBCjAhCBsVUIFxhRc+hzYqghUBAQE?= X-IronPort-AV: E=Sophos;i="5.39,317,1493683200"; d="scan'208,217";a="653481860" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2017 13:56:39 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v59Dud5D008934 for ; Fri, 9 Jun 2017 13:56:39 GMT To: NETMOD Working Group From: Benoit Claise Message-ID: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> Date: Fri, 9 Jun 2017 15:56:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------1A6FED007EFEC8051BB5CE9F" Content-Language: en-US Archived-At: Subject: [netmod] Important: Guidelines for YANG module authors X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 13:56:45 -0000 This is a multi-part message in MIME format. --------------1A6FED007EFEC8051BB5CE9F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, Now that the new NETMOD and NETCONF charters have been approved, it's time to think about the guidelines for YANG module authors. The Network Management Datastore Architecture (NMDA) addresses the so-called "OpState problem" that has been the subject of much discussion in the IETF. NMDA is still in development, and there will be a transition period before NMDA solutions are universally available. The NETMOD Datastore Design Team and the Routing Yang Architecture Design Team have worked with Alia and Benoit to create initial guidelines for how the NMDA, as defined in draft-ietf-netmod-revised-datastores , impacts Yang models. The draft-dsdt-nmda-guidelines individual draft was foundational in helping creating those guidelines. If you have questions or concerns on how these guidelines should apply to work of interest, please contact your WG Chairs or ADs. It is our strong recommendation, as ADs with agreement from the NETMOD WG Chairs, that models SHOULD move as quickly as possible to the NMDA. The specific approach to be taken for models being developed now and during the NMDA transition period should be based on both the expected usage and the maturity of the data model. 1. New models and models that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible. 2. Models that require immediate support for "in use" and "system created" information SHOULD be structured for NMDA. Then derived versions of these models SHOULD be created, either by hand or with suitable tools, that follow the current modeling strategies. In some cases, the non-NMDA model may be an existing model and not derived from the NMDA model. In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. The non-NMDA module names should include ’-state’ appended. We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, and all others who helped develop these guidelines. Regards, Alia Atlas, Routing AD Deborah Brungard, Routing AD Alvaro Retana, Routing AD Warren Kumari, Operations & Management AD Benoit Claise, Operations & Management AD --------------1A6FED007EFEC8051BB5CE9F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

Now that the new NETMOD and NETCONF charters have been approved, it's time to think about the guidelines for YANG module authors.

The Network Management Datastore Architecture (NMDA) addresses the so-called "OpState problem" that has been the subject of much discussion in the IETF. NMDA is still in development, and there will be a transition period before NMDA solutions are universally available.

The NETMOD Datastore Design Team and the Routing Yang Architecture Design Team have worked with Alia and Benoit to create initial guidelines for how the NMDA, as defined in draft-ietf-netmod-revised-datastores, impacts Yang models. The draft-dsdt-nmda-guidelines individual draft was foundational in helping creating those guidelines.

If you have questions or concerns on how these guidelines should apply to work of interest, please contact your WG Chairs or ADs.

It is our strong recommendation, as ADs with agreement from the NETMOD WG Chairs, that models SHOULD move as quickly as possible to the NMDA. The specific approach to be taken for models being developed now and during the NMDA transition period should be based on both the expected usage and the maturity of the data model.

1. New models and models that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible.

2. Models that require immediate support for "in use" and "system created" information SHOULD be structured for NMDA. Then derived versions of these models SHOULD be created, either by hand or with suitable tools, that follow the current modeling strategies. In some cases, the non-NMDA model may be an existing model and not derived from the NMDA model. In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. The non-NMDA module names should include ’-state’ appended.

We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, and all others who helped develop these guidelines.

Regards,
Alia Atlas, Routing AD
Deborah Brungard, Routing AD
Alvaro Retana, Routing AD
Warren Kumari, Operations & Management AD
Benoit Claise, Operations & Management AD
--------------1A6FED007EFEC8051BB5CE9F-- From nobody Fri Jun 9 07:12:20 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513A1129483 for ; Fri, 9 Jun 2017 07:12:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 oe9mRDjcZwfM for ; Fri, 9 Jun 2017 07:12:16 -0700 (PDT) Received: from gproxy8.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 3ADAC12426E for ; Fri, 9 Jun 2017 07:12:16 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id A87581AB07A for ; Fri, 9 Jun 2017 08:12:15 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id WeCB1v00r2SSUrH01eCE55; Fri, 09 Jun 2017 08:12:15 -0600 X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=48vgC7mUAAAA:8 a=SJoBkxFSY3z_vumiJPcA:9 a=KMrDw2QKs0pXkGpL:21 a=TWgvJRPUaKaY2-84:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=UXd/Gwmaam7aNWHf3EUpyjMDm/5uCiVLOS03jfkUKPo=; b=T8xOfvOzzAWicD2FQjWwPWyd9y 47FqmI8uBSDsq+C8zJbWVjDa5g+6wyx7v6zvPqlzYoLqtyYerflUx6txJXKbfnM17FMe1xM3KUX7k Rz6wc9N7uoYdeNpWTzdDvPS5R; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:37746 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dJKe3-0000j4-O6; Fri, 09 Jun 2017 08:12:11 -0600 To: Benoit Claise , NETMOD Working Group References: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> From: Lou Berger Message-ID: <9acb5757-c520-b9a1-bff6-6a7aa67d776a@labn.net> Date: Fri, 9 Jun 2017 10:12:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dJKe3-0000j4-O6 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:37746 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] Important: Guidelines for YANG module authors X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 14:12:18 -0000 Benoit, Thanks for this! WG, Now would be a good time to take a look at, and comment on, draft-dsdt-nmda-guidelines also consider how this document impacts draft-ietf-netmod-rfc6087bis (particularly section 5.23). Optimally we could have a proposed revision to draft-ietf-netmod-rfc6087bis discussed on the list prior to Prague, but I know I'm being optimistic. Lou and Kent On 6/9/2017 9:56 AM, Benoit Claise wrote: > Dear all, > > Now that the new NETMOD and NETCONF charters have been approved, it's > time to think about the guidelines for YANG module authors. > > The Network Management Datastore Architecture (NMDA) addresses the > so-called "OpState problem" that has been the subject of much > discussion in the IETF. NMDA is still in development, and there will > be a transition period before NMDA solutions are universally available. > > The NETMOD Datastore Design Team and the Routing Yang Architecture > Design Team have worked with Alia and Benoit to create initial > guidelines for how the NMDA, as defined in > draft-ietf-netmod-revised-datastores > , > impacts Yang models. The draft-dsdt-nmda-guidelines > > individual draft was foundational in helping creating those guidelines. > > If you have questions or concerns on how these guidelines should apply > to work of interest, please contact your WG Chairs or ADs. > > It is our strong recommendation, as ADs with agreement from the NETMOD > WG Chairs, that models SHOULD move as quickly as possible to the NMDA. > The specific approach to be taken for models being developed now and > during the NMDA transition period should be based on both the expected > usage and the maturity of the data model. > > 1. New models and models that are not concerned with the operational > state of configuration information SHOULD immediately be structured to > be NMDA-compatible. > > 2. Models that require immediate support for "in use" and "system > created" information SHOULD be structured for NMDA. Then derived > versions of these models SHOULD be created, either by hand or with > suitable tools, that follow the current modeling strategies. In some > cases, the non-NMDA model may be an existing model and not derived > from the NMDA model. In all cases, the NMDA and non-NMDA modules > SHOULD be published in the same document, with NMDA modules in the > document main body and the non-NMDA modules in an Appendix. The use of > the non-NMDA model will allow temporary bridging of the time period > until NMDA implementations are available. The non-NMDA module names > should include ’-state’ appended. > > We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin > Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen > Schoenwaelder, and all others who helped develop these guidelines. > > Regards, > Alia Atlas, Routing AD > Deborah Brungard, Routing AD > Alvaro Retana, Routing AD > Warren Kumari, Operations & Management AD > Benoit Claise, Operations & Management AD > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jun 9 10:06:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5120A127010 for ; Fri, 9 Jun 2017 10:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=yumaworks-com.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 mHOlxlPOXM-M for ; Fri, 9 Jun 2017 10:06:27 -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 DB6331270A3 for ; Fri, 9 Jun 2017 10:06:26 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id v111so39669778wrc.3 for ; Fri, 09 Jun 2017 10:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IJ2qyjEzGrCUR0+QBWc6PVxF9nWe6jaq820IAbVc4w8=; b=alNxKlzg9zBxC3/G7xMClS64svkyXUtFPXrPVh8rttzoSvn8hO7/Kdj+MUIQMygTZ9 m7XzpluHddRhgGExRuUXPOTSe7lVLGhRtyW7eroDh31fkOjID/h41M3Osvz9SHlfPmDk GkPj8ogsoTc+7KUNFFvLvLcMDnZz81uHJyOlg+pNsq+qMe1K6q6o4SfncvTmgNo8IGZV jFmzlV8oYmAfFtFM3rDzfH3lQ5V2N6mk2dBVxHaUvZ5HueJv8oasHvxzyE0T7AiJS7wZ SsiABoT4YiE7T6jZECxy+jc8oLSdt41TExHgvcBw7sHsdg2dp2YDu4aw+W4gqm5ZxoAR aaQg== 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; bh=IJ2qyjEzGrCUR0+QBWc6PVxF9nWe6jaq820IAbVc4w8=; b=EMnu1xDsbHbPkCYKeu/7ur/Ppt1wMDJBeOgxHlbAaYtL8ujDUxZNp1gxbuiujCV9Te FqXneVCEoGNYhTjKZvcpIg1GiD6cCHqEN1IGGSaEWPvewQd2HVdS7G89IzNEw/nptu4p iPff9wbmQC9ePoqiJhXLjPldw/WBCd06Uc2qytjB0XyVXLOBlaeCCutneOm2gSIfY7/y KcYDQ20+PqJh9KetOEDvrFN9dRY1hvFoeXND5AlpjCnM9mQ302fS11ns2B7b6rJuluuU EdHzdh2yihySb/P/u/BuQwyRUKbodKSVVGkKSDm5U4u7k+F2UC66Bn2wAHyV2uJErYef 8aiA== X-Gm-Message-State: AKS2vOymhwsa7dJMhc4qT8Brbe7g2VcDZjqNgt6pWz0XxQLDI2JtIuNt 6OdXqKblYdfUs9rR9i/V1DBsPFze+GpD X-Received: by 10.28.181.201 with SMTP id e192mr585847wmf.48.1497027985411; Fri, 09 Jun 2017 10:06:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.173 with HTTP; Fri, 9 Jun 2017 10:06:24 -0700 (PDT) In-Reply-To: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> References: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> From: Andy Bierman Date: Fri, 9 Jun 2017 10:06:24 -0700 Message-ID: To: Benoit Claise Cc: NETMOD Working Group Content-Type: multipart/alternative; boundary="f403045f55e24a2196055189fd7d" Archived-At: Subject: Re: [netmod] Important: Guidelines for YANG module authors X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 17:06:30 -0000 --f403045f55e24a2196055189fd7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I am trying to complete rfc6087bis. It has been held up waiting for this draft. It is not clear to me how sec. 6.23 (Operational Data) needs to change. Should the whole section be replaced by an informative reference to this new draft? Andy On Fri, Jun 9, 2017 at 6:56 AM, Benoit Claise wrote: > Dear all, > > Now that the new NETMOD and NETCONF charters have been approved, it's tim= e > to think about the guidelines for YANG module authors. > > The Network Management Datastore Architecture (NMDA) addresses the > so-called "OpState problem" that has been the subject of much discussion = in > the IETF. NMDA is still in development, and there will be a transition > period before NMDA solutions are universally available. > > The NETMOD Datastore Design Team and the Routing Yang Architecture Design > Team have worked with Alia and Benoit to create initial guidelines for ho= w > the NMDA, as defined in draft-ietf-netmod-revised-datastores > , > impacts Yang models. The draft-dsdt-nmda-guidelines > individual > draft was foundational in helping creating those guidelines. > > If you have questions or concerns on how these guidelines should apply to > work of interest, please contact your WG Chairs or ADs. > > It is our strong recommendation, as ADs with agreement from the NETMOD WG > Chairs, that models SHOULD move as quickly as possible to the NMDA. The > specific approach to be taken for models being developed now and during t= he > NMDA transition period should be based on both the expected usage and the > maturity of the data model. > > 1. New models and models that are not concerned with the operational stat= e > of configuration information SHOULD immediately be structured to be > NMDA-compatible. > > 2. Models that require immediate support for "in use" and "system created= " > information SHOULD be structured for NMDA. Then derived versions of these > models SHOULD be created, either by hand or with suitable tools, that > follow the current modeling strategies. In some cases, the non-NMDA model > may be an existing model and not derived from the NMDA model. In all case= s, > the NMDA and non-NMDA modules SHOULD be published in the same document, > with NMDA modules in the document main body and the non-NMDA modules in a= n > Appendix. The use of the non-NMDA model will allow temporary bridging of > the time period until NMDA implementations are available. The non-NMDA > module names should include =E2=80=99-state=E2=80=99 appended. > > We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin > Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, > and all others who helped develop these guidelines. > > Regards, > Alia Atlas, Routing AD > Deborah Brungard, Routing AD > Alvaro Retana, Routing AD > Warren Kumari, Operations & Management AD > Benoit Claise, Operations & Management AD > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --f403045f55e24a2196055189fd7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to complete rfc6087bis.=
It has been held up waiting for this draft.
It is not = clear to me how sec. 6.23 (Operational Data) needs to change.
Sho= uld the whole section be replaced by an informative reference to this new d= raft?


Andy


On Fri, Jun 9, = 2017 at 6:56 AM, Benoit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
Dear all,

Now that the new NETMOD and NETCONF charters have been approved, it's time to think about the guidelines for YANG module authors.
The Network Management Datastore Architecture (NMDA) addresses the so-called "OpState problem" that has been the subject of much discussion in the IETF. NMDA is still in development, and there will be a transition period before NMDA solutions are universally available.

The NETMOD Datastore Design Team and the Routing Yang Architecture Design Team have worked with Alia and Benoit to create initial guidelines for how the NMDA, as defined in = draft-ietf-netmod-revised-datastores, impacts Yang models. The draft-dsdt-nmda-guidelines individual draft was foundational in helping creating those guidelines.

If you have questions or concerns on how these guidelines should apply to work of interest, please contact your WG Chairs or ADs.

It is our strong recommendation, as ADs with agreement from the NETMOD WG Chairs, that models SHOULD move as quickly as possible to the NMDA. The specific approach to be taken for models being developed now and during the NMDA transition period should be based on both the expected usage and the maturity of the data model.

1. New models and models that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible.

2. Models that require immediate support for "in use" and &qu= ot;system created" information SHOULD be structured for NMDA. Then derived versions of these models SHOULD be created, either by hand or with suitable tools, that follow the current modeling strategies. In some cases, the non-NMDA model may be an existing model and not derived from the NMDA model. In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. The non-NMDA module names should include =E2=80=99-state=E2=80=99 appended.

We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, and all others who helped develop these guidelines.

Regards,
Alia Atlas, Routing AD
Deborah Brungard, Routing AD
Alvaro Retana, Routing AD
Warren Kumari, Operations & Management AD
Benoit Claise, Operations & Management AD

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

--f403045f55e24a2196055189fd7d-- From nobody Fri Jun 9 20:42:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99956128AFE for ; Fri, 9 Jun 2017 20:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 wHKp4BobQwKh for ; Fri, 9 Jun 2017 20:42:43 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0100.outbound.protection.outlook.com [104.47.36.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA3912708C for ; Fri, 9 Jun 2017 20:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ampB1DFyGeA9jnTRhFGvk5eLyg2TuWvDKdXd725PVJw=; b=HoCDjOito4FD80COVFgaRIOh+faks8cZiKWbZxstfEIvmWMW+vB9KPWxK67KuebMeruWDPEOsfbUk+7DNUaObpgcO8hCb2xHymqtIpUtdHiq3MwSYWlMHvjst40lBCbDj9oN5bzHkSufATJuCF1zuqilHwjK5//MH6Be5IPM+Fw= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1217.namprd05.prod.outlook.com (10.160.113.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.9; Sat, 10 Jun 2017 03:42:42 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1157.014; Sat, 10 Jun 2017 03:42:42 +0000 From: Kent Watsen To: Andy Bierman CC: Benoit Claise , NETMOD Working Group Thread-Topic: [netmod] Important: Guidelines for YANG module authors Thread-Index: AQHS4Sg9yo6TKjTdckiOsaZCZtmCo6IcwyIAgACxx04= Date: Sat, 10 Jun 2017 03:42:41 +0000 Message-ID: <4F84D7BA-4FBE-4C39-9633-D19976C6E388@juniper.net> References: <767b9462-80ad-2942-f67e-31789239b894@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [137.118.194.72] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1217; 7:2GgBDNBI4yXG/sCgTtKptR4ETr74YQgEjQoGWbtm/+RhW4N4NaNBeQLpXHi12y2c4XEMKryeW1zeG/JxIwSgmyJfqJjvUSmiqTlIMzEtGC+Ba/EnJxDshgDhhRB1QSu2TB47KgprFDTsAlwqF5ii0tYtl84Qm4MujLchviFAQ2r8Qdqs6sSpgA3TRLYsfg43TnwgFlvLveBqgeREerLHb/nRrxL41qj22Si9mISVhEEMQBlJO7CQjItEpb7V6+I2Z62s5v0ASZT7e8SpDUfmbzUULFBxG3x8V3wX/CNdNLNiOzrsuBJGntRD2Q+EQmgxmotyeaGC3BtHXuFdtjqdpQ== x-ms-traffictypediagnostic: BN3PR0501MB1217: x-ms-office365-filtering-correlation-id: 42552632-6b54-4686-09d4-08d4afb2bfb3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0501MB1217; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1217; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1217; x-forefront-prvs: 0334223192 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39850400002)(39410400002)(39400400002)(39860400002)(39840400002)(377454003)(24454002)(478600001)(14454004)(2900100001)(6486002)(606005)(99286003)(77096006)(189998001)(966005)(6506006)(6436002)(82746002)(6916009)(110136004)(122556002)(6306002)(54896002)(6512007)(54906002)(236005)(83716003)(2950100002)(33656002)(6246003)(38730400002)(53936002)(4326008)(8936002)(36756003)(3846002)(2906002)(102836003)(53546009)(76176999)(54356999)(50986999)(25786009)(229853002)(3280700002)(7736002)(7906003)(81166006)(66066001)(3660700001)(86362001)(8676002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1217; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_4F84D7BA4FBE4C399633D19976C6E388junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2017 03:42:42.0053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1217 Archived-At: Subject: Re: [netmod] Important: Guidelines for YANG module authors X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 03:42:47 -0000 --_000_4F84D7BA4FBE4C399633D19976C6E388junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpZZXMsIGxldCdzIHJld3JpdGUgNi4yMyBjb21wbGV0ZWx5IHRvIHN0YXRlIG1vcmUgaGVscGZ1 bGx5IHdoYXQncyBpbiB0aGUgZ3VpZGVsaW5lcyBkcmFmdC4NCg0KSSBkb24ndCBleHBlY3QgdGhl IGd1aWRlbGluZXMgZG9jIGlzIGdvaW5nIHRvIHByb2dyZXNzIGluZGVwZW5kZW50bHkuDQoNCktl bnQuIC8vIHNoZXBoZXJkDQoNCg0KT24gSnVuIDksIDIwMTcsIGF0IDE6MDYgUE0sIEFuZHkgQmll cm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PiB3cm90 ZToNCg0KSGksDQoNCkkgYW0gdHJ5aW5nIHRvIGNvbXBsZXRlIHJmYzYwODdiaXMuDQpJdCBoYXMg YmVlbiBoZWxkIHVwIHdhaXRpbmcgZm9yIHRoaXMgZHJhZnQuDQpJdCBpcyBub3QgY2xlYXIgdG8g bWUgaG93IHNlYy4gNi4yMyAoT3BlcmF0aW9uYWwgRGF0YSkgbmVlZHMgdG8gY2hhbmdlLg0KU2hv dWxkIHRoZSB3aG9sZSBzZWN0aW9uIGJlIHJlcGxhY2VkIGJ5IGFuIGluZm9ybWF0aXZlIHJlZmVy ZW5jZSB0byB0aGlzIG5ldyBkcmFmdD8NCg0KDQpBbmR5DQoNCg0KT24gRnJpLCBKdW4gOSwgMjAx NyBhdCA2OjU2IEFNLCBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbTxtYWlsdG86YmNs YWlzZUBjaXNjby5jb20+PiB3cm90ZToNCkRlYXIgYWxsLA0KDQpOb3cgdGhhdCB0aGUgbmV3IE5F VE1PRCBhbmQgTkVUQ09ORiBjaGFydGVycyBoYXZlIGJlZW4gYXBwcm92ZWQsIGl0J3MgdGltZSB0 byB0aGluayBhYm91dCB0aGUgZ3VpZGVsaW5lcyBmb3IgWUFORyBtb2R1bGUgYXV0aG9ycy4NCg0K VGhlIE5ldHdvcmsgTWFuYWdlbWVudCBEYXRhc3RvcmUgQXJjaGl0ZWN0dXJlIChOTURBKSBhZGRy ZXNzZXMgdGhlIHNvLWNhbGxlZCAiT3BTdGF0ZSBwcm9ibGVtIiB0aGF0IGhhcyBiZWVuIHRoZSBz dWJqZWN0IG9mIG11Y2ggZGlzY3Vzc2lvbiBpbiB0aGUgSUVURi4gTk1EQSBpcyBzdGlsbCBpbiBk ZXZlbG9wbWVudCwgYW5kIHRoZXJlIHdpbGwgYmUgYSB0cmFuc2l0aW9uIHBlcmlvZCBiZWZvcmUg Tk1EQSBzb2x1dGlvbnMgYXJlIHVuaXZlcnNhbGx5IGF2YWlsYWJsZS4NCg0KVGhlIE5FVE1PRCBE YXRhc3RvcmUgRGVzaWduIFRlYW0gYW5kIHRoZSBSb3V0aW5nIFlhbmcgQXJjaGl0ZWN0dXJlIERl c2lnbiBUZWFtIGhhdmUgd29ya2VkIHdpdGggQWxpYSBhbmQgQmVub2l0IHRvIGNyZWF0ZSBpbml0 aWFsIGd1aWRlbGluZXMgZm9yIGhvdyB0aGUgTk1EQSwgYXMgZGVmaW5lZCBpbiBkcmFmdC1pZXRm LW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXM8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzLz4sIGltcGFjdHMgWWFuZyBt b2RlbHMuIFRoZSBkcmFmdC1kc2R0LW5tZGEtZ3VpZGVsaW5lczxodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1kc2R0LW5tZGEtZ3VpZGVsaW5lcy8+IGluZGl2aWR1YWwgZHJh ZnQgd2FzIGZvdW5kYXRpb25hbCBpbiBoZWxwaW5nIGNyZWF0aW5nIHRob3NlIGd1aWRlbGluZXMu DQoNCklmIHlvdSBoYXZlIHF1ZXN0aW9ucyBvciBjb25jZXJucyBvbiBob3cgdGhlc2UgZ3VpZGVs aW5lcyBzaG91bGQgYXBwbHkgdG8gd29yayBvZiBpbnRlcmVzdCwgcGxlYXNlIGNvbnRhY3QgeW91 ciBXRyBDaGFpcnMgb3IgQURzLg0KDQpJdCBpcyBvdXIgc3Ryb25nIHJlY29tbWVuZGF0aW9uLCBh cyBBRHMgd2l0aCBhZ3JlZW1lbnQgZnJvbSB0aGUgTkVUTU9EIFdHIENoYWlycywgdGhhdCBtb2Rl bHMgU0hPVUxEIG1vdmUgYXMgcXVpY2tseSBhcyBwb3NzaWJsZSB0byB0aGUgTk1EQS4gVGhlIHNw ZWNpZmljIGFwcHJvYWNoIHRvIGJlIHRha2VuIGZvciBtb2RlbHMgYmVpbmcgZGV2ZWxvcGVkIG5v dyBhbmQgZHVyaW5nIHRoZSBOTURBIHRyYW5zaXRpb24gcGVyaW9kIHNob3VsZCBiZSBiYXNlZCBv biBib3RoIHRoZSBleHBlY3RlZCB1c2FnZSBhbmQgdGhlIG1hdHVyaXR5IG9mIHRoZSBkYXRhIG1v ZGVsLg0KDQoxLiBOZXcgbW9kZWxzIGFuZCBtb2RlbHMgdGhhdCBhcmUgbm90IGNvbmNlcm5lZCB3 aXRoIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBvZiBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIFNI T1VMRCBpbW1lZGlhdGVseSBiZSBzdHJ1Y3R1cmVkIHRvIGJlIE5NREEtY29tcGF0aWJsZS4NCg0K Mi4gTW9kZWxzIHRoYXQgcmVxdWlyZSBpbW1lZGlhdGUgc3VwcG9ydCBmb3IgImluIHVzZSIgYW5k ICJzeXN0ZW0gY3JlYXRlZCIgaW5mb3JtYXRpb24gU0hPVUxEIGJlIHN0cnVjdHVyZWQgZm9yIE5N REEuIFRoZW4gZGVyaXZlZCB2ZXJzaW9ucyBvZiB0aGVzZSBtb2RlbHMgU0hPVUxEIGJlIGNyZWF0 ZWQsIGVpdGhlciBieSBoYW5kIG9yIHdpdGggc3VpdGFibGUgdG9vbHMsIHRoYXQgZm9sbG93IHRo ZSBjdXJyZW50IG1vZGVsaW5nIHN0cmF0ZWdpZXMuIEluIHNvbWUgY2FzZXMsIHRoZSBub24tTk1E QSBtb2RlbCBtYXkgYmUgYW4gZXhpc3RpbmcgbW9kZWwgYW5kIG5vdCBkZXJpdmVkIGZyb20gdGhl IE5NREEgbW9kZWwuIEluIGFsbCBjYXNlcywgdGhlIE5NREEgYW5kIG5vbi1OTURBIG1vZHVsZXMg U0hPVUxEIGJlIHB1Ymxpc2hlZCBpbiB0aGUgc2FtZSBkb2N1bWVudCwgd2l0aCBOTURBIG1vZHVs ZXMgaW4gdGhlIGRvY3VtZW50IG1haW4gYm9keSBhbmQgdGhlIG5vbi1OTURBIG1vZHVsZXMgaW4g YW4gQXBwZW5kaXguIFRoZSB1c2Ugb2YgdGhlIG5vbi1OTURBIG1vZGVsIHdpbGwgYWxsb3cgdGVt cG9yYXJ5IGJyaWRnaW5nIG9mIHRoZSB0aW1lIHBlcmlvZCB1bnRpbCBOTURBIGltcGxlbWVudGF0 aW9ucyBhcmUgYXZhaWxhYmxlLiBUaGUgbm9uLU5NREEgbW9kdWxlIG5hbWVzIHNob3VsZCBpbmNs dWRlIOKAmS1zdGF0ZeKAmSBhcHBlbmRlZC4NCg0KV2Ugd291bGQgbGlrZSB0byB0aGFuayBLZW50 IFdhdHNlbiwgTG91IEJlcmdlciwgUm9iIFdpbHRvbiwgTWFydGluIEJqb3JrbHVuZCwgUGhpbCBT aGFmZXIsIEFjZWUgTGluZGVtLCBDaHJpcyBIb3BwcywgSnVlcmdlbiBTY2hvZW53YWVsZGVyLCBh bmQgYWxsIG90aGVycyB3aG8gaGVscGVkIGRldmVsb3AgdGhlc2UgZ3VpZGVsaW5lcy4NCg0KUmVn YXJkcywNCkFsaWEgQXRsYXMsIFJvdXRpbmcgQUQNCkRlYm9yYWggQnJ1bmdhcmQsIFJvdXRpbmcg QUQNCkFsdmFybyBSZXRhbmEsIFJvdXRpbmcgQUQNCldhcnJlbiBLdW1hcmksIE9wZXJhdGlvbnMg JiBNYW5hZ2VtZW50IEFEDQpCZW5vaXQgQ2xhaXNlLCBPcGVyYXRpb25zICYgTWFuYWdlbWVudCBB RA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0 bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGlu ZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= --_000_4F84D7BA4FBE4C399633D19976C6E388junipernet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5ZZXMsIGxldCdz IHJld3JpdGUgNi4yMyBjb21wbGV0ZWx5IHRvIHN0YXRlIG1vcmUgaGVscGZ1bGx5IHdoYXQncyBp biB0aGUgZ3VpZGVsaW5lcyBkcmFmdC4gJm5ic3A7PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxT aWduYXR1cmUiPjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5JIGRv bid0IGV4cGVjdCB0aGUgZ3VpZGVsaW5lcyBkb2MgaXMgZ29pbmcgdG8gcHJvZ3Jlc3MgaW5kZXBl bmRlbnRseS48YnI+DQo8YnI+DQo8ZGl2PktlbnQuIC8vIHNoZXBoZXJkJm5ic3A7PC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCk9uIEp1biA5LCAyMDE3LCBhdCAx OjA2IFBNLCBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5j b20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+SGksDQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGFtIHRyeWluZyB0byBjb21wbGV0ZSByZmM2MDg3YmlzLjwv ZGl2Pg0KPGRpdj5JdCBoYXMgYmVlbiBoZWxkIHVwIHdhaXRpbmcgZm9yIHRoaXMgZHJhZnQuPC9k aXY+DQo8ZGl2Pkl0IGlzIG5vdCBjbGVhciB0byBtZSBob3cgc2VjLiA2LjIzIChPcGVyYXRpb25h bCBEYXRhKSBuZWVkcyB0byBjaGFuZ2UuPC9kaXY+DQo8ZGl2PlNob3VsZCB0aGUgd2hvbGUgc2Vj dGlvbiBiZSByZXBsYWNlZCBieSBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gdGhpcyBuZXcg ZHJhZnQ/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ QW5keTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmksIEp1biA5LCAyMDE3 IGF0IDY6NTYgQU0sIEJlbm9pdCBDbGFpc2UgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9 Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjbGFpc2VAY2lzY28u Y29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZG Ij5EZWFyIGFsbCw8YnI+DQo8YnI+DQpOb3cgdGhhdCB0aGUgbmV3IE5FVE1PRCBhbmQgTkVUQ09O RiBjaGFydGVycyBoYXZlIGJlZW4gYXBwcm92ZWQsIGl0J3MgdGltZSB0byB0aGluayBhYm91dCB0 aGUgZ3VpZGVsaW5lcyBmb3IgWUFORyBtb2R1bGUgYXV0aG9ycy48YnI+DQo8YnI+DQpUaGUgTmV0 d29yayBNYW5hZ2VtZW50IERhdGFzdG9yZSBBcmNoaXRlY3R1cmUgKE5NREEpIGFkZHJlc3NlcyB0 aGUgc28tY2FsbGVkICZxdW90O09wU3RhdGUgcHJvYmxlbSZxdW90OyB0aGF0IGhhcyBiZWVuIHRo ZSBzdWJqZWN0IG9mIG11Y2ggZGlzY3Vzc2lvbiBpbiB0aGUgSUVURi4gTk1EQSBpcyBzdGlsbCBp biBkZXZlbG9wbWVudCwgYW5kIHRoZXJlIHdpbGwgYmUgYSB0cmFuc2l0aW9uIHBlcmlvZCBiZWZv cmUgTk1EQSBzb2x1dGlvbnMgYXJlIHVuaXZlcnNhbGx5DQogYXZhaWxhYmxlLjxicj4NCjxkaXY+ PGJyPg0KVGhlIE5FVE1PRCBEYXRhc3RvcmUgRGVzaWduIFRlYW0gYW5kIHRoZSBSb3V0aW5nIFlh bmcgQXJjaGl0ZWN0dXJlIERlc2lnbiBUZWFtIGhhdmUgd29ya2VkIHdpdGggQWxpYSBhbmQgQmVu b2l0IHRvIGNyZWF0ZSBpbml0aWFsIGd1aWRlbGluZXMgZm9yIGhvdyB0aGUgTk1EQSwgYXMgZGVm aW5lZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzLyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQt aWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhPHdicj5zdG9yZXM8L2E+LCBpbXBhY3RzIFlhbmcgbW9k ZWxzLiBUaGUgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt ZHNkdC1ubWRhLWd1aWRlbGluZXMvIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1kc2R0LW5tZGEt Z3VpZGVsaW5lczwvYT4gaW5kaXZpZHVhbCBkcmFmdCB3YXMgZm91bmRhdGlvbmFsIGluIGhlbHBp bmcgY3JlYXRpbmcgdGhvc2UgZ3VpZGVsaW5lcy48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQpJZiB5b3UgaGF2ZSBxdWVzdGlvbnMgb3IgY29uY2VybnMgb24gaG93IHRoZXNlIGd1aWRl bGluZXMgc2hvdWxkIGFwcGx5IHRvIHdvcmsgb2YgaW50ZXJlc3QsIHBsZWFzZSBjb250YWN0IHlv dXIgV0cgQ2hhaXJzIG9yIEFEcy48YnI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KSXQgaXMgb3VyIHN0 cm9uZyByZWNvbW1lbmRhdGlvbiwgYXMgQURzIHdpdGggYWdyZWVtZW50IGZyb20gdGhlIE5FVE1P RCBXRyBDaGFpcnMsIHRoYXQgbW9kZWxzIFNIT1VMRCBtb3ZlIGFzIHF1aWNrbHkgYXMgcG9zc2li bGUgdG8gdGhlIE5NREEuIFRoZSBzcGVjaWZpYyBhcHByb2FjaCB0byBiZSB0YWtlbiBmb3IgbW9k ZWxzIGJlaW5nIGRldmVsb3BlZCBub3cgYW5kIGR1cmluZyB0aGUgTk1EQSB0cmFuc2l0aW9uIHBl cmlvZCBzaG91bGQgYmUgYmFzZWQNCiBvbiBib3RoIHRoZSBleHBlY3RlZCB1c2FnZSBhbmQgdGhl IG1hdHVyaXR5IG9mIHRoZSBkYXRhIG1vZGVsLjxicj4NCjxicj4NCjEuIE5ldyBtb2RlbHMgYW5k IG1vZGVscyB0aGF0IGFyZSBub3QgY29uY2VybmVkIHdpdGggdGhlIG9wZXJhdGlvbmFsIHN0YXRl IG9mIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gU0hPVUxEIGltbWVkaWF0ZWx5IGJlIHN0cnVj dHVyZWQgdG8gYmUgTk1EQS1jb21wYXRpYmxlLjxicj4NCjxicj4NCjIuIE1vZGVscyB0aGF0IHJl cXVpcmUgaW1tZWRpYXRlIHN1cHBvcnQgZm9yICZxdW90O2luIHVzZSZxdW90OyBhbmQgJnF1b3Q7 c3lzdGVtIGNyZWF0ZWQmcXVvdDsgaW5mb3JtYXRpb24gU0hPVUxEIGJlIHN0cnVjdHVyZWQgZm9y IE5NREEuIFRoZW4gZGVyaXZlZCB2ZXJzaW9ucyBvZiB0aGVzZSBtb2RlbHMgU0hPVUxEIGJlIGNy ZWF0ZWQsIGVpdGhlciBieSBoYW5kIG9yIHdpdGggc3VpdGFibGUgdG9vbHMsIHRoYXQgZm9sbG93 IHRoZSBjdXJyZW50IG1vZGVsaW5nIHN0cmF0ZWdpZXMuDQogSW4gc29tZSBjYXNlcywgdGhlIG5v bi1OTURBIG1vZGVsIG1heSBiZSBhbiBleGlzdGluZyBtb2RlbCBhbmQgbm90IGRlcml2ZWQgZnJv bSB0aGUgTk1EQSBtb2RlbC4gSW4gYWxsIGNhc2VzLCB0aGUgTk1EQSBhbmQgbm9uLU5NREEgbW9k dWxlcyBTSE9VTEQgYmUgcHVibGlzaGVkIGluIHRoZSBzYW1lIGRvY3VtZW50LCB3aXRoIE5NREEg bW9kdWxlcyBpbiB0aGUgZG9jdW1lbnQgbWFpbiBib2R5IGFuZCB0aGUgbm9uLU5NREEgbW9kdWxl cyBpbiBhbg0KIEFwcGVuZGl4LiBUaGUgdXNlIG9mIHRoZSBub24tTk1EQSBtb2RlbCB3aWxsIGFs bG93IHRlbXBvcmFyeSBicmlkZ2luZyBvZiB0aGUgdGltZSBwZXJpb2QgdW50aWwgTk1EQSBpbXBs ZW1lbnRhdGlvbnMgYXJlIGF2YWlsYWJsZS4gVGhlIG5vbi1OTURBIG1vZHVsZSBuYW1lcyBzaG91 bGQgaW5jbHVkZSDigJktc3RhdGXigJkgYXBwZW5kZWQuPGJyPg0KPGJyPg0KV2Ugd291bGQgbGlr ZSB0byB0aGFuayBLZW50IFdhdHNlbiwgTG91IEJlcmdlciwgUm9iIFdpbHRvbiwgTWFydGluIEJq b3JrbHVuZCwgUGhpbCBTaGFmZXIsIEFjZWUgTGluZGVtLCBDaHJpcyBIb3BwcywgSnVlcmdlbiBT Y2hvZW53YWVsZGVyLCBhbmQgYWxsIG90aGVycyB3aG8gaGVscGVkIGRldmVsb3AgdGhlc2UgZ3Vp ZGVsaW5lcy48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCkFsaWEgQXRsYXMsIFJvdXRpbmcgQUQ8 YnI+DQpEZWJvcmFoIEJydW5nYXJkLCBSb3V0aW5nIEFEPGJyPg0KQWx2YXJvIFJldGFuYSwgUm91 dGluZyBBRDxicj4NCldhcnJlbiBLdW1hcmksIE9wZXJhdGlvbnMgJmFtcDsgTWFuYWdlbWVudCBB RCA8YnI+DQpCZW5vaXQgQ2xhaXNlLCBPcGVyYXRpb25zICZhbXA7IE1hbmFnZW1lbnQgQUQ8YnI+ DQo8L2Rpdj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19f X19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Om5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGlu Zm8vbmV0bW9kPC9hPjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRp dj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv c3Bhbj48YnI+DQo8c3Bhbj5uZXRtb2QgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxh IGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48L3NwYW4+ PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9h Pjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4F84D7BA4FBE4C399633D19976C6E388junipernet_-- From nobody Fri Jun 9 23:49:33 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10E31293F3 for ; Fri, 9 Jun 2017 23:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVFlBmP6ZlqP for ; Fri, 9 Jun 2017 23:49:25 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEE11293E9 for ; Fri, 9 Jun 2017 23:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12375; q=dns/txt; s=iport; t=1497077364; x=1498286964; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=xix8V933XyCJibwspPtf+QAP3ScFL8j5FiC9mN7hurs=; b=mRoUG9AljTGntl85flsEFaX6cWH7HrV+YFzFlr9FPaeKa0S5Hdg+DoE8 CaHqRBfmKszFzCEbPZPHDbJuxf+jtSKJgKuvxUuhiVOB9Maq18I3gNn/4 GD0FZ80e8qwGc1qxIr2D+bUS6YGhFve/m7w1GV1elu+EidP0WGS3CLuwk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AQAtlTtZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyuBD4ENg3SKGHOQWiGQSoU5ghEhAQqFLkoCg0AYAQIBAQEBAQE?= =?us-ascii?q?BayiFGQEBAQMBASFLCxALDgQGJwMCAicfAw4GAQwGAgEBF4oRELEfgiYrizkBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYZhgWArC4Jqh3yCYQWQdoYShzWHK1uLQoI?= =?us-ascii?q?GhUODS4ZyjC6DU4RqHzg/SzAhCBsVSAiBcYJagj0+Noc0KoIVAQEB?= X-IronPort-AV: E=Sophos;i="5.39,321,1493683200"; d="scan'208,217";a="653496362" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2017 06:49:19 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v5A6nJkn007543; Sat, 10 Jun 2017 06:49:19 GMT To: Kent Watsen , Andy Bierman Cc: NETMOD Working Group References: <767b9462-80ad-2942-f67e-31789239b894@cisco.com> <4F84D7BA-4FBE-4C39-9633-D19976C6E388@juniper.net> From: Benoit Claise Message-ID: Date: Sat, 10 Jun 2017 08:49:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <4F84D7BA-4FBE-4C39-9633-D19976C6E388@juniper.net> Content-Type: multipart/alternative; boundary="------------EF691065C0E0FF799E8637CC" Content-Language: en-US Archived-At: Subject: Re: [netmod] Important: Guidelines for YANG module authors X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 06:49:31 -0000 This is a multi-part message in MIME format. --------------EF691065C0E0FF799E8637CC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/10/2017 5:42 AM, Kent Watsen wrote: > > Yes, let's rewrite 6.23 completely to state more helpfully what's in > the guidelines draft. > > I don't expect the guidelines doc is going to progress independently. Agreed. Regards, B. > > Kent. // shepherd > > > On Jun 9, 2017, at 1:06 PM, Andy Bierman > wrote: > >> Hi, >> >> I am trying to complete rfc6087bis. >> It has been held up waiting for this draft. >> It is not clear to me how sec. 6.23 (Operational Data) needs to change. >> Should the whole section be replaced by an informative reference to >> this new draft? >> >> >> Andy >> >> >> On Fri, Jun 9, 2017 at 6:56 AM, Benoit Claise > > wrote: >> >> Dear all, >> >> Now that the new NETMOD and NETCONF charters have been approved, >> it's time to think about the guidelines for YANG module authors. >> >> The Network Management Datastore Architecture (NMDA) addresses >> the so-called "OpState problem" that has been the subject of much >> discussion in the IETF. NMDA is still in development, and there >> will be a transition period before NMDA solutions are universally >> available. >> >> The NETMOD Datastore Design Team and the Routing Yang >> Architecture Design Team have worked with Alia and Benoit to >> create initial guidelines for how the NMDA, as defined in >> draft-ietf-netmod-revised-datastores >> , >> impacts Yang models. The draft-dsdt-nmda-guidelines >> >> individual draft was foundational in helping creating those >> guidelines. >> >> If you have questions or concerns on how these guidelines should >> apply to work of interest, please contact your WG Chairs or ADs. >> >> It is our strong recommendation, as ADs with agreement from the >> NETMOD WG Chairs, that models SHOULD move as quickly as possible >> to the NMDA. The specific approach to be taken for models being >> developed now and during the NMDA transition period should be >> based on both the expected usage and the maturity of the data model. >> >> 1. New models and models that are not concerned with the >> operational state of configuration information SHOULD immediately >> be structured to be NMDA-compatible. >> >> 2. Models that require immediate support for "in use" and "system >> created" information SHOULD be structured for NMDA. Then derived >> versions of these models SHOULD be created, either by hand or >> with suitable tools, that follow the current modeling strategies. >> In some cases, the non-NMDA model may be an existing model and >> not derived from the NMDA model. In all cases, the NMDA and >> non-NMDA modules SHOULD be published in the same document, with >> NMDA modules in the document main body and the non-NMDA modules >> in an Appendix. The use of the non-NMDA model will allow >> temporary bridging of the time period until NMDA implementations >> are available. The non-NMDA module names should include ’-state’ >> appended. >> >> We would like to thank Kent Watsen, Lou Berger, Rob Wilton, >> Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen >> Schoenwaelder, and all others who helped develop these guidelines. >> >> Regards, >> Alia Atlas, Routing AD >> Deborah Brungard, Routing AD >> Alvaro Retana, Routing AD >> Warren Kumari, Operations & Management AD >> Benoit Claise, Operations & Management AD >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod --------------EF691065C0E0FF799E8637CC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/10/2017 5:42 AM, Kent Watsen wrote:

Yes, let's rewrite 6.23 completely to state more helpfully what's in the guidelines draft.  

I don't expect the guidelines doc is going to progress independently.
Agreed.

Regards, B.

Kent. // shepherd 


On Jun 9, 2017, at 1:06 PM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

I am trying to complete rfc6087bis.
It has been held up waiting for this draft.
It is not clear to me how sec. 6.23 (Operational Data) needs to change.
Should the whole section be replaced by an informative reference to this new draft?


Andy


On Fri, Jun 9, 2017 at 6:56 AM, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

Now that the new NETMOD and NETCONF charters have been approved, it's time to think about the guidelines for YANG module authors.

The Network Management Datastore Architecture (NMDA) addresses the so-called "OpState problem" that has been the subject of much discussion in the IETF. NMDA is still in development, and there will be a transition period before NMDA solutions are universally available.

The NETMOD Datastore Design Team and the Routing Yang Architecture Design Team have worked with Alia and Benoit to create initial guidelines for how the NMDA, as defined in draft-ietf-netmod-revised-datastores, impacts Yang models. The draft-dsdt-nmda-guidelines individual draft was foundational in helping creating those guidelines.

If you have questions or concerns on how these guidelines should apply to work of interest, please contact your WG Chairs or ADs.

It is our strong recommendation, as ADs with agreement from the NETMOD WG Chairs, that models SHOULD move as quickly as possible to the NMDA. The specific approach to be taken for models being developed now and during the NMDA transition period should be based on both the expected usage and the maturity of the data model.

1. New models and models that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible.

2. Models that require immediate support for "in use" and "system created" information SHOULD be structured for NMDA. Then derived versions of these models SHOULD be created, either by hand or with suitable tools, that follow the current modeling strategies. In some cases, the non-NMDA model may be an existing model and not derived from the NMDA model. In all cases, the NMDA and non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in an Appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. The non-NMDA module names should include ’-state’ appended.

We would like to thank Kent Watsen, Lou Berger, Rob Wilton, Martin Bjorklund, Phil Shafer, Acee Lindem, Chris Hopps, Juergen Schoenwaelder, and all others who helped develop these guidelines.

Regards,
Alia Atlas, Routing AD
Deborah Brungard, Routing AD
Alvaro Retana, Routing AD
Warren Kumari, Operations & Management AD
Benoit Claise, Operations & Management AD

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


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

--------------EF691065C0E0FF799E8637CC-- From nobody Mon Jun 12 10:21:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D07129454 for ; Mon, 12 Jun 2017 10:21:47 -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, RP_MATCHES_RCVD=-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 wPJAP_m30YtJ for ; Mon, 12 Jun 2017 10:21:45 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D071293FD for ; Mon, 12 Jun 2017 10:21:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 37CEC77; Mon, 12 Jun 2017 19:21:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id YVOofc_g01Bm; Mon, 12 Jun 2017 19:21:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 12 Jun 2017 19:21:43 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E725D20094; Mon, 12 Jun 2017 19:21:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ID7BH4f8ffvG; Mon, 12 Jun 2017 19:21:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9812920091; Mon, 12 Jun 2017 19:21:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 999CD3FBC10C; Mon, 12 Jun 2017 19:21:42 +0200 (CEST) Date: Mon, 12 Jun 2017 19:21:42 +0200 From: Juergen Schoenwaelder To: "Bogaert, Bart (Nokia - BE/Antwerp)" Cc: "netmod@ietf.org" Message-ID: <20170612172141.GA52797@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 17:21:48 -0000 On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > > We have a question regarding the statistics container as defined in the > interfaces-state model. This container defines one mandatory leaf > (discontinuity-time) while all other leafs are optional. What is the > rationale behind this leaf being mandatory and not an optional field? > > It does not make a lot of sense to return a discontinuity-time value and no > counters if none of the counters are relevant for a specific interface. > > Another alternative could be to add, via a deviation, a when clause to the > container indicating for which ifType(s) the container is (or is not) > present. But that would lead to not supporting the IETF interfaces model to > the full extent. > The discontinuity-time is relevant for _any_ counter associated with an interface, regardless whether the counter is defined in the interfaces model or elsewhere. I have a hard time to imagine an interface that has zero counters. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 12 11:31:37 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA4512EB55 for ; Mon, 12 Jun 2017 11:31:24 -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, 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=yumaworks-com.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 hrQ5uu8HRt09 for ; Mon, 12 Jun 2017 11:31:22 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16978129548 for ; Mon, 12 Jun 2017 11:31:22 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id q97so108623182wrb.2 for ; Mon, 12 Jun 2017 11:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=sFWXhfbWQDkOsOHjmKj7Issf3CXjaAxCABYK7cNoVZk=; b=HKxDkMAUbsUBVpIwsOCljHbaJjQkupu6b2rxVAziyZQ6ICK324IS8OOmUWrH0RG3/3 xwP7D5PsrhuU743iCchY6CkehVl8x9aSNXmoZw5Vqce3rbSemB97xjtzQVznWEWf5SUD XcWi49MM4+LUDobaklxesGz6GaiaEXqiNFMwkMdLdmSedIY309RHlrtCZKolzyELXnJA SXxHHQYmZE1YvWLGG2eH4/LiRMBtAgIZJx4dXIpwj+CpmAlzSunwEihT+9kOwleVCzhJ TtfQOKUMUvQ260+GjQc4i1WLYkjZth6J1/WCsai0FwWdzKMdli50yNvSWW5bdWYdeeGY jSbA== 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; bh=sFWXhfbWQDkOsOHjmKj7Issf3CXjaAxCABYK7cNoVZk=; b=iWpCZmcWWSwSMVGN3/FuoNhq3hWsBVNKWEp8XMvgu4qqvfuMHBaMEQzKqmiJNctBze GRZzIRkFl9uR34BUmIXNohSZCr02xx/rnTZ0WDrz8ri1of6CEhNuavn4UWfWtg0LAo4v LuaBheZmijtun7eBPtuUZJliZyhBfHV6J5ZZRvOGpuAne9sRV3y0/344+h2cpC3jh0gK 3TxJr+AalaaQvSvCeiKp9Bo3LfQRIE3YzGcKwINSjkkBETILt2uU8IxNBXNOzocGG/lY MKbEaU+79tvOtCFG/cKe3hgb2BTEgVu2xtVbwWO2bpMqIfGERovqny6GW913xX7BC0xh F8mw== X-Gm-Message-State: AKS2vOyQVECcY2TP9mrMpkfMkCmWA8WwEvVNlFiu30/ujQ3RGrMxFAzK JJwnZYZXkZ3LHCpFI1BrYy4C+MKUTH/J X-Received: by 10.223.176.205 with SMTP id j13mr182844wra.65.1497292280501; Mon, 12 Jun 2017 11:31:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.173 with HTTP; Mon, 12 Jun 2017 11:31:19 -0700 (PDT) In-Reply-To: <20170612172141.GA52797@elstar.local> References: <20170612172141.GA52797@elstar.local> From: Andy Bierman Date: Mon, 12 Jun 2017 11:31:19 -0700 Message-ID: To: Juergen Schoenwaelder , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a1141c6c08135260551c78653" Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 18:31:25 -0000 --001a1141c6c08135260551c78653 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - > BE/Antwerp) wrote: > > > > We have a question regarding the statistics container as defined in the > > interfaces-state model. This container defines one mandatory leaf > > (discontinuity-time) while all other leafs are optional. What is the > > rationale behind this leaf being mandatory and not an optional field? > > > > It does not make a lot of sense to return a discontinuity-time value and > no > > counters if none of the counters are relevant for a specific interface. > > > > Another alternative could be to add, via a deviation, a when clause to > the > > container indicating for which ifType(s) the container is (or is not) > > present. But that would lead to not supporting the IETF interfaces model > to > > the full extent. > > > > The discontinuity-time is relevant for _any_ counter associated with > an interface, regardless whether the counter is defined in the > interfaces model or elsewhere. I have a hard time to imagine an > interface that has zero counters. > > The mandatory-stmt is very confusing for config=false nodes. Mandatory=true means an must contain an instance of the mandatory leaf. Mandatory=false does not mean optional-to-implement although it sure looks that way for config=false nodes. Only if-feature can make a node optional to implement. /js Andy -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1141c6c08135260551c78653 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, = Bart (Nokia - BE/Antwerp) wrote:
>
> We have a question regarding the statistics container as defined in th= e
> interfaces-state model.=C2=A0 This container defines one mandatory lea= f
> (discontinuity-time) while all other leafs are optional.=C2=A0 What is= the
> rationale behind this leaf being mandatory and not an optional field?<= br> >
> It does not make a lot of sense to return a discontinuity-time value a= nd no
> counters if none of the counters are relevant for a specific interface= .
>
> Another alternative could be to add, via a deviation, a when clause to= the
> container indicating for which ifType(s) the container is (or is not)<= br> > present. But that would lead to not supporting the IETF interfaces mod= el to
> the full extent.
>

The discontinuity-time is relevant for _any_ counter associated with
an interface, regardless whether the counter is defined in the
interfaces model or elsewhere. I have a hard time to imagine an
interface that has zero counters.


The mandatory-stmt is very confusing for config=3Dfa= lse nodes. Mandatory=3Dtrue means=C2=A0
an <rpc-reply> must= contain an instance of the mandatory leaf.

Mandat= ory=3Dfalse does not mean optional-to-implement although it sure
= looks that way for config=3Dfalse nodes.=C2=A0 Only if-feature can make a n= ode optional to implement.



=C2=A0/js


Andy

<= /span>
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a1141c6c08135260551c78653-- From nobody Tue Jun 13 02:24:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7887A131582 for ; Tue, 13 Jun 2017 02:24:15 -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, 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 UNvTtmeOGMY1 for ; Tue, 13 Jun 2017 02:24:12 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBA612EC0D for ; Tue, 13 Jun 2017 02:15:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6AE3214E1367; Tue, 13 Jun 2017 11:15:12 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id leb17jzykkgb; Tue, 13 Jun 2017 11:15:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 40CC614E1368; Tue, 13 Jun 2017 11:15:12 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id T5w-7Yc1e3eD; Tue, 13 Jun 2017 11:15:12 +0200 (CEST) Received: from [192.168.209.116] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 2291514E1365; Tue, 13 Jun 2017 11:15:12 +0200 (CEST) To: Andy Bierman , Juergen Schoenwaelder , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: <20170612172141.GA52797@elstar.local> From: Vladimir Vassilev Message-ID: <65e1aa8e-c37b-d323-a351-c17fa4e96b3e@transpacket.com> Date: Tue, 13 Jun 2017 11:15:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 09:24:15 -0000 On 06/12/2017 08:31 PM, Andy Bierman wrote: > > > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder > > wrote: > > On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - > BE/Antwerp) wrote: > > > > We have a question regarding the statistics container as defined > in the > > interfaces-state model. This container defines one mandatory leaf > > (discontinuity-time) while all other leafs are optional. What > is the > > rationale behind this leaf being mandatory and not an optional > field? > > > > It does not make a lot of sense to return a discontinuity-time > value and no > > counters if none of the counters are relevant for a specific > interface. > > > > Another alternative could be to add, via a deviation, a when > clause to the > > container indicating for which ifType(s) the container is (or is > not) > > present. But that would lead to not supporting the IETF > interfaces model to > > the full extent. > > > The alternative which we use is to not have /interfaces-state/interface/statistics container for the interfaces without counters. The container is mandatory=false. > > > The discontinuity-time is relevant for _any_ counter associated with > an interface, regardless whether the counter is defined in the > interfaces model or elsewhere. I have a hard time to imagine an > interface that has zero counters. > There are some though. Optical amplifiers and similar equipment that does not have counters - the status data is only signal levels. > > The mandatory-stmt is very confusing for config=false nodes. > Mandatory=true means > an must contain an instance of the mandatory leaf. > > Mandatory=false does not mean optional-to-implement although it sure > looks that way for config=false nodes. Only if-feature can make a > node optional to implement. If we take serial interface with hardware that only has in-octets and out-octets counters I would expect to only find these two in /interfaces-state/interface/statistics + discontinuity-time. Do you say the rest of the counters must be present (e.g. allways 0) for proper implementation of ietf-interfaces? Vladimir > > > > /js > > > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jun 13 05:34:13 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3447B12E855; Tue, 13 Jun 2017 05:34:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149735725207.17561.16997653317514816844@ietfa.amsl.com> Date: Tue, 13 Jun 2017 05:34:12 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 12:34:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : YANG Tree Diagrams Authors : Martin Bjorklund Lou Berger Filename : draft-ietf-netmod-yang-tree-diagrams-00.txt Pages : 4 Date : 2017-06-13 Abstract: This document captures the current syntax used in YANG module Tree Diagrams. The purpose of the document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-00 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 13 09:16:33 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3BB131A30; Tue, 13 Jun 2017 09:16:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149737058627.7559.129063958308124732@ietfa.amsl.com> Date: Tue, 13 Jun 2017 09:16:26 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-model-classification-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 16:16:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : YANG Module Classification Authors : Dean Bogdanovic Benoit Claise Carl Moberg Filename : draft-ietf-netmod-yang-model-classification-08.txt Pages : 11 Date : 2017-06-13 Abstract: The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards development organizations (SDOs), open source software projects, vendors and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules. A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-08 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-model-classification-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-model-classification-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 13 09:57:01 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3640B13012B; Tue, 13 Jun 2017 09:57:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Cc: netmod-chairs@ietf.org, The IESG , netmod@ietf.org, draft-ietf-netmod-yang-model-classification@ietf.org, Lou Berger , lberger@labn.net, warren@kumari.net, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149737302021.7559.5605716312265049646.idtracker@ietfa.amsl.com> Date: Tue, 13 Jun 2017 09:57:00 -0700 Archived-At: Subject: [netmod] Document Action: 'YANG Module Classification' to Informational RFC (draft-ietf-netmod-yang-model-classification-08.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 16:57:00 -0000 The IESG has approved the following document: - 'YANG Module Classification' (draft-ietf-netmod-yang-model-classification-08.txt) as Informational RFC This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Warren Kumari and Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ Technical Summary A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG modules. Working Group Summary No particular drama. Document Quality This document has received extensive input and review. It already serves as foundation for related work in the working group and OPS area. Personnel Document Shepherd: Lou Berger Responsible Area Director: Warren Kumari From nobody Tue Jun 13 11:52:54 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AF7129486 for ; Tue, 13 Jun 2017 11:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fM9DvHXaGLWf for ; Tue, 13 Jun 2017 11:52:50 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AABBC129409 for ; Tue, 13 Jun 2017 11:52:50 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id AB89B18216B4; Tue, 13 Jun 2017 20:54:20 +0200 (CEST) Received: from localhost (cst-prg-41-5.cust.vodafone.cz [46.135.41.5]) by trail.lhotka.name (Postfix) with ESMTPSA id C88FE1820E6C; Tue, 13 Jun 2017 20:54:17 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , "Bogaert\, Bart \(Nokia - BE\/Antwerp\)" , "netmod\@ietf.org" In-Reply-To: References: <20170612172141.GA52797@elstar.local> Date: Tue, 13 Jun 2017 20:52:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 18:52:53 -0000 Andy Bierman writes: > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - >> BE/Antwerp) wrote: >> > >> > We have a question regarding the statistics container as defined in the >> > interfaces-state model. This container defines one mandatory leaf >> > (discontinuity-time) while all other leafs are optional. What is the >> > rationale behind this leaf being mandatory and not an optional field? >> > >> > It does not make a lot of sense to return a discontinuity-time value and >> no >> > counters if none of the counters are relevant for a specific interface. >> > >> > Another alternative could be to add, via a deviation, a when clause to >> the >> > container indicating for which ifType(s) the container is (or is not) >> > present. But that would lead to not supporting the IETF interfaces model >> to >> > the full extent. >> > >> >> The discontinuity-time is relevant for _any_ counter associated with >> an interface, regardless whether the counter is defined in the >> interfaces model or elsewhere. I have a hard time to imagine an >> interface that has zero counters. >> >> > The mandatory-stmt is very confusing for config=false nodes. Mandatory=true > means > an must contain an instance of the mandatory leaf. I don't think it is that confusing. RFC 7950 defines what a valid data tree means and "mandatory" are among the constraints. I agree though that in terms of a management protocol it means different things for config true and false data, but this is true also for default values and maybe other YANG concepts as well. > > Mandatory=false does not mean optional-to-implement although it sure > looks that way for config=false nodes. Only if-feature can make a node > optional to implement. I don't think this interpretation is supported by any text in the YANG spec. State data nodes that are optional needn't be implemented. Lada > > > > /js > > > Andy > > -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Jun 13 12:30:41 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76C4129540 for ; Tue, 13 Jun 2017 12:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=yumaworks-com.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 4pmp5A68bm0y for ; Tue, 13 Jun 2017 12:30:37 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 153AD129534 for ; Tue, 13 Jun 2017 12:30:37 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id 36so36188197wry.3 for ; Tue, 13 Jun 2017 12:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7i0EnWg+a01ehrnmxB0IH0g9QGeQwFKGd6k1ZAlOwVg=; b=CObhl+1Mizpvb8hDpFEx5bk0lH8cUpdIwHJmI4CgZrsd4BNCOlChyt+/Z0F0IX4wzu vqWhDi2vBO2vJaUIHdsUQZTO+UV/IKbnE7T0jh/AqeRjquz2WnMRFL+Z9KH2NMpw9KMB dNPY0jbZfGCqYumpO3tPV/e8/qMxOZH07LEaZ9V1n0XaSlCtcVDDSl9R/SHgLuCN6spQ oYHGsH9lw9hku01uDFzwi8AzaPizV28x9NJLN8RBnvXNCK7WVsNuJf2nhgKEghVjwdWD yVmwFugzMZ08bqcXlx9T3XwYYh49AIemT1JxdDjGiFJtl67T0ufcbmKCAMEBOQxClO/K WC1A== 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; bh=7i0EnWg+a01ehrnmxB0IH0g9QGeQwFKGd6k1ZAlOwVg=; b=BMp30ATYs1nbxCj8bTXDb5amA0zG1y11p+kNGG8xWOEOcRndlcPuh925Rj4e8yIHRm OKVNyTjZj4aned4wzObTnuXWDy9Lhg/2WOIH1i7Kn7BCdXeTTBiXCoVPiCkqe7M9OwNE s8qhBxHzokl9znNqlrD1KeWfew2RJGL3qpG0BQUbE1ubh2DpiCVKMEqA7/3wA9bPBo6M 6PhJBsycmzCcs9ks+6APxlrounw4xaP9N73PePFcrZlvXaC6HDxis1DQZwTQGX4xb46y dFGYpCzTrTNLOGpwggAkJ3stHNRxxAJGfVLNSkb+irrJpfUTJpEnGXR/4Z1jJV5T+r2v SyIA== X-Gm-Message-State: AKS2vOzIDVOI06PHSRUw1xg9wOAJu5yvvJD6kGZkA3H3qW0CXXiuDgy9 axpMngbS+di8wWxFF35VHDUcyBLIRDWF X-Received: by 10.28.151.207 with SMTP id z198mr12438747wmd.48.1497382235429; Tue, 13 Jun 2017 12:30:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.173 with HTTP; Tue, 13 Jun 2017 12:30:34 -0700 (PDT) In-Reply-To: References: <20170612172141.GA52797@elstar.local> From: Andy Bierman Date: Tue, 13 Jun 2017 12:30:34 -0700 Message-ID: To: Ladislav Lhotka Cc: Juergen Schoenwaelder , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a1144ea2a3cb11c0551dc7823" Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 19:30:40 -0000 --001a1144ea2a3cb11c0551dc7823 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > >> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - > >> BE/Antwerp) wrote: > >> > > >> > We have a question regarding the statistics container as defined in > the > >> > interfaces-state model. This container defines one mandatory leaf > >> > (discontinuity-time) while all other leafs are optional. What is the > >> > rationale behind this leaf being mandatory and not an optional field? > >> > > >> > It does not make a lot of sense to return a discontinuity-time value > and > >> no > >> > counters if none of the counters are relevant for a specific > interface. > >> > > >> > Another alternative could be to add, via a deviation, a when clause to > >> the > >> > container indicating for which ifType(s) the container is (or is not) > >> > present. But that would lead to not supporting the IETF interfaces > model > >> to > >> > the full extent. > >> > > >> > >> The discontinuity-time is relevant for _any_ counter associated with > >> an interface, regardless whether the counter is defined in the > >> interfaces model or elsewhere. I have a hard time to imagine an > >> interface that has zero counters. > >> > >> > > The mandatory-stmt is very confusing for config=false nodes. > Mandatory=true > > means > > an must contain an instance of the mandatory leaf. > > I don't think it is that confusing. RFC 7950 defines what a valid data > tree means and "mandatory" are among the constraints. > > I agree though that in terms of a management protocol it means different > things for config true and false data, but this is true also for default > values and maybe other YANG concepts as well. > > > > > Mandatory=false does not mean optional-to-implement although it sure > > looks that way for config=false nodes. Only if-feature can make a node > > optional to implement. > > I don't think this interpretation is supported by any text in the YANG > spec. State data nodes that are optional needn't be implemented. > > RFC 7950, sec 5.6 (Conformance) does not support your interpretation. It defines basic behavior, optional (via features), and deviations as the only mechanisms affecting conformance. Lada > > > > Andy > > > > > > /js > > > > > > Andy > > > > -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > --001a1144ea2a3cb11c0551dc7823 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
>> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - >> BE/Antwerp) wrote:
>> >
>> > We have a question regarding the statistics container as defi= ned in the
>> > interfaces-state model.=C2=A0 This container defines one mand= atory leaf
>> > (discontinuity-time) while all other leafs are optional.=C2= =A0 What is the
>> > rationale behind this leaf being mandatory and not an optiona= l field?
>> >
>> > It does not make a lot of sense to return a discontinuity-tim= e value and
>> no
>> > counters if none of the counters are relevant for a specific = interface.
>> >
>> > Another alternative could be to add, via a deviation, a when = clause to
>> the
>> > container indicating for which ifType(s) the container is (or= is not)
>> > present. But that would lead to not supporting the IETF inter= faces model
>> to
>> > the full extent.
>> >
>>
>> The discontinuity-time is relevant for _any_ counter associated wi= th
>> an interface, regardless whether the counter is defined in the
>> interfaces model or elsewhere. I have a hard time to imagine an >> interface that has zero counters.
>>
>>
> The mandatory-stmt is very confusing for config=3Dfalse nodes. Mandato= ry=3Dtrue
> means
> an <rpc-reply> must contain an instance of the mandatory leaf.
I don't think it is that confusing. RFC 7950 defines what a valid data<= br> tree means and "mandatory" are among the constraints.

I agree though that in terms of a management protocol it means different things for config true and false data, but this is true also for default values and maybe other YANG concepts as well.

>
> Mandatory=3Dfalse does not mean optional-to-implement although it sure=
> looks that way for config=3Dfalse nodes.=C2=A0 Only if-feature can mak= e a node
> optional to implement.

I don't think this interpretation is supported by any text in the YANG<= br> spec. State data nodes that are optional needn't be implemented.


RFC 7950, sec 5.6 =C2=A0(Conformance) = does not support your interpretation.
It defines basic behavior, = optional (via features), and deviations as the only mechanisms affecting co= nformance.


>
>
>=C2=A0 /js
>
>
> Andy
>
> --
>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jaco= bs University Bremen gGmbH
>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ri= ng 1 | 28759 Bremen | Germany
>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netm= od
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

--001a1144ea2a3cb11c0551dc7823-- From nobody Tue Jun 13 12:53:38 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157E0129577; Tue, 13 Jun 2017 12:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.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 uKqVbeB8HplK; Tue, 13 Jun 2017 12:53:34 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0097.outbound.protection.outlook.com [104.47.37.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29110129687; Tue, 13 Jun 2017 12:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kImmb3kukvDzD2WvNS3bza5VE/OpTkQpFnuoe+wbNYM=; b=bIMuLY360+f316oWYsFBZRGkonL+7UkfB0PbxaCPveK3S3fpAxH8N3ktEUoZGmyTnFz9VQDTil8dBI9uomxIfG66IgJcPDnqDDS7ffMzrAPj30PxD0SvW0DynYUAkZh3PK2yKhenG6GaJNZKWLpGF7IQi+fFqpWUvXXgh+Fn1ak= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0868.namprd02.prod.outlook.com (10.160.154.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Tue, 13 Jun 2017 19:53:32 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1157.017; Tue, 13 Jun 2017 19:53:32 +0000 From: Xufeng Liu To: "draft-dsdt-nmda-guidelines@ietf.org" , "netmod@ietf.org" Thread-Topic: Clarification Question on draft-dsdt-nmda-guidelines-01 Thread-Index: AdLke06/vgT9KziZR8agaNlzO3lZRw== Date: Tue, 13 Jun 2017 19:53:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXHhsaXVcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy1mNzYwYmVjOS01MDcxLTExZTctOWMxNC0xODVlMGZlM2M0NWNcYW1lLXRlc3RcZjc2MGJlY2EtNTA3MS0xMWU3LTljMTQtMTg1ZTBmZTNjNDVjYm9keS5odG1sIiBzej0iMjY2NiIgdD0iMTMxNDE4NTcyMDkxMzMwNDAzIiBoPSJaME9NQUZTaWxVRnBSREo0YmU5N3RDS2pySXc9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+ authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0868; 7:JqZMrQCWV3mAYxxp25REkwTgmuWjVfySP9IKoGqACK9mYlUshyCqg4rihEUi2JN0Cg6m2cwVh6CnqpTca55h9YB5bJfqG4qoz+rbwtlssVN0upFpao9eu8STvS9F34KmWhlEjpkKHKkHz6Wc46n4JZwxmDkjN0S9C4OF0eVA6TByZ9v6wq8iKpi29umnWWTHc7wVB443qDqlAhyso/1QXeEg2K38xsXsW0IJF8G4+XnTjUiybmNAhlcQqUFj5dIXA872G50zQjqgVo1rtV+oba06rv8u83ELK7ODRifm/uVBHjp95WScm8TjZAIOQmem9rkrGcfjmhpG20pa2jL7/g== x-ms-office365-filtering-correlation-id: 18131aea-5c91-42cf-8b19-08d4b295decc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0201MB0868; x-ms-traffictypediagnostic: BN3PR0201MB0868: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0868; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0868; x-forefront-prvs: 0337AFFE9A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39410400002)(39840400002)(39400400002)(39850400002)(199003)(189002)(189998001)(3280700002)(97736004)(2900100001)(5660300001)(80792005)(7696004)(2501003)(7736002)(25786009)(74316002)(122556002)(2906002)(72206003)(478600001)(33656002)(230783001)(14454004)(3660700001)(6436002)(6306002)(6506006)(54896002)(55016002)(86362001)(77096006)(106356001)(9686003)(3846002)(450100002)(81156014)(99286003)(53936002)(54356999)(50986999)(38730400002)(8676002)(101416001)(81166006)(8936002)(66066001)(102836003)(6116002)(105586002)(68736007)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0868; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB0867C18E5FF7239EE991F720F1C20BN3PR0201MB0867_" MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2017 19:53:32.1556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0868 Archived-At: Subject: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 19:53:37 -0000 --_000_BN3PR0201MB0867C18E5FF7239EE991F720F1C20BN3PR0201MB0867_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During discussing the adoption of this guidelines, a question came up w.r.t= . the semantics of the non-NMDA "-state" module during the transitioning pe= riod: What kind of state do the leaves in the "-state" module represent? The appl= ied configuration or the actually used operational data? Since only of the two types can be represented, what is the guideline to mo= del the other type? Thanks, - Xufeng --_000_BN3PR0201MB0867C18E5FF7239EE991F720F1C20BN3PR0201MB0867_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During discussing the adoption of this guidelines, a= question came up w.r.t. the semantics of the non-NMDA “-state”= module during the transitioning period:

 

What kind of state do the leaves in the “-stat= e” module represent? The applied configuration or the actually used o= perational data?

Since only of the two types can be represented, what= is the guideline to model the other type?

 

Thanks,

- Xufeng

--_000_BN3PR0201MB0867C18E5FF7239EE991F720F1C20BN3PR0201MB0867_-- From nobody Tue Jun 13 13:09:40 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C92129A92; Tue, 13 Jun 2017 13:09:39 -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, RP_MATCHES_RCVD=-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 VJWcjK6Hf_xb; Tue, 13 Jun 2017 13:09:37 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE1C129A8D; Tue, 13 Jun 2017 13:09:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E4DF476; Tue, 13 Jun 2017 22:09:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id LvaWGRmJjz3C; Tue, 13 Jun 2017 22:09:35 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Jun 2017 22:09:35 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98E1320094; Tue, 13 Jun 2017 22:09:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2-MqQaqAaOkG; Tue, 13 Jun 2017 22:09:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 510B020091; Tue, 13 Jun 2017 22:09:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A47013FBEA83; Tue, 13 Jun 2017 22:09:32 +0200 (CEST) Date: Tue, 13 Jun 2017 22:09:31 +0200 From: Juergen Schoenwaelder To: Xufeng Liu Cc: "draft-dsdt-nmda-guidelines@ietf.org" , "netmod@ietf.org" Message-ID: <20170613200928.GA55527@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Xufeng Liu , "draft-dsdt-nmda-guidelines@ietf.org" , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:09:39 -0000 Hi, the typical -state tree consists of config false nodes and hence it represents operational state. This is not a transitioning period question, this is how -state trees were designed. Note also that the applied configuration is part of the operational state in NMDA - for config true objects, there is no difference between the applied configuration value and the operationally used value - they are the same. /js On Tue, Jun 13, 2017 at 07:53:32PM +0000, Xufeng Liu wrote: > During discussing the adoption of this guidelines, a question came up w.r.t. the semantics of the non-NMDA "-state" module during the transitioning period: > > What kind of state do the leaves in the "-state" module represent? The applied configuration or the actually used operational data? > Since only of the two types can be represented, what is the guideline to model the other type? > > Thanks, > - Xufeng -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 13 13:27:33 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEB3129451; Tue, 13 Jun 2017 13:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEsedtdTR4lE; Tue, 13 Jun 2017 13:27:30 -0700 (PDT) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7AA6128768; Tue, 13 Jun 2017 13:27:29 -0700 (PDT) Received: by mail-lf0-x241.google.com with SMTP id v20so14508545lfa.2; Tue, 13 Jun 2017 13:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=lgBBtBuxausWcfmggrmd7C3y7NKYUrZ9mIEsrx6Zrwk=; b=EEU+oUpMrc86W0ZaVkcO9EBUPN8fRF1H2Kngkpbu732ijyNlAfF7iKIQZfXAyOGheD DhqFZ6HkKSdhE+JMseFOdppsq4JHV6xybzDdEz3XBFnZUrOeV+AlmpXFGFT5OPTzyHiv yqxL2YDcwfVNUasG81yLICzAz231iNTZovMvS0oJ7P/h91Rn7paRUSwvuTDHRogPZn8L afUUgFr3yKEJ92cD7aMmiA5o7VluL6rLUBW14vMH7wHEng3CxWBkpwtb4yTAllaSFbfj vBqiq7LmcJqqGebxjH89R6hQbGYdOCi5q/H93TcoaUlLiDjzr2/8TMF5QuHKpdsueyo4 le0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=lgBBtBuxausWcfmggrmd7C3y7NKYUrZ9mIEsrx6Zrwk=; b=fBhy0Ai/kc1WPXByEw74A2N44nj7+c3PdSINIl8uxDlg9+2DSYkTgUDEz1GzdPz40R u+uXY2r8bI8WFZxpp3xPS6OlFf97pLWXAtf7Jd0HT2CTrvh0oVi1+8s94isA2kAuQ42R aqkKkpvEHVnnJ2ncICyVsGYjfor7YT6hlcDrHds5Wo9WoBtoN8FEiubSToVl3beoThFP 2MFxVFU2cdKR8ZOKl7ol0f8V5CiCG8a/CJgRWZZFVLveh5eQ2SBqlwZlMqzGBV12SXx4 pLhNDhTG+E+Njb0i/qYuUcL/QWounpuNJNo59k6zncPCbKi+c+h1U9So0w7bF67Ab5Ws KsgA== X-Gm-Message-State: AKS2vOyZJpcWwAdH6b2YJQLze6uzKVu3WfQiZ0GyOh6RFyJNy1e3We+9 MySbczyKSAm9et5+2nY= X-Received: by 10.46.82.157 with SMTP id n29mr564557lje.58.1497385647867; Tue, 13 Jun 2017 13:27:27 -0700 (PDT) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id i20sm3656968lfh.53.2017.06.13.13.27.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 13:27:27 -0700 (PDT) From: "Xufeng Liu" To: , Date: Tue, 13 Jun 2017 16:27:24 -0400 Message-ID: <01b901d2e483$792089f0$6b619dd0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BA_01D2E461.F213CBF0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdLkgJUUcwSA0JfMRE26worjISEc0Q== Content-Language: en-us x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXHhsaXVcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy1iM2RkNWFiYi01MDc2LTExZTctOWMxNC0xODVlMGZlM2M0NWNcYW1lLXRlc3RcYjNkZDVhYmMtNTA3Ni0xMWU3LTljMTQtMTg1ZTBmZTNjNDVjYm9keS5odG1sIiBzej0iNTE4OCIgdD0iMTMxNDE4NTkyNDM2MTg0MzAyIiBoPSJFZmtxSTlUaU9QZGpCL2k2Mjk3NnZtV2pzUW89IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+ Archived-At: Subject: [netmod] Schema-mount question: Augmentation to the Mounted Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:27:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01BA_01D2E461.F213CBF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Lada, We have got two questions on how to specify the module entries in a schema: 1. Are augmentations of parent modules inherited when augmented module is listed in schema-mounts schema? For example, ietf-ospf module augments ietf-routing. When we include ietf-routing to the schema entry, is ietf-ospf automatically included? 2. When we have ietf-yang-library mounted under a parent (LNE), does ietf-yang-library have to contain exactly the same list of Yang modules as the list contained in the "schema" entry under "schema-mount"? For example, ietf-ospf module augments ietf-routing. When we mount ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in the mount module list? And also in ietf-yang-library? It would be great if these can be clarified. Thanks, - Xufeng ------=_NextPart_000_01BA_01D2E461.F213CBF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lada,

 

We have got = two questions on how to specify the module entries in a = schema:

 

  1. Are augmentations of = parent modules inherited when augmented module is listed in = schema-mounts schema?

For example, ietf-ospf module augments = ietf-routing. When we include ietf-routing to the schema entry, is = ietf-ospf automatically included?

 

  1. When we have = ietf-yang-library mounted under a parent (LNE), does ietf-yang-library = have to contain exactly the same list of Yang modules as the list = contained in the “schema” entry under = “schema-mount”?

For example, ietf-ospf module augments = ietf-routing. When we mount ietf-routing ietf-yang-library to LNE, = should we list ietf-ospf in the mount module list? And also in = ietf-yang-library?

 

It = would be great if these can be clarified.

 

Thanks,

- = Xufeng

 

------=_NextPart_000_01BA_01D2E461.F213CBF0-- From nobody Tue Jun 13 15:35:28 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EA2131A34 for ; Tue, 13 Jun 2017 15:35:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTdpNHhWb1H5 for ; Tue, 13 Jun 2017 15:35:25 -0700 (PDT) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A9F131A2C for ; Tue, 13 Jun 2017 15:35:25 -0700 (PDT) From: Alex Campbell To: Andy Bierman , Ladislav Lhotka CC: "netmod@ietf.org" Thread-Topic: [netmod] Question on intefaces-state model Thread-Index: AdLhDRC34rNQajuWS5+4b+qYQggHyQCzfdcAAAJubIAAMwoVAAABUkEA//+9NFA= Date: Tue, 13 Jun 2017 22:35:23 +0000 Message-ID: <1497393323725.99784@Aviatnet.com> References: <20170612172141.GA52797@elstar.local> , In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.10] Content-Type: multipart/alternative; boundary="_000_149739332372599784Aviatnetcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 22:35:28 -0000 --_000_149739332372599784Aviatnetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Presumably a device is free to not implement an optional config=3Dfalse nod= e if that node would never be returned in a response anyway - as this will = make no externally visible difference. However, if the model states or implies that the node is present under cert= ain conditions (for example, the node is always present for Ethernet ports)= , and the device can meet those conditions (i.e. it has an Ethernet port), = then the device must implement the node or it does not conform to the model= . Alex ________________________________ From: netmod on behalf of Andy Bierman Sent: Wednesday, 14 June 2017 7:30 a.m. To: Ladislav Lhotka Cc: netmod@ietf.org Subject: Re: [netmod] Question on intefaces-state model On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka > wrote: Andy Bierman > writes: > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - >> BE/Antwerp) wrote: >> > >> > We have a question regarding the statistics container as defined in th= e >> > interfaces-state model. This container defines one mandatory leaf >> > (discontinuity-time) while all other leafs are optional. What is the >> > rationale behind this leaf being mandatory and not an optional field? >> > >> > It does not make a lot of sense to return a discontinuity-time value a= nd >> no >> > counters if none of the counters are relevant for a specific interface= . >> > >> > Another alternative could be to add, via a deviation, a when clause to >> the >> > container indicating for which ifType(s) the container is (or is not) >> > present. But that would lead to not supporting the IETF interfaces mod= el >> to >> > the full extent. >> > >> >> The discontinuity-time is relevant for _any_ counter associated with >> an interface, regardless whether the counter is defined in the >> interfaces model or elsewhere. I have a hard time to imagine an >> interface that has zero counters. >> >> > The mandatory-stmt is very confusing for config=3Dfalse nodes. Mandatory= =3Dtrue > means > an must contain an instance of the mandatory leaf. I don't think it is that confusing. RFC 7950 defines what a valid data tree means and "mandatory" are among the constraints. I agree though that in terms of a management protocol it means different things for config true and false data, but this is true also for default values and maybe other YANG concepts as well. > > Mandatory=3Dfalse does not mean optional-to-implement although it sure > looks that way for config=3Dfalse nodes. Only if-feature can make a node > optional to implement. I don't think this interpretation is supported by any text in the YANG spec. State data nodes that are optional needn't be implemented. RFC 7950, sec 5.6 (Conformance) does not support your interpretation. It defines basic behavior, optional (via features), and deviations as the o= nly mechanisms affecting conformance. Lada > Andy > > > /js > > > Andy > > -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 --_000_149739332372599784Aviatnetcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Presumably a device is free to not i= mplement an optional config=3Dfalse node if that node would never be return= ed in a response anyway - as this will make no externally visible differenc= e.

However, if the model states or implies that the node is present under cert= ain conditions (for example, the node is always present for Ethernet ports)= , and the device can meet those conditions (i.e. it has an Ethernet port), = then the device must implement the node or it does not conform to the model.



Alex

From: netmod <netmod-bo= unces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com>
Sent: Wednesday, 14 June 2017 7:30 a.m.
To: Ladislav Lhotka
Cc: netmod@ietf.org
Subject: Re: [netmod] Question on intefaces-state model


On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotk= a <lhotka@nic.cz>= ; wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
>> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia= -
>> BE/Antwerp) wrote:
>> >
>> > We have a question regarding the statistics container as defi= ned in the
>> > interfaces-state model.  This container defines one mand= atory leaf
>> > (discontinuity-time) while all other leafs are optional. = ; What is the
>> > rationale behind this leaf being mandatory and not an optiona= l field?
>> >
>> > It does not make a lot of sense to return a discontinuity-tim= e value and
>> no
>> > counters if none of the counters are relevant for a specific = interface.
>> >
>> > Another alternative could be to add, via a deviation, a when = clause to
>> the
>> > container indicating for which ifType(s) the container is (or= is not)
>> > present. But that would lead to not supporting the IETF inter= faces model
>> to
>> > the full extent.
>> >
>>
>> The discontinuity-time is relevant for _any_ counter associated wi= th
>> an interface, regardless whether the counter is defined in the
>> interfaces model or elsewhere. I have a hard time to imagine an >> interface that has zero counters.
>>
>>
> The mandatory-stmt is very confusing for config=3Dfalse nodes. Mandato= ry=3Dtrue
> means
> an <rpc-reply> must contain an instance of the mandatory leaf.
I don't think it is that confusing. RFC 7950 defines what a valid data
tree means and "mandatory" are among the constraints.

I agree though that in terms of a management protocol it means different things for config true and false data, but this is true also for default values and maybe other YANG concepts as well.

>
> Mandatory=3Dfalse does not mean optional-to-implement although it sure=
> looks that way for config=3Dfalse nodes.  Only if-feature can mak= e a node
> optional to implement.

I don't think this interpretation is supported by any text in the YANG
spec. State data nodes that are optional needn't be implemented.


RFC 7950, sec 5.6  (Conformance) does not support your interpreta= tion.
It defines basic behavior, optional (via features), and deviations as = the only mechanisms affecting conformance.


Lada

>


Andy
 
>
>
>  /js
>
>
> Andy
>
> --
>> Juergen Schoenwaelder           Jaco= bs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campu= s Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103        &= nbsp;<http://www.jacobs-university.de/>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

--_000_149739332372599784Aviatnetcom_-- From nobody Wed Jun 14 01:28:16 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69E1128854 for ; Wed, 14 Jun 2017 01:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 VNt43PDXDm50 for ; Wed, 14 Jun 2017 01:28:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 326EB128656 for ; Wed, 14 Jun 2017 01:28:11 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:7137:2953:3870:77fe] (unknown [IPv6:2001:718:1a02:1:7137:2953:3870:77fe]) by mail.nic.cz (Postfix) with ESMTPSA id F38BE6096F; Wed, 14 Jun 2017 10:28:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1497428890; bh=wkSenEdYQ3SUIxnL/6RphLW3h6M6Nf/TmaGVV6UjNPY=; h=From:Date:To; b=PwYIo9SHAfhtWjvs0yF10M8AVzAiLDDD68kKHp5lUcSgHTaaMCIMIt8ddmDRZirnF rp/ofBGpAgClh2UzhsCbwtvck0br6LC8O4VzJ+UGYUlChU+UYsssfx/9tTKx1rgLy/ uRwXYXTS4qjkja0MXlxri07X7cjynpuNQSGWTRP4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka In-Reply-To: <1497393323725.99784@Aviatnet.com> Date: Wed, 14 Jun 2017 10:28:09 +0200 Cc: Andy Bierman , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170612172141.GA52797@elstar.local> <1497393323725.99784@Aviatnet.com> To: Alex Campbell X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 08:28:15 -0000 > On 14 Jun 2017, at 00:35, Alex Campbell = wrote: >=20 >=20 > Presumably a device is free to not implement an optional config=3Dfalse = node if that node would never be returned in a response anyway - as this = will make no externally visible difference. That's my view, too. However, this reasoning works if the parent = container is being retrieved but it is not very clear what is supposed = to happen if the client asks explicly for that optional parameter. This = looks like a gap in the architecture =E2=80=93 most of the time, YANG = pretends to be something like a schema language in that it describes = constraints on a valid data tree but conformance issues like what = parameters a server needs to implement are something different. >=20 > However, if the model states or implies that the node is present under = certain conditions (for example, the node is always present for Ethernet = ports), and the device can meet those conditions (i.e. it has an = Ethernet port), then the device must implement the node or it does not = conform to the model. Right, this could be written in a description, but I've been assuming it = is not the case. Lada >=20 >=20 >=20 > Alex >=20 > From: netmod on behalf of Andy Bierman = > Sent: Wednesday, 14 June 2017 7:30 a.m. > To: Ladislav Lhotka > Cc: netmod@ietf.org > Subject: Re: [netmod] Question on intefaces-state model >=20 >=20 > On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > >> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - > >> BE/Antwerp) wrote: > >> > > >> > We have a question regarding the statistics container as defined = in the > >> > interfaces-state model. This container defines one mandatory = leaf > >> > (discontinuity-time) while all other leafs are optional. What is = the > >> > rationale behind this leaf being mandatory and not an optional = field? > >> > > >> > It does not make a lot of sense to return a discontinuity-time = value and > >> no > >> > counters if none of the counters are relevant for a specific = interface. > >> > > >> > Another alternative could be to add, via a deviation, a when = clause to > >> the > >> > container indicating for which ifType(s) the container is (or is = not) > >> > present. But that would lead to not supporting the IETF = interfaces model > >> to > >> > the full extent. > >> > > >> > >> The discontinuity-time is relevant for _any_ counter associated = with > >> an interface, regardless whether the counter is defined in the > >> interfaces model or elsewhere. I have a hard time to imagine an > >> interface that has zero counters. > >> > >> > > The mandatory-stmt is very confusing for config=3Dfalse nodes. = Mandatory=3Dtrue > > means > > an must contain an instance of the mandatory leaf. >=20 > I don't think it is that confusing. RFC 7950 defines what a valid data > tree means and "mandatory" are among the constraints. >=20 > I agree though that in terms of a management protocol it means = different > things for config true and false data, but this is true also for = default > values and maybe other YANG concepts as well. >=20 > > > > Mandatory=3Dfalse does not mean optional-to-implement although it = sure > > looks that way for config=3Dfalse nodes. Only if-feature can make a = node > > optional to implement. >=20 > I don't think this interpretation is supported by any text in the YANG > spec. State data nodes that are optional needn't be implemented. >=20 >=20 > RFC 7950, sec 5.6 (Conformance) does not support your interpretation. > It defines basic behavior, optional (via features), and deviations as = the only mechanisms affecting conformance. >=20 >=20 > Lada >=20 > > >=20 >=20 > Andy > =20 > > > > > > /js > > > > > > Andy > > > > -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jun 14 02:15:29 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1A01273E2 for ; Wed, 14 Jun 2017 02:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4FpjYdsFUf4 for ; Wed, 14 Jun 2017 02:15:25 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908A0126BF0 for ; Wed, 14 Jun 2017 02:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4634; q=dns/txt; s=iport; t=1497431724; x=1498641324; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=sr7sxVzfpDE9YCyZp12fOu0YTWpqpFl2hXZtJUn5B+0=; b=A0yJh8lNoOlsng1Cv8jmWW4rav0o9iU+tCh/jpZdr/EAXW/i6OGDbffF vb7gdUM9OeKJVXXb5jg4sdFOl8ejKI6dcsueWinekhSNVlu/qn4TbmWmk YjN51G7L0LuSzvWRlwFmGDF6s++MehRPKkZYnhZJ3CVNW+wKJSdow1oyH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAAAE/kBZ/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMrgQ+BDY4Oc5EDlgOCESELhS5KAoMIGAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEBATY2GQILEAgnBxsMHxEGAQwGAgEBiiAIELA0hBYBhygBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR4FhlyCC4J1hFQ3JoUsBZ5Hk1CLFYZzjDeIPh84gQowIQg?= =?us-ascii?q?bFUiGUwE7PzaJagEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,340,1493683200"; d="scan'208";a="655411553" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 09:15:22 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5E9FM9v005360; Wed, 14 Jun 2017 09:15:22 GMT To: Vladimir Vassilev , Andy Bierman , Juergen Schoenwaelder , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: <20170612172141.GA52797@elstar.local> <65e1aa8e-c37b-d323-a351-c17fa4e96b3e@transpacket.com> From: Robert Wilton Message-ID: Date: Wed, 14 Jun 2017 10:15:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <65e1aa8e-c37b-d323-a351-c17fa4e96b3e@transpacket.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:15:27 -0000 On 13/06/2017 10:15, Vladimir Vassilev wrote: > On 06/12/2017 08:31 PM, Andy Bierman wrote: > >> >> >> On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder >> > > wrote: >> >> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - >> BE/Antwerp) wrote: >> > >> > We have a question regarding the statistics container as defined >> in the >> > interfaces-state model. This container defines one mandatory leaf >> > (discontinuity-time) while all other leafs are optional. What >> is the >> > rationale behind this leaf being mandatory and not an optional >> field? >> > >> > It does not make a lot of sense to return a discontinuity-time >> value and no >> > counters if none of the counters are relevant for a specific >> interface. >> > >> > Another alternative could be to add, via a deviation, a when >> clause to the >> > container indicating for which ifType(s) the container is (or is >> not) >> > present. But that would lead to not supporting the IETF >> interfaces model to >> > the full extent. >> > >> > The alternative which we use is to not have > /interfaces-state/interface/statistics container for the interfaces > without counters. The container is mandatory=false. >> >> >> The discontinuity-time is relevant for _any_ counter associated with >> an interface, regardless whether the counter is defined in the >> interfaces model or elsewhere. I have a hard time to imagine an >> interface that has zero counters. +1 >> > There are some though. Optical amplifiers and similar equipment that > does not have counters - the status data is only signal levels. For me the question is here is whether the objects being modelled by optical amplifiers are actually interfaces or something else, and I think that they are probably something else. I appreciate that this may not be the universal view, but I think of an interface as something that forwards traffic at layer 2 or above. I.e. it is something that is potentially meaningful to have a IP address on, assign a routing protocol to, have frame or packet statistics, etc. I would rather IETF defines a separate list of objects (e.g. Cisco's IOS XR would call them 'controllers') for L1 forwarding objects, given that most of the configuration and properties of these L1 forwarding constructs is generally quite different from 'regular' interfaces. >> >> The mandatory-stmt is very confusing for config=false nodes. >> Mandatory=true means >> an must contain an instance of the mandatory leaf. >> >> Mandatory=false does not mean optional-to-implement although it sure >> looks that way for config=false nodes. Only if-feature can make a >> node optional to implement. > If we take serial interface with hardware that only has in-octets and > out-octets counters I would expect to only find these two in > /interfaces-state/interface/statistics + discontinuity-time. Do you > say the rest of the counters must be present (e.g. allways 0) for > proper implementation of ietf-interfaces? Returning zero values here is not useful, in fact it is misleading. I think that if a server doesn't have a value to return for a particular node it is much better to return nothing than to return a false value. As an aside, I think that this is also why default values for config false leaves aren't helpful because they can cause ambiguity as to whether a server has no value to return, or is instead returning the default value. Rob > > > Vladimir >> >> >> >> /js >> >> >> Andy >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> Fax: +49 421 200 3103 > > >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Wed Jun 14 02:21:58 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B0A128BBB for ; Wed, 14 Jun 2017 02:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UsPxEyVbrlJ for ; Wed, 14 Jun 2017 02:21:53 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5146A126CF9 for ; Wed, 14 Jun 2017 02:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5191; q=dns/txt; s=iport; t=1497432113; x=1498641713; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=J2UvTeoDpYpEdY42wtKbK9K4yJ7/0sa66XModoDRj7E=; b=hx94+YIriST4BBgDK/5tXVZscxlueUrFXTZIZ6j86eNexX9THY7lXf5n GGhj514FVh5I3ngxv9wn1I1EdBM+BpCSyopbGLrXAPR+0N68w283RaiE3 rMA3HNUNk17F1OfRLk4hY4AcOZ8yAYjdRZgSu0uPVP694KvBS6qTLigyv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAAAo/0BZ/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMrgQ+BDYN2ihhzkQOWA4IRIQuFLkoCgwgYAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECAQEBIQ8BBTYLDgILEAEBAwEBAQICJgICGwwiBggGAQwGAgEBiiAIE?= =?us-ascii?q?K4SgiaLPwEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQaFVoILgnWEVDcmgkuCYQW?= =?us-ascii?q?eR5NQixWGc4w3iD4fOIEKMCEIGxVIhw8/NolqAQEB?= X-IronPort-AV: E=Sophos;i="5.39,340,1493683200"; d="scan'208";a="655411683" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 09:21:51 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v5E9LpNn022733; Wed, 14 Jun 2017 09:21:51 GMT To: Ladislav Lhotka , Alex Campbell References: <20170612172141.GA52797@elstar.local> <1497393323725.99784@Aviatnet.com> Cc: "netmod@ietf.org" From: Robert Wilton Message-ID: <9f022715-51cf-a68a-b9fa-94d191af4891@cisco.com> Date: Wed, 14 Jun 2017 10:21:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:21:56 -0000 On 14/06/2017 09:28, Ladislav Lhotka wrote: >> On 14 Jun 2017, at 00:35, Alex Campbell wrote: >> >> >> Presumably a device is free to not implement an optional config=false node if that node would never be returned in a response anyway - as this will make no externally visible difference. > That's my view, too. However, this reasoning works if the parent container is being retrieved but it is not very clear what is supposed to happen if the client asks explicly for that optional parameter. This looks like a gap in the architecture – most of the time, YANG pretends to be something like a schema language in that it describes constraints on a valid data tree but conformance issues like what parameters a server needs to implement are something different. It would surely do the same thing as if a client requested any node in a YANG data tree that doesn't exist. RESTCONF has special semantics if a GET request is for a specific leaf rather than a parent container, but I just regard this as a mistake in the specification (i.e. the "restconf default handling" thread on the NETCONF alias). > >> However, if the model states or implies that the node is present under certain conditions (for example, the node is always present for Ethernet ports), and the device can meet those conditions (i.e. it has an Ethernet port), then the device must implement the node or it does not conform to the model. > Right, this could be written in a description, but I've been assuming it is not the case. > > Lada Rob > >> >> >> Alex >> >> From: netmod on behalf of Andy Bierman >> Sent: Wednesday, 14 June 2017 7:30 a.m. >> To: Ladislav Lhotka >> Cc: netmod@ietf.org >> Subject: Re: [netmod] Question on intefaces-state model >> >> >> On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka wrote: >> Andy Bierman writes: >> >>> On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < >>> j.schoenwaelder@jacobs-university.de> wrote: >>> >>>> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - >>>> BE/Antwerp) wrote: >>>>> We have a question regarding the statistics container as defined in the >>>>> interfaces-state model. This container defines one mandatory leaf >>>>> (discontinuity-time) while all other leafs are optional. What is the >>>>> rationale behind this leaf being mandatory and not an optional field? >>>>> >>>>> It does not make a lot of sense to return a discontinuity-time value and >>>> no >>>>> counters if none of the counters are relevant for a specific interface. >>>>> >>>>> Another alternative could be to add, via a deviation, a when clause to >>>> the >>>>> container indicating for which ifType(s) the container is (or is not) >>>>> present. But that would lead to not supporting the IETF interfaces model >>>> to >>>>> the full extent. >>>>> >>>> The discontinuity-time is relevant for _any_ counter associated with >>>> an interface, regardless whether the counter is defined in the >>>> interfaces model or elsewhere. I have a hard time to imagine an >>>> interface that has zero counters. >>>> >>>> >>> The mandatory-stmt is very confusing for config=false nodes. Mandatory=true >>> means >>> an must contain an instance of the mandatory leaf. >> I don't think it is that confusing. RFC 7950 defines what a valid data >> tree means and "mandatory" are among the constraints. >> >> I agree though that in terms of a management protocol it means different >> things for config true and false data, but this is true also for default >> values and maybe other YANG concepts as well. >> >>> Mandatory=false does not mean optional-to-implement although it sure >>> looks that way for config=false nodes. Only if-feature can make a node >>> optional to implement. >> I don't think this interpretation is supported by any text in the YANG >> spec. State data nodes that are optional needn't be implemented. >> >> >> RFC 7950, sec 5.6 (Conformance) does not support your interpretation. >> It defines basic behavior, optional (via features), and deviations as the only mechanisms affecting conformance. >> >> >> Lada >> >> >> Andy >> >>> >>> /js >>> >>> >>> Andy >>> >>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jun 14 02:39:53 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B72126BF0 for ; Wed, 14 Jun 2017 02:39:51 -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, RP_MATCHES_RCVD=-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 egK3HO7RnOT1 for ; Wed, 14 Jun 2017 02:39:49 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414EA12953B for ; Wed, 14 Jun 2017 02:39:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 13CFDE90; Wed, 14 Jun 2017 11:39:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id c_no5TH1Gf4G; Wed, 14 Jun 2017 11:39:45 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 14 Jun 2017 11:39:45 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFC8720091; Wed, 14 Jun 2017 11:39:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id i_47fu1kfKgM; Wed, 14 Jun 2017 11:39:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7774920090; Wed, 14 Jun 2017 11:39:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 82B873FBF5C5; Wed, 14 Jun 2017 11:39:44 +0200 (CEST) Date: Wed, 14 Jun 2017 11:39:43 +0200 From: Juergen Schoenwaelder To: Robert Wilton Cc: Vladimir Vassilev , Andy Bierman , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Message-ID: <20170614093943.GA56060@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , Vladimir Vassilev , Andy Bierman , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: <20170612172141.GA52797@elstar.local> <65e1aa8e-c37b-d323-a351-c17fa4e96b3e@transpacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:39:51 -0000 On Wed, Jun 14, 2017 at 10:15:22AM +0100, Robert Wilton wrote: > > Returning zero values here is not useful, in fact it is misleading. I think > that if a server doesn't have a value to return for a particular node it is > much better to return nothing than to return a false value. +1. It took us years to kill this attitude in SNMP land. Saying a counter is zero and never changes is largely misleading if you actually have no such counter. It is easy to waste hours of expensive engineering time by given people fake counters. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jun 14 02:46:21 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB841129568 for ; Wed, 14 Jun 2017 02:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 ApiXuwrMBXol for ; Wed, 14 Jun 2017 02:46:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 D7000128CDC for ; Wed, 14 Jun 2017 02:46:17 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:7137:2953:3870:77fe] (unknown [IPv6:2001:718:1a02:1:7137:2953:3870:77fe]) by mail.nic.cz (Postfix) with ESMTPSA id BCDBC6091C; Wed, 14 Jun 2017 11:46:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1497433574; bh=ZLGE/pDXR1kbZWzKNbMLy0j4R5jCJ291uGi6+u7xM4Y=; h=From:Date:To; b=q9CuIlpKIVmm7VxvYYDsx+o77PVT+gGNmlUaAV1qxwt8ZjMqx8QxiYK/uGlf4hifW RRCDwdpLUBsUT86RZs8qVIh9oY2z/hinXBnwTNhJ6eRyF+fcI+3vNItI8KyqS3Kz0Y oAJAGcsMATj5BvFtzBEkrbWVkU59iIhidUbVekBQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka In-Reply-To: <9f022715-51cf-a68a-b9fa-94d191af4891@cisco.com> Date: Wed, 14 Jun 2017 11:46:14 +0200 Cc: Alex Campbell , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5634D470-693E-499A-BDBB-FE8BB4F2E553@nic.cz> References: <20170612172141.GA52797@elstar.local> <1497393323725.99784@Aviatnet.com> <9f022715-51cf-a68a-b9fa-94d191af4891@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 09:46:21 -0000 > On 14 Jun 2017, at 11:21, Robert Wilton wrote: >=20 >=20 >=20 > On 14/06/2017 09:28, Ladislav Lhotka wrote: >>> On 14 Jun 2017, at 00:35, Alex Campbell = wrote: >>>=20 >>>=20 >>> Presumably a device is free to not implement an optional = config=3Dfalse node if that node would never be returned in a response = anyway - as this will make no externally visible difference. >> That's my view, too. However, this reasoning works if the parent = container is being retrieved but it is not very clear what is supposed = to happen if the client asks explicly for that optional parameter. This = looks like a gap in the architecture =E2=80=93 most of the time, YANG = pretends to be something like a schema language in that it describes = constraints on a valid data tree but conformance issues like what = parameters a server needs to implement are something different. > It would surely do the same thing as if a client requested any node in = a YANG data tree that doesn't exist. So you are saying that one server can return the parameter but another = may report "404 Not Found", correct? >=20 > RESTCONF has special semantics if a GET request is for a specific leaf = rather than a parent container, but I just regard this as a mistake in = the specification (i.e. the "restconf default handling" thread on the = NETCONF alias). Defaults are another can of worms. If we have an optional config false = parameter with a default defined in YANG and the server doesn't = implement the parameter (and hence doesn't send it), can the client = assume that the server actually has the default value? Lada >=20 >=20 >>=20 >>> However, if the model states or implies that the node is present = under certain conditions (for example, the node is always present for = Ethernet ports), and the device can meet those conditions (i.e. it has = an Ethernet port), then the device must implement the node or it does = not conform to the model. >> Right, this could be written in a description, but I've been assuming = it is not the case. >>=20 >> Lada > Rob >=20 >>=20 >>>=20 >>>=20 >>> Alex >>>=20 >>> From: netmod on behalf of Andy Bierman = >>> Sent: Wednesday, 14 June 2017 7:30 a.m. >>> To: Ladislav Lhotka >>> Cc: netmod@ietf.org >>> Subject: Re: [netmod] Question on intefaces-state model >>>=20 >>>=20 >>> On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka = wrote: >>> Andy Bierman writes: >>>=20 >>>> On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < >>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>=20 >>>>> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - >>>>> BE/Antwerp) wrote: >>>>>> We have a question regarding the statistics container as defined = in the >>>>>> interfaces-state model. This container defines one mandatory = leaf >>>>>> (discontinuity-time) while all other leafs are optional. What is = the >>>>>> rationale behind this leaf being mandatory and not an optional = field? >>>>>>=20 >>>>>> It does not make a lot of sense to return a discontinuity-time = value and >>>>> no >>>>>> counters if none of the counters are relevant for a specific = interface. >>>>>>=20 >>>>>> Another alternative could be to add, via a deviation, a when = clause to >>>>> the >>>>>> container indicating for which ifType(s) the container is (or is = not) >>>>>> present. But that would lead to not supporting the IETF = interfaces model >>>>> to >>>>>> the full extent. >>>>>>=20 >>>>> The discontinuity-time is relevant for _any_ counter associated = with >>>>> an interface, regardless whether the counter is defined in the >>>>> interfaces model or elsewhere. I have a hard time to imagine an >>>>> interface that has zero counters. >>>>>=20 >>>>>=20 >>>> The mandatory-stmt is very confusing for config=3Dfalse nodes. = Mandatory=3Dtrue >>>> means >>>> an must contain an instance of the mandatory leaf. >>> I don't think it is that confusing. RFC 7950 defines what a valid = data >>> tree means and "mandatory" are among the constraints. >>>=20 >>> I agree though that in terms of a management protocol it means = different >>> things for config true and false data, but this is true also for = default >>> values and maybe other YANG concepts as well. >>>=20 >>>> Mandatory=3Dfalse does not mean optional-to-implement although it = sure >>>> looks that way for config=3Dfalse nodes. Only if-feature can make = a node >>>> optional to implement. >>> I don't think this interpretation is supported by any text in the = YANG >>> spec. State data nodes that are optional needn't be implemented. >>>=20 >>>=20 >>> RFC 7950, sec 5.6 (Conformance) does not support your = interpretation. >>> It defines basic behavior, optional (via features), and deviations = as the only mechanisms affecting conformance. >>>=20 >>>=20 >>> Lada >>>=20 >>>=20 >>> Andy >>> =20 >>>>=20 >>>> /js >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>> Fax: +49 421 200 3103 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>>=20 >>>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jun 14 03:35:40 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C1C129BE8 for ; Wed, 14 Jun 2017 03:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INkpp-ff5jLv for ; Wed, 14 Jun 2017 03:35:36 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2F3129BDD for ; Wed, 14 Jun 2017 03:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7592; q=dns/txt; s=iport; t=1497436535; x=1498646135; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=TGANCy0AyRveJUC3Fq2Ldq9EDP+FC9q3GvcalDno0t0=; b=M+KyNaMeUY9wfckm5CTqhrz3AVEruJW4udxpC0e0f8ZhnJex5VujCNpP QL5slzFazovkWrDnHmJ3GGnj39g5ESDZYdXsc+9R2L0RlhWBwFHC8ivr2 3z8WU9p/C0vkz3ZxkSCxqlw2WYYj/qYrtFa8eSe00JrkBA2M9LWvqdrW4 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAAAPEUFZ/xbLJq1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMrgQ+BDYN2ihhzkQOWA4IRIQuFLkoCgwoYAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECAQEBIQ8BBTYLDgILEAEBAwEBAQICJgICGwwiBggGCgMGAgEBiiAIE?= =?us-ascii?q?K4cgiaLPgEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQaFVoFgK4J1hFQ3JoJLgmE?= =?us-ascii?q?FnkeTUIsVhnOMN4g+HziBCjAhCBsVSIcPPzaJagEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,340,1493683200"; d="scan'208";a="695137233" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 10:35:33 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5EAZX7r002889; Wed, 14 Jun 2017 10:35:33 GMT To: Ladislav Lhotka References: <20170612172141.GA52797@elstar.local> <1497393323725.99784@Aviatnet.com> <9f022715-51cf-a68a-b9fa-94d191af4891@cisco.com> <5634D470-693E-499A-BDBB-FE8BB4F2E553@nic.cz> Cc: Alex Campbell , "netmod@ietf.org" From: Robert Wilton Message-ID: <213f4274-7fe3-5ec3-01ed-49d367130c29@cisco.com> Date: Wed, 14 Jun 2017 11:35:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5634D470-693E-499A-BDBB-FE8BB4F2E553@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 10:35:39 -0000 On 14/06/2017 10:46, Ladislav Lhotka wrote: >> On 14 Jun 2017, at 11:21, Robert Wilton wrote: >> >> >> >> On 14/06/2017 09:28, Ladislav Lhotka wrote: >>>> On 14 Jun 2017, at 00:35, Alex Campbell wrote: >>>> >>>> >>>> Presumably a device is free to not implement an optional config=false node if that node would never be returned in a response anyway - as this will make no externally visible difference. >>> That's my view, too. However, this reasoning works if the parent container is being retrieved but it is not very clear what is supposed to happen if the client asks explicly for that optional parameter. This looks like a gap in the architecture – most of the time, YANG pretends to be something like a schema language in that it describes constraints on a valid data tree but conformance issues like what parameters a server needs to implement are something different. >> It would surely do the same thing as if a client requested any node in a YANG data tree that doesn't exist. > So you are saying that one server can return the parameter but another may report "404 Not Found", correct? Yes. > >> RESTCONF has special semantics if a GET request is for a specific leaf rather than a parent container, but I just regard this as a mistake in the specification (i.e. the "restconf default handling" thread on the NETCONF alias). > Defaults are another can of worms. If we have an optional config false parameter with a default defined in YANG and the server doesn't implement the parameter (and hence doesn't send it), can the client assume that the server actually has the default value? Not in any way that is reliable. I.e. sometimes the client may make this assumption and just be wrong! One of the key themes running through the NMDA work has been to try and get more integrity and consistence between the data that is being returned. So, in the NMDA world, I think that there are really only two "with-default" options that are robust and most useful: (1) For the candidate/running/status datastores, where the content of the datastore is controlled by the client, then the explicit mode is the sane default choice. I.e. generally you should get out exactly what you put in. (2) For the operational state datastore, the report-all mode is the sane choice, because this is the only one that allows a client to detect that a server is choosing to return no value rather than the default value. I do appreciate that the other with-defaults options can be used to either minimize the amount of data being transferred (potentially at the expense of data accuracy), or provide a consolidated view of the configuration (e.g. to avoid the client constructing the same combined view itself). But I think that the client should have to opt in if they want to see these, and the normal behaviour should be to favour correctness and explicitness. Hence, I wish there had been more consistency with the normal choice of default mode in the standard rather that leaving it up to the server implementation to decide, thus requiring that clients have to cope with a mismash of default handling flavours. Rob > > Lada > >> >>>> However, if the model states or implies that the node is present under certain conditions (for example, the node is always present for Ethernet ports), and the device can meet those conditions (i.e. it has an Ethernet port), then the device must implement the node or it does not conform to the model. >>> Right, this could be written in a description, but I've been assuming it is not the case. >>> >>> Lada >> Rob >> >>>> >>>> Alex >>>> >>>> From: netmod on behalf of Andy Bierman >>>> Sent: Wednesday, 14 June 2017 7:30 a.m. >>>> To: Ladislav Lhotka >>>> Cc: netmod@ietf.org >>>> Subject: Re: [netmod] Question on intefaces-state model >>>> >>>> >>>> On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka wrote: >>>> Andy Bierman writes: >>>> >>>>> On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < >>>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>> >>>>>> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - >>>>>> BE/Antwerp) wrote: >>>>>>> We have a question regarding the statistics container as defined in the >>>>>>> interfaces-state model. This container defines one mandatory leaf >>>>>>> (discontinuity-time) while all other leafs are optional. What is the >>>>>>> rationale behind this leaf being mandatory and not an optional field? >>>>>>> >>>>>>> It does not make a lot of sense to return a discontinuity-time value and >>>>>> no >>>>>>> counters if none of the counters are relevant for a specific interface. >>>>>>> >>>>>>> Another alternative could be to add, via a deviation, a when clause to >>>>>> the >>>>>>> container indicating for which ifType(s) the container is (or is not) >>>>>>> present. But that would lead to not supporting the IETF interfaces model >>>>>> to >>>>>>> the full extent. >>>>>>> >>>>>> The discontinuity-time is relevant for _any_ counter associated with >>>>>> an interface, regardless whether the counter is defined in the >>>>>> interfaces model or elsewhere. I have a hard time to imagine an >>>>>> interface that has zero counters. >>>>>> >>>>>> >>>>> The mandatory-stmt is very confusing for config=false nodes. Mandatory=true >>>>> means >>>>> an must contain an instance of the mandatory leaf. >>>> I don't think it is that confusing. RFC 7950 defines what a valid data >>>> tree means and "mandatory" are among the constraints. >>>> >>>> I agree though that in terms of a management protocol it means different >>>> things for config true and false data, but this is true also for default >>>> values and maybe other YANG concepts as well. >>>> >>>>> Mandatory=false does not mean optional-to-implement although it sure >>>>> looks that way for config=false nodes. Only if-feature can make a node >>>>> optional to implement. >>>> I don't think this interpretation is supported by any text in the YANG >>>> spec. State data nodes that are optional needn't be implemented. >>>> >>>> >>>> RFC 7950, sec 5.6 (Conformance) does not support your interpretation. >>>> It defines basic behavior, optional (via features), and deviations as the only mechanisms affecting conformance. >>>> >>>> >>>> Lada >>>> >>>> >>>> Andy >>>> >>>>> /js >>>>> >>>>> >>>>> Andy >>>>> >>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>>> Fax: +49 421 200 3103 >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>> >>>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > . > From nobody Wed Jun 14 04:17:41 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F830126579; Wed, 14 Jun 2017 04:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrZcQU0R1B_u; Wed, 14 Jun 2017 04:17:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BD6B61201FA; Wed, 14 Jun 2017 04:17:37 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 8E25418216B4; Wed, 14 Jun 2017 13:19:03 +0200 (CEST) Received: from localhost (unknown [195.113.220.115]) by trail.lhotka.name (Postfix) with ESMTPSA id 7216A18201A2; Wed, 14 Jun 2017 13:19:02 +0200 (CEST) From: Ladislav Lhotka To: Xufeng Liu , draft-ietf-netmod-schema-mount@ietf.org, netmod@ietf.org In-Reply-To: <01b901d2e483$792089f0$6b619dd0$@gmail.com> References: <01b901d2e483$792089f0$6b619dd0$@gmail.com> Date: Wed, 14 Jun 2017 13:17:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Schema-mount question: Augmentation to the Mounted Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:17:40 -0000 Hi Xufeng, please see my answers inline. Xufeng Liu writes: > Hi Lada, > > > > We have got two questions on how to specify the module entries in a schema: > > > > 1. Are augmentations of parent modules inherited when augmented module > is listed in schema-mounts schema? > > For example, ietf-ospf module augments ietf-routing. When we include > ietf-routing to the schema entry, is ietf-ospf automatically included? No, you also have to include "ietf-ospf" in the "module" list inside the corresponding "schema" entry, exactly as you do in the top level YANG library, otherwise ietf-ospf won't be mounted. > > > > 2. When we have ietf-yang-library mounted under a parent (LNE), does > ietf-yang-library have to contain exactly the same list of Yang modules as > the list contained in the "schema" entry under "schema-mount"? I am not sure I understand but do you mean an LNE mounted schema defined via the "use-schema" case that also includes ietf-yang-library? This is a corner case we probably haven't thought about but it IMO doesn't make any sense to do so because the applicable YANG library that counts is inside the "schema" entry. Martin, should we address this anomaly? BTW, I think that normally LNE schema is supposed to be mounted using the "inline" case, and then of course ietf-yang-library is required but there is no "schema" entry under "schema-mounts" to worry about. Lada > > For example, ietf-ospf module augments ietf-routing. When we mount > ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in the mount > module list? And also in ietf-yang-library? > > > > It would be great if these can be clarified. > > > > Thanks, > > - Xufeng > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jun 14 04:18:21 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089CA126579 for ; Wed, 14 Jun 2017 04:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 1dRhMp7EUMda for ; Wed, 14 Jun 2017 04:18:17 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40117.outbound.protection.outlook.com [40.107.4.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC4C1201FA for ; Wed, 14 Jun 2017 04:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Xwh599NMSN1KDXFsY3fhtscRY9ZB0Oa7ulkd2zNGuq4=; b=s4+scyAxhFCHXcSfeLLyJa2CFeWV3ERkZfCtp5P3BBFlvcEbp1uFqnOQ3sVO1tuTpGmrG4R6fs+2ySf/heTyOxJSeeO5zsTuZkdf7ePvEgUg1pqcbrY50u/a8ymK4wHTTGuFnyA2qJc5U4mWW+wiL9+LGYhgHhf/mGpC44EWyzE= Received: from AM3PR07MB0632.eurprd07.prod.outlook.com (10.160.4.12) by AM3PR07MB0645.eurprd07.prod.outlook.com (10.160.4.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5; Wed, 14 Jun 2017 11:18:13 +0000 Received: from AM3PR07MB0632.eurprd07.prod.outlook.com ([fe80::1522:73c9:f5c2:15e2]) by AM3PR07MB0632.eurprd07.prod.outlook.com ([fe80::1522:73c9:f5c2:15e2%14]) with mapi id 15.01.1178.008; Wed, 14 Jun 2017 11:18:13 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Juergen Schoenwaelder , "Robert Wilton" CC: Vladimir Vassilev , Andy Bierman , "netmod@ietf.org" Thread-Topic: [netmod] Question on intefaces-state model Thread-Index: AdLhDRC34rNQajuWS5+4b+qYQggHyQD4bFgwAADZKIAAA2Ou8A== Date: Wed, 14 Jun 2017 11:18:13 +0000 Message-ID: References: <20170612172141.GA52797@elstar.local> <65e1aa8e-c37b-d323-a351-c17fa4e96b3e@transpacket.com> <20170614093943.GA56060@elstar.local> In-Reply-To: <20170614093943.GA56060@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0645; 7:QNYtUteLWehc85PxXXkL5fjDeulXshWrm/e/IN0Hnrwj0wr8Md4iAFOaozfY3cmxlzUXhLCMBcmvoDU0KVwp0NhSs/RVqB3zn8rogTXlm85I202NiSM+p//tTDyBC+NzsmQSnbGZgerBZyhcUTdhzDRdTzjvpoSqpTLfZAgFiMfDjlnZdRmfDquwDgksvlVGdFTOAlCKzwiuBIydQuEHna0fH9nT6eoqEUxxWQUB3EIXxiegfvd/unXmOYqivSxbKSGOTC8LFpXqyqGOQAwe1/GC0X//tpKNT/IxGt2+rlbXPnF+gWhyT3M5MZf9inYBl0vbYfm9AQPeckwLTzTH0VSbYxS3xhYAVWFPoSKnyY7jz+uijJ9Xszgh7t+ywPXOFh/PblJzziij269QR/YXaRHPiuNHA3k6ZHyOgAV34a0h7jvltG1Su6pxgTB2HUUT3SP6W3FcKEVHrLfW2Jcg4OQtNz+JmeaaZqQGpvVhT7bFtIF9py6UUkqKX8r9Wu+5JWAmahwiACHkvA0aJoU5Iv1byTrfz9D8dMnzGrN9Y9IJoFPqAUx3Ztdfey80IdnnBVtdrdAo+/Paj2NRyWyf11zaMV99AQkvKUbSNuMCOSabzzjpqEsWmleOSkkHw51hW8MV5MhGY/OXVomGCFhNbVUf47T6kMJC+CF5p+hDCN64QfwTw70y67srkQ6b8oyGYlXaUfPm67+ZipRlEKTwGKKisG1i3Qy4PruhMgOmGb16FXH1RR/6RLG4V1Ni5brOVg3l3gulu3FB7mxvooF8EFSjySPiUB4262ZDY6fdu+s= x-ms-office365-filtering-correlation-id: 650841fe-be83-4a77-806c-08d4b3170c48 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM3PR07MB0645; x-ms-traffictypediagnostic: AM3PR07MB0645: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(82608151540597)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0645; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0645; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39400400002)(39840400002)(39450400003)(39410400002)(13464003)(24454002)(189998001)(53936002)(8936002)(38730400002)(5660300001)(305945005)(6246003)(478600001)(3846002)(102836003)(6116002)(66066001)(74316002)(5250100002)(86362001)(76176999)(54356999)(50986999)(229853002)(99936001)(9686003)(55016002)(6306002)(7736002)(2900100001)(99286003)(54906002)(2906002)(81166006)(2950100002)(53546009)(33656002)(3280700002)(25786009)(14454004)(7696004)(3660700001)(6436002)(4326008)(6506006)(93886004)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB0645; H:AM3PR07MB0632.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_023C_01D2E510.AC341EA0" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2017 11:18:13.4928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0645 Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:18:20 -0000 ------=_NextPart_000_023C_01D2E510.AC341EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That's why these counters are optional in the model: if there is nothing to return we should indeed not return 0... -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: 14 June 2017 11:40 To: Robert Wilton Cc: Vladimir Vassilev ; Andy Bierman ; Bogaert, Bart (Nokia - BE/Antwerp) ; netmod@ietf.org Subject: Re: [netmod] Question on intefaces-state model On Wed, Jun 14, 2017 at 10:15:22AM +0100, Robert Wilton wrote: > > Returning zero values here is not useful, in fact it is misleading. I > think that if a server doesn't have a value to return for a particular > node it is much better to return nothing than to return a false value. +1. It took us years to kill this attitude in SNMP land. Saying a counter is zero and never changes is largely misleading if you actually have no such counter. It is easy to waste hours of expensive engineering time by given people fake counters. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 ------=_NextPart_000_023C_01D2E510.AC341EA0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA2MTQxMTE4MTFaMCMGCSqGSIb3DQEJBDEWBBTB5TNr zQZMXKtLYbJzUMkbs6LFjDCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAAHwT1OvSLfRg6L/IU4ipIeKXcZ6jWE5ERNWrGCRxyXy2ps7nUftTEvdTECF 5fgh4M0++WtVNrEDOWB+Z40gBr5Xg5f88zoAjkGwvdmguRFpJ7ZJPxt6oFeBPYvVKVZ6tfClkLdJ YiTBDLMw1Te3O3XfFWCCIIJdukG9yNLmLhJlAXiv/+zBduoHO6dq2yP8cgNylGlmKCjvl0OYZ8GJ +hTjfzkNXMMNnPqkdrgfZAO1xzer0OXNVBozrqzcph+Vaofraup4IMSgAVDItTYTzharG68PIxhF ERcoRTrNXhhRBwMX+qjt/di6Puc3YLLVIr9S+S98AJ02vyvV96v77sQAAAAAAAA= ------=_NextPart_000_023C_01D2E510.AC341EA0-- From nobody Wed Jun 14 04:43:29 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4121A12EBB0 for ; Wed, 14 Jun 2017 04:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 FWvfyEmVM1-g for ; Wed, 14 Jun 2017 04:43:23 -0700 (PDT) Received: from gproxy10.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 1546912EBB1 for ; Wed, 14 Jun 2017 04:43:21 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id D23E11405C2 for ; Wed, 14 Jun 2017 05:43:18 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id YbjE1v00g2SSUrH01bjHw6; Wed, 14 Jun 2017 05:43:18 -0600 X-Authority-Analysis: v=2.2 cv=VKStp5HX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=pGLkceISAAAA:8 a=Cs676VMd2xgWf8Qfb7oA:9 a=Ryb1F5nhlJBJkL1Z:21 a=dIGVSRpketvDe-Da:21 a=QEXdDO2ut3YA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Cvkbk2W7QqZPV/Uvm03I3BM9Ewq71bubAb5GJtZjRbU=; b=YbOcePaaVUh4wNUEcvbuhS6IPc 5mDwmENYc1DDpoC3qIlxoCutLHPtqWpR7H44xHB5GleCP9WcKHzdDETYu8SVm21wUHEqcLfWBdfFp MmO6joS+FHg4D5as4p0dvY5qt; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:53154 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dL6he-0005zi-NW; Wed, 14 Jun 2017 05:43:14 -0600 To: Ladislav Lhotka , Xufeng Liu , draft-ietf-netmod-schema-mount@ietf.org, netmod@ietf.org References: <01b901d2e483$792089f0$6b619dd0$@gmail.com> From: Lou Berger Message-ID: Date: Wed, 14 Jun 2017 07:43:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dL6he-0005zi-NW X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:53154 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] Schema-mount question: Augmentation to the Mounted Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:43:27 -0000 Hi, (speaking as contributor...) On 6/14/2017 7:17 AM, Ladislav Lhotka wrote: > Hi Xufeng, > > please see my answers inline. > > Xufeng Liu writes: > >> Hi Lada, >> >> >> >> We have got two questions on how to specify the module entries in a schema: >> >> >> >> 1. Are augmentations of parent modules inherited when augmented module >> is listed in schema-mounts schema? >> >> For example, ietf-ospf module augments ietf-routing. When we include >> ietf-routing to the schema entry, is ietf-ospf automatically included? > No, you also have to include "ietf-ospf" in the "module" list inside the > corresponding "schema" entry, exactly as you do in the top level YANG > library, otherwise ietf-ospf won't be mounted. I agree. The draft should have text that makes this explicit. >> >> >> 2. When we have ietf-yang-library mounted under a parent (LNE), does >> ietf-yang-library have to contain exactly the same list of Yang modules as >> the list contained in the "schema" entry under "schema-mount"? > I am not sure I understand but do you mean an LNE mounted schema defined via > the "use-schema" case that also includes ietf-yang-library? This is a > corner case we probably haven't thought about but it IMO doesn't make > any sense to do so because the applicable YANG library that counts is > inside the "schema" entry. Martin, should we address this anomaly? I think this is a very real scenario for LNE. Consider a 'host' system that allows read only views of the LNE and wants the benefit of "use-schema". In this case, library under the mount point is still needed for client access within the mounted LNE. It seems to me that in this case the mounted library module data must exactly match what is listed in the corresponding "schema" entry under "schema-mount" in order to ensure deterministic client views/behavior. Again, I think this should be made explicit in the draft. > BTW, I think that normally LNE schema is supposed to be mounted using the > "inline" case, and then of course ietf-yang-library is required but > there is no "schema" entry under "schema-mounts" to worry about. Both inline and non-inline LNE usage is expected in real systems... Lou > Lada > >> For example, ietf-ospf module augments ietf-routing. When we mount >> ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in the mount >> module list? And also in ietf-yang-library? >> >> >> >> It would be great if these can be clarified. >> >> >> >> Thanks, >> >> - Xufeng >> >> >> From nobody Wed Jun 14 06:01:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C7512E052; Wed, 14 Jun 2017 06:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.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 AJBFBRBOUJYZ; Wed, 14 Jun 2017 06:01:42 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0099.outbound.protection.outlook.com [104.47.36.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D18A1294F8; Wed, 14 Jun 2017 06:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ccsXHzpt0KmzouCb5Rt4pUAfBzV7ZQFV7z3jEn7c5Ac=; b=q7TC0ge4YdFimRo50nR42rMWV+2tFcbKEYJhuvyS8RQZ4xQJ/49Tb2aYJcZLQVuspuCuVwHcO47uX3MXl9TuukdxQ9a3MZxuv3FE90wcCSlu3+LCLpplm81A8uF21j1a7LxOi2Vvutr+mq/fNg4phiWKZj8BkVPAHln0MBUpjUA= Received: from CY1PR0201MB0875.namprd02.prod.outlook.com (10.160.163.141) by CY1PR0201MB0876.namprd02.prod.outlook.com (10.160.163.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.12; Wed, 14 Jun 2017 13:01:39 +0000 Received: from CY1PR0201MB0875.namprd02.prod.outlook.com ([10.160.163.141]) by CY1PR0201MB0875.namprd02.prod.outlook.com ([10.160.163.141]) with mapi id 15.01.1157.017; Wed, 14 Jun 2017 13:01:40 +0000 From: Xufeng Liu To: Juergen Schoenwaelder CC: "draft-dsdt-nmda-guidelines@ietf.org" , "netmod@ietf.org" Thread-Topic: Clarification Question on draft-dsdt-nmda-guidelines-01 Thread-Index: AdLke06/vgT9KziZR8agaNlzO3lZRwABaj2AACMV6gA= Date: Wed, 14 Jun 2017 13:01:39 +0000 Message-ID: References: <20170613200928.GA55527@elstar.local> In-Reply-To: <20170613200928.GA55527@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTk5MmNlMGVlLTUxMDEtMTFlNy05YzE0LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFw5OTJjZTBmMC01MTAxLTExZTctOWMxNC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjE4NDciIHQ9IjEzMTQxOTE4ODk3Nzg4MjEyOCIgaD0iS3dpMGhOdFVmTnN6RW5VanAzR3MxU3FxUU9jPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0201MB0876; 7:VwZ6obNKFIEx8ghiQ8jkvQhCbc3qzpJt5rinDmtwRgRB9pnhRd/aIF6ORVNP98luaf6EWBrldZ0aJbMmU/0oVyQfngh/KPr1aOzdP/ywGsI/M7P7ozaHrYBS15p5//HvLT3FNK2QdfL4ZWiW9O9iSdfLoqWjhpvAHkbRbe9tZ1HMr68l/6aS6bH/EI6IlCmcvuReT3Rux89E2Ch66He0Zav8VXrhBY8MSpyuKIzVN0nWWgduvW5cr4kjixSghNMbmbSzHav/CDLpiAoU5TXpisvoxp8ehbxkYN8VfP6yDMXCotp6X4Kt0rzNI57WL7HcSAdeW4tY4W7/b7XtbiI0jA== x-ms-traffictypediagnostic: CY1PR0201MB0876: x-ms-office365-filtering-correlation-id: 826bf50c-9221-4a44-18e6-08d4b3257f7d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:CY1PR0201MB0876; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21534305686606); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201703061421075)(201703161042150)(20161123558100)(6072148)(6042181)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0201MB0876; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0201MB0876; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(51444003)(51914003)(24454002)(74316002)(3846002)(6916009)(50986999)(6246003)(76176999)(54356999)(7696004)(86362001)(33656002)(2950100002)(498600001)(5660300001)(54906002)(72206003)(3280700002)(102836003)(6306002)(3660700001)(6506006)(6436002)(77096006)(9686003)(80792005)(38730400002)(230783001)(110136004)(55016002)(6116002)(99286003)(229853002)(53936002)(14454004)(81166006)(8936002)(53546009)(4326008)(25786009)(2900100001)(189998001)(2906002)(66066001)(122556002)(7736002)(305945005)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0201MB0876; H:CY1PR0201MB0875.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2017 13:01:39.8274 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB0876 Archived-At: Subject: Re: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:01:45 -0000 Hi Juergen, Thanks for the confirmation. As for the distinction between applied configuration and operational, I thi= nk that it has been determined to be useful in some use cases. We can creat= e a separate leaf in such a case. Regards, - Xufeng > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, June 13, 2017 4:10 PM > To: Xufeng Liu > Cc: draft-dsdt-nmda-guidelines@ietf.org; netmod@ietf.org > Subject: Re: Clarification Question on draft-dsdt-nmda-guidelines-01 >=20 > Hi, >=20 > the typical -state tree consists of config false nodes and hence it repre= sents > operational state. This is not a transitioning period question, this is h= ow -state > trees were designed. Note also that the applied configuration is part of = the > operational state in NMDA - for config true objects, there is no differen= ce > between the applied configuration value and the operationally used value = - they > are the same. >=20 > /js >=20 > On Tue, Jun 13, 2017 at 07:53:32PM +0000, Xufeng Liu wrote: > > During discussing the adoption of this guidelines, a question came up w= .r.t. the > semantics of the non-NMDA "-state" module during the transitioning period= : > > > > What kind of state do the leaves in the "-state" module represent? The = applied > configuration or the actually used operational data? > > Since only of the two types can be represented, what is the guideline t= o model > the other type? > > > > Thanks, > > - Xufeng >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Wed Jun 14 06:13:47 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A8F1294F8 for ; Wed, 14 Jun 2017 06:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn-v_45b-Qtn for ; Wed, 14 Jun 2017 06:13:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF51126FDC for ; Wed, 14 Jun 2017 06:13:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIM69978; Wed, 14 Jun 2017 13:13:39 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 14 Jun 2017 14:13:39 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.136]) with mapi id 14.03.0301.000; Wed, 14 Jun 2017 06:13:29 -0700 From: Igor Bryskin To: "lhotka@nic.cz" , "Alex.Campbell@Aviatnet.com" CC: "netmod@ietf.org" Thread-Topic: [netmod] Question on intefaces-state model Thread-Index: AdLhDRC34rNQajuWS5+4b+qYQggHyQCzfdcAAAJubIAAMwoVAAABUkEA//+9NFCAARwNgP//2mB0 Date: Wed, 14 Jun 2017 13:13:29 +0000 Message-ID: References: <20170612172141.GA52797@elstar.local> <1497393323725.99784@Aviatnet.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_etPan594136925bf1d2351987localhost_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.59413684.0095, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2efbd0e213a21e4d2a52a62e25a1fe4a Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:13:46 -0000 --_000_etPan594136925bf1d2351987localhost_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Franchesco, To your point 1: I was describing a very common use case when a client owns/ controls OTN TT= Ps, while the multi domain network provides connectivity betweeb access lin= ks across the network. In this cae network only deals with transit segments= (neither head nor tail) To your point 2 There is only one thing aboutb OTN transit segments that is OTN specific = - bandwidth. Because the configuration of a transit OTN segment needs to include the ex= act ODUk container (to match the container on the opposite side of the inco= ming access/interdomain link) - said ODUk container is expected to be encod= ed as a generic label subobject that follows the network side access/inter= domain link subobject - this alone tells the network controller everything= it needs to know about the required bandwidth. In short, for this use case you dont need OTN augmentation to support client -network interface - base /generic TE tunnel model work= s just fine, I do agree that every use case that requires provisioning by network OTN T= TPs does require the OTN augmentation. Igor From:Ladislav Lhotka To:Alex Campbell, Cc:netmod@ietf.org, Date:2017-06-14 04:28:51 Subject:Re: [netmod] Question on intefaces-state model > On 14 Jun 2017, at 00:35, Alex Campbell wrot= e: > > > Presumably a device is free to not implement an optional config=3Dfalse n= ode if that node would never be returned in a response anyway - as this wil= l make no externally visible difference. That's my view, too. However, this reasoning works if the parent container = is being retrieved but it is not very clear what is supposed to happen if t= he client asks explicly for that optional parameter. This looks like a gap = in the architecture =96 most of the time, YANG pretends to be something lik= e a schema language in that it describes constraints on a valid data tree b= ut conformance issues like what parameters a server needs to implement are = something different. > > However, if the model states or implies that the node is present under ce= rtain conditions (for example, the node is always present for Ethernet port= s), and the device can meet those conditions (i.e. it has an Ethernet port)= , then the device must implement the node or it does not conform to the mod= el. Right, this could be written in a description, but I've been assuming it is= not the case. Lada > > > > Alex > > From: netmod on behalf of Andy Bierman > Sent: Wednesday, 14 June 2017 7:30 a.m. > To: Ladislav Lhotka > Cc: netmod@ietf.org > Subject: Re: [netmod] Question on intefaces-state model > > > On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > >> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - > >> BE/Antwerp) wrote: > >> > > >> > We have a question regarding the statistics container as defined in = the > >> > interfaces-state model. This container defines one mandatory leaf > >> > (discontinuity-time) while all other leafs are optional. What is th= e > >> > rationale behind this leaf being mandatory and not an optional field= ? > >> > > >> > It does not make a lot of sense to return a discontinuity-time value= and > >> no > >> > counters if none of the counters are relevant for a specific interfa= ce. > >> > > >> > Another alternative could be to add, via a deviation, a when clause = to > >> the > >> > container indicating for which ifType(s) the container is (or is not= ) > >> > present. But that would lead to not supporting the IETF interfaces m= odel > >> to > >> > the full extent. > >> > > >> > >> The discontinuity-time is relevant for _any_ counter associated with > >> an interface, regardless whether the counter is defined in the > >> interfaces model or elsewhere. I have a hard time to imagine an > >> interface that has zero counters. > >> > >> > > The mandatory-stmt is very confusing for config=3Dfalse nodes. Mandator= y=3Dtrue > > means > > an must contain an instance of the mandatory leaf. > > I don't think it is that confusing. RFC 7950 defines what a valid data > tree means and "mandatory" are among the constraints. > > I agree though that in terms of a management protocol it means different > things for config true and false data, but this is true also for default > values and maybe other YANG concepts as well. > > > > > Mandatory=3Dfalse does not mean optional-to-implement although it sure > > looks that way for config=3Dfalse nodes. Only if-feature can make a no= de > > optional to implement. > > I don't think this interpretation is supported by any text in the YANG > spec. State data nodes that are optional needn't be implemented. > > > RFC 7950, sec 5.6 (Conformance) does not support your interpretation. > It defines basic behavior, optional (via features), and deviations as the= only mechanisms affecting conformance. > > > Lada > > > > > > Andy > > > > > > > /js > > > > > > Andy > > > > -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_etPan594136925bf1d2351987localhost_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Franchesco,

To your point 1:
I was describing a very common use case when a client owns/ controls OTN TT= Ps, while the multi domain network provides connectivity betweeb access lin= ks across the network. In this cae network only deals with transit segments= (neither head nor tail)
To your point 2
There is only one thing aboutb OTN transit segments that is  OTN speci= fic  - bandwidth.
Because the configuration  of a transit OTN segment needs to include t= he exact ODUk container (to match the container on the opposite side of the= incoming access/interdomain link) - said ODUk container is expected to be = encoded as a generic label subobject that follows  the network side access/interdomain link subobject = ; - this alone tells the network controller everything it needs to know abo= ut the required bandwidth.
In short, for this use case you dont need OTN augmentation
to support client -network interface  - base /generic  TE tunnel = model works just fine,

I do agree that every use case that requires provisioning by network OTN&nb= sp; TTPs does require the OTN augmentation.

Igor

From:Ladislav Lhotka
To:Alex Campbell,
Cc:netmod@ietf.org,
Date:2017-06-14 04:28:51
Subject:Re: [netmod] Question on= intefaces-state model


> On 14 Jun 2017, at 00:35, Alex Campbell <Alex.Campbell@Aviatnet.com= > wrote:
>
>
> Presumably a device is free to not implement an optional config=3Dfals= e node if that node would never be returned in a response anyway - as this = will make no externally visible difference.

That's my view, too. However, this reasoning works if the parent container = is being retrieved but it is not very clear what is supposed to happen if t= he client asks explicly for that optional parameter. This looks like a gap = in the architecture =96 most of the time, YANG pretends to be something like a schema language in that it desc= ribes constraints on a valid data tree but conformance issues like what par= ameters a server needs to implement are something different.

>
> However, if the model states or implies that the node is present under= certain conditions (for example, the node is always present for Ethernet p= orts), and the device can meet those conditions (i.e. it has an Ethernet po= rt), then the device must implement the node or it does not conform to the model.

Right, this could be written in a description, but I've been assuming it is= not the case.

Lada

>
>
>
> Alex
>
> From: netmod <netmod-bounces@ietf.org> on behalf of Andy Bierman= <andy@yumaworks.com>
> Sent: Wednesday, 14 June 2017 7:30 a.m.
> To: Ladislav Lhotka
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Question on intefaces-state model
>
>
> On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka <lhotka@nic.cz>= ; wrote:
> Andy Bierman <andy@yumaworks.com> writes:
>
> > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> >> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (= Nokia -
> >> BE/Antwerp) wrote:
> >> >
> >> > We have a question regarding the statistics container as= defined in the
> >> > interfaces-state model.  This container defines one= mandatory leaf
> >> > (discontinuity-time) while all other leafs are optional.=   What is the
> >> > rationale behind this leaf being mandatory and not an op= tional field?
> >> >
> >> > It does not make a lot of sense to return a discontinuit= y-time value and
> >> no
> >> > counters if none of the counters are relevant for a spec= ific interface.
> >> >
> >> > Another alternative could be to add, via a deviation, a = when clause to
> >> the
> >> > container indicating for which ifType(s) the container i= s (or is not)
> >> > present. But that would lead to not supporting the IETF = interfaces model
> >> to
> >> > the full extent.
> >> >
> >>
> >> The discontinuity-time is relevant for _any_ counter associat= ed with
> >> an interface, regardless whether the counter is defined in th= e
> >> interfaces model or elsewhere. I have a hard time to imagine = an
> >> interface that has zero counters.
> >>
> >>
> > The mandatory-stmt is very confusing for config=3Dfalse nodes. Ma= ndatory=3Dtrue
> > means
> > an <rpc-reply> must contain an instance of the mandatory le= af.
>
> I don't think it is that confusing. RFC 7950 defines what a valid data=
> tree means and "mandatory" are among the constraints.
>
> I agree though that in terms of a management protocol it means differe= nt
> things for config true and false data, but this is true also for defau= lt
> values and maybe other YANG concepts as well.
>
> >
> > Mandatory=3Dfalse does not mean optional-to-implement although it= sure
> > looks that way for config=3Dfalse nodes.  Only if-feature ca= n make a node
> > optional to implement.
>
> I don't think this interpretation is supported by any text in the YANG=
> spec. State data nodes that are optional needn't be implemented.
>
>
> RFC 7950, sec 5.6  (Conformance) does not support your interpreta= tion.
> It defines basic behavior, optional (via features), and deviations as = the only mechanisms affecting conformance.
>
>
> Lada
>
> >
>
>
> Andy
> 
> >
> >
> >  /js
> >
> >
> > Andy
> >
> > --
> >> Juergen Schoenwaelder      &nbs= p;    Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587     &nbs= p;   Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103    =      <h= ttp://www.jacobs-university.de/>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> http= s://www.ietf.org/mailman/listinfo/netmod
> >>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://= www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67





_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netmod
 --_000_etPan594136925bf1d2351987localhost_-- From nobody Wed Jun 14 06:22:07 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A07A1294FF; Wed, 14 Jun 2017 06:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 89q0mHTiMpCj; Wed, 14 Jun 2017 06:22:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 075CF126FDC; Wed, 14 Jun 2017 06:22:04 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id 16CF060899; Wed, 14 Jun 2017 15:22:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1497446522; bh=rh+rAoTT3IeD7fIcvSsL1yV4RUPibHvN0tpKNMMt7Jw=; h=From:Date:To; b=ZXxTiNtvETPj/3Oum76AvHCV9J34wMmunxJDAc2Eey8qpcJV8N1WB/Uwui05hxY7k /s14lh01dymlmu+GhW4ub14s+VVzzl54LR7dmsSAlCMRiwjo+oMx9jPvepTU3tEyM9 ykLlFb3ecI5eig1537mpElkCzZijFgxwIJ2jEWtg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 14 Jun 2017 15:22:01 +0200 Cc: Xufeng Liu , draft-ietf-netmod-schema-mount@ietf.org, netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <01b901d2e483$792089f0$6b619dd0$@gmail.com> To: Lou Berger X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Schema-mount question: Augmentation to the Mounted Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:22:06 -0000 > On 14 Jun 2017, at 13:43, Lou Berger wrote: >=20 > Hi, >=20 > (speaking as contributor...) >=20 >=20 > On 6/14/2017 7:17 AM, Ladislav Lhotka wrote: >> Hi Xufeng, >>=20 >> please see my answers inline. >>=20 >> Xufeng Liu writes: >>=20 >>> Hi Lada, >>>=20 >>>=20 >>>=20 >>> We have got two questions on how to specify the module entries in a = schema: >>>=20 >>>=20 >>>=20 >>> 1. Are augmentations of parent modules inherited when augmented = module >>> is listed in schema-mounts schema? >>>=20 >>> For example, ietf-ospf module augments ietf-routing. When we include >>> ietf-routing to the schema entry, is ietf-ospf automatically = included? >> No, you also have to include "ietf-ospf" in the "module" list inside = the >> corresponding "schema" entry, exactly as you do in the top level YANG >> library, otherwise ietf-ospf won't be mounted. >=20 > I agree. The draft should have text that makes this explicit. Why? It should be sufficiently clear that modules that are not listed in = "schema" are not present in the mounted schema. An augment is just a = special mechanism of contributing schema nodes.=20 >=20 >>>=20 >>>=20 >>> 2. When we have ietf-yang-library mounted under a parent (LNE), = does >>> ietf-yang-library have to contain exactly the same list of Yang = modules as >>> the list contained in the "schema" entry under "schema-mount"? >> I am not sure I understand but do you mean an LNE mounted schema = defined via >> the "use-schema" case that also includes ietf-yang-library? This is a >> corner case we probably haven't thought about but it IMO doesn't make >> any sense to do so because the applicable YANG library that counts is >> inside the "schema" entry. Martin, should we address this anomaly? >=20 > I think this is a very real scenario for LNE. Consider a 'host' = system > that allows read only views of the LNE and wants the benefit of > "use-schema". In this case, library under the mount point is still > needed for client access within the mounted LNE. In this case it would IMO be much better if the server inside the LNE = provide YANG library data separately for its clients. The client of the = host system needn't see it because it is just redundant. > =20 >=20 > It seems to me that in this case the mounted library module data must > exactly match what is listed in the corresponding "schema" entry under > "schema-mount" in order to ensure deterministic client views/behavior.=20= > Again, I think this should be made explicit in the draft. Another option is to ban ietf-yang-library in schemas mounted via = "use-schema". I still think it is wrong to tout "inline" and = "use-schema" as the same "schema mount" concept. If we clearly separated = the two concepts, "inline" would become an absolute no-brainer requiring = just a single YANG extension statement, and "use-schema" would also be = easier to explain with no confusing exceptions and qualifications. It's = just simple divide-and-conquer in terms of the spec, with no limitations = compared to the current options. Lada >=20 >> BTW, I think that normally LNE schema is supposed to be mounted using = the >> "inline" case, and then of course ietf-yang-library is required but >> there is no "schema" entry under "schema-mounts" to worry about. > Both inline and non-inline LNE usage is expected in real systems... >=20 > Lou >> Lada >>=20 >>> For example, ietf-ospf module augments ietf-routing. When we mount >>> ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in = the mount >>> module list? And also in ietf-yang-library? >>>=20 >>>=20 >>>=20 >>> It would be great if these can be clarified. >>>=20 >>>=20 >>>=20 >>> Thanks, >>>=20 >>> - Xufeng -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jun 14 06:23:58 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1206712E040 for ; Wed, 14 Jun 2017 06:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOfnG6LYrslm for ; Wed, 14 Jun 2017 06:23:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD4F12EC18 for ; Wed, 14 Jun 2017 06:23:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIM71792; Wed, 14 Jun 2017 13:23:47 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 14 Jun 2017 14:23:45 +0100 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.136]) with mapi id 14.03.0301.000; Wed, 14 Jun 2017 06:23:33 -0700 From: Igor Bryskin To: Igor Bryskin , "lhotka@nic.cz" , "Alex.Campbell@Aviatnet.com" CC: "netmod@ietf.org" Thread-Topic: [netmod] Question on intefaces-state model Thread-Index: AdLhDRC34rNQajuWS5+4b+qYQggHyQCzfdcAAAJubIAAMwoVAAABUkEA//+9NFCAARwNgP//2mB0///914A= Date: Wed, 14 Jun 2017 13:23:32 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD0078639099D9296@SJCEML703-CHM.china.huawei.com> References: <20170612172141.GA52797@elstar.local> <1497393323725.99784@Aviatnet.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.222] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD0078639099D9296SJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.594138E3.00BB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8ae6017e67490886fe58a77c00eba5fa Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:23:57 -0000 --_000_0C72C38E7EBC34499E8A9E7DD0078639099D9296SJCEML703CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I apologize for the email below - replied to the wrong one, please, disrega= rd. Igor From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Wednesday, June 14, 2017 9:13 AM To: lhotka@nic.cz; Alex.Campbell@Aviatnet.com Cc: netmod@ietf.org Subject: Re: [netmod] Question on intefaces-state model Hi Franchesco, To your point 1: I was describing a very common use case when a client owns/ controls OTN TT= Ps, while the multi domain network provides connectivity betweeb access lin= ks across the network. In this cae network only deals with transit segments= (neither head nor tail) To your point 2 There is only one thing aboutb OTN transit segments that is OTN specific = - bandwidth. Because the configuration of a transit OTN segment needs to include the ex= act ODUk container (to match the container on the opposite side of the inco= ming access/interdomain link) - said ODUk container is expected to be encod= ed as a generic label subobject that follows the network side access/inter= domain link subobject - this alone tells the network controller everything= it needs to know about the required bandwidth. In short, for this use case you dont need OTN augmentation to support client -network interface - base /generic TE tunnel model work= s just fine, I do agree that every use case that requires provisioning by network OTN T= TPs does require the OTN augmentation. Igor From:Ladislav Lhotka To:Alex Campbell, Cc:netmod@ietf.org, Date:2017-06-14 04:28:51 Subject:Re: [netmod] Question on intefaces-state model > On 14 Jun 2017, at 00:35, Alex Campbell wrot= e: > > > Presumably a device is free to not implement an optional config=3Dfalse n= ode if that node would never be returned in a response anyway - as this wil= l make no externally visible difference. That's my view, too. However, this reasoning works if the parent container = is being retrieved but it is not very clear what is supposed to happen if t= he client asks explicly for that optional parameter. This looks like a gap = in the architecture - most of the time, YANG pretends to be something like = a schema language in that it describes constraints on a valid data tree but= conformance issues like what parameters a server needs to implement are so= mething different. > > However, if the model states or implies that the node is present under ce= rtain conditions (for example, the node is always present for Ethernet port= s), and the device can meet those conditions (i.e. it has an Ethernet port)= , then the device must implement the node or it does not conform to the mod= el. Right, this could be written in a description, but I've been assuming it is= not the case. Lada > > > > Alex > > From: netmod on behalf of Andy Bierman > Sent: Wednesday, 14 June 2017 7:30 a.m. > To: Ladislav Lhotka > Cc: netmod@ietf.org > Subject: Re: [netmod] Question on intefaces-state model > > > On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > >> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (Nokia - > >> BE/Antwerp) wrote: > >> > > >> > We have a question regarding the statistics container as defined in = the > >> > interfaces-state model. This container defines one mandatory leaf > >> > (discontinuity-time) while all other leafs are optional. What is th= e > >> > rationale behind this leaf being mandatory and not an optional field= ? > >> > > >> > It does not make a lot of sense to return a discontinuity-time value= and > >> no > >> > counters if none of the counters are relevant for a specific interfa= ce. > >> > > >> > Another alternative could be to add, via a deviation, a when clause = to > >> the > >> > container indicating for which ifType(s) the container is (or is not= ) > >> > present. But that would lead to not supporting the IETF interfaces m= odel > >> to > >> > the full extent. > >> > > >> > >> The discontinuity-time is relevant for _any_ counter associated with > >> an interface, regardless whether the counter is defined in the > >> interfaces model or elsewhere. I have a hard time to imagine an > >> interface that has zero counters. > >> > >> > > The mandatory-stmt is very confusing for config=3Dfalse nodes. Mandator= y=3Dtrue > > means > > an must contain an instance of the mandatory leaf. > > I don't think it is that confusing. RFC 7950 defines what a valid data > tree means and "mandatory" are among the constraints. > > I agree though that in terms of a management protocol it means different > things for config true and false data, but this is true also for default > values and maybe other YANG concepts as well. > > > > > Mandatory=3Dfalse does not mean optional-to-implement although it sure > > looks that way for config=3Dfalse nodes. Only if-feature can make a no= de > > optional to implement. > > I don't think this interpretation is supported by any text in the YANG > spec. State data nodes that are optional needn't be implemented. > > > RFC 7950, sec 5.6 (Conformance) does not support your interpretation. > It defines basic behavior, optional (via features), and deviations as the= only mechanisms affecting conformance. > > > Lada > > > > > > Andy > > > > > > > /js > > > > > > Andy > > > > -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_0C72C38E7EBC34499E8A9E7DD0078639099D9296SJCEML703CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I apologize for the email= below – replied to the wrong one, please, disregard.

 <= /p>

Igor

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Wednesday, June 14, 2017 9:13 AM
To: lhotka@nic.cz; Alex.Campbell@Aviatnet.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Question on intefaces-state model

 

Hi Franchesco,

To your point 1:
I was describing a very common use case when a client owns/ controls OTN TT= Ps, while the multi domain network provides connectivity betweeb access lin= ks across the network. In this cae network only deals with transit segments= (neither head nor tail)
To your point 2
There is only one thing aboutb OTN transit segments that is  OTN speci= fic  - bandwidth.
Because the configuration  of a transit OTN segment needs to include t= he exact ODUk container (to match the container on the opposite side of the= incoming access/interdomain link) - said ODUk container is expected to be = encoded as a generic label subobject that follows  the network side access/interdomain link subobject = ; - this alone tells the network controller everything it needs to know abo= ut the required bandwidth.
In short, for this use case you dont need OTN augmentation
to support client -network interface  - base /generic  TE tunnel = model works just fine,

I do agree that every use case that requires provisioning by network OTN&nb= sp; TTPs does require the OTN augmentation.

Igor

From:Ladislav Lhotka

To:Alex Campbell,

Cc:netmod@ietf.org,

Date:2017-06-14 04:28:51

Subject:Re: [netmod] Question on intefaces-state model

 


> On 14 Jun 2017, at 00:35, Alex Campbell <Alex.Campbell@Aviatnet.com= > wrote:
>
>
> Presumably a device is free to not implement an optional config=3Dfals= e node if that node would never be returned in a response anyway - as this = will make no externally visible difference.

That's my view, too. However, this reasoning works if the parent container = is being retrieved but it is not very clear what is supposed to happen if t= he client asks explicly for that optional parameter. This looks like a gap = in the architecture – most of the time, YANG pretends to be something like a schema language in that it desc= ribes constraints on a valid data tree but conformance issues like what par= ameters a server needs to implement are something different.

>
> However, if the model states or implies that the node is present under= certain conditions (for example, the node is always present for Ethernet p= orts), and the device can meet those conditions (i.e. it has an Ethernet po= rt), then the device must implement the node or it does not conform to the model.

Right, this could be written in a description, but I've been assuming it is= not the case.

Lada

>
>
>
> Alex
>
> From: netmod <netmod-bounces@ietf.org> on behalf of Andy Bierman= <andy@yumaworks.com>
> Sent: Wednesday, 14 June 2017 7:30 a.m.
> To: Ladislav Lhotka
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Question on intefaces-state model
>
>
> On Tue, Jun 13, 2017 at 11:52 AM, Ladislav Lhotka <lhotka@nic.cz>= ; wrote:
> Andy Bierman <andy@yumaworks.com> writes:
>
> > On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> >> On Fri, Jun 09, 2017 at 10:55:20AM +0000, Bogaert, Bart (= Nokia -
> >> BE/Antwerp) wrote:
> >> >
> >> > We have a question regarding the statistics container as= defined in the
> >> > interfaces-state model.  This container defines one= mandatory leaf
> >> > (discontinuity-time) while all other leafs are optional.=   What is the
> >> > rationale behind this leaf being mandatory and not an op= tional field?
> >> >
> >> > It does not make a lot of sense to return a discontinuit= y-time value and
> >> no
> >> > counters if none of the counters are relevant for a spec= ific interface.
> >> >
> >> > Another alternative could be to add, via a deviation, a = when clause to
> >> the
> >> > container indicating for which ifType(s) the container i= s (or is not)
> >> > present. But that would lead to not supporting the IETF = interfaces model
> >> to
> >> > the full extent.
> >> >
> >>
> >> The discontinuity-time is relevant for _any_ counter associat= ed with
> >> an interface, regardless whether the counter is defined in th= e
> >> interfaces model or elsewhere. I have a hard time to imagine = an
> >> interface that has zero counters.
> >>
> >>
> > The mandatory-stmt is very confusing for config=3Dfalse nodes. Ma= ndatory=3Dtrue
> > means
> > an <rpc-reply> must contain an instance of the mandatory le= af.
>
> I don't think it is that confusing. RFC 7950 defines what a valid data=
> tree means and "mandatory" are among the constraints.
>
> I agree though that in terms of a management protocol it means differe= nt
> things for config true and false data, but this is true also for defau= lt
> values and maybe other YANG concepts as well.
>
> >
> > Mandatory=3Dfalse does not mean optional-to-implement although it= sure
> > looks that way for config=3Dfalse nodes.  Only if-feature ca= n make a node
> > optional to implement.
>
> I don't think this interpretation is supported by any text in the YANG=
> spec. State data nodes that are optional needn't be implemented.
>
>
> RFC 7950, sec 5.6  (Conformance) does not support your interpreta= tion.
> It defines basic behavior, optional (via features), and deviations as = the only mechanisms affecting conformance.
>
>
> Lada
>
> >
>
>
> Andy
> 
> >
> >
> >  /js
> >
> >
> > Andy
> >
> > --
> >> Juergen Schoenwaelder      &nbs= p;    Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587     &nbs= p;   Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103    =      <h= ttp://www.jacobs-university.de/>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> http= s://www.ietf.org/mailman/listinfo/netmod
> >>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://= www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67





_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netmod

--_000_0C72C38E7EBC34499E8A9E7DD0078639099D9296SJCEML703CHMchi_-- From nobody Wed Jun 14 06:47:15 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B83C12E04B for ; Wed, 14 Jun 2017 06:47:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 pB-js8mP45zS for ; Wed, 14 Jun 2017 06:47:11 -0700 (PDT) Received: from gproxy4.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 0B7A212EA7F for ; Wed, 14 Jun 2017 06:47:09 -0700 (PDT) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 95A9A175EA1 for ; Wed, 14 Jun 2017 07:47:08 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id Ydn41v01D2SSUrH01dn7k0; Wed, 14 Jun 2017 07:47:08 -0600 X-Authority-Analysis: v=2.2 cv=QdwWhoTv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=wU2YTnxGAAAA:8 a=pGLkceISAAAA:8 a=1zAXGk6y_wnAwvbvmP0A:9 a=lxL-gWMC4343zF5V:21 a=Olu-WH5Bze89Xz-7:21 a=QEXdDO2ut3YA:10 a=v2312BZ5C20A:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=6kGIvZw6iX1k4Y-7sg4_:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=mcc5PbTkLbcHpL7srFe4TGRuTefa+7JyPGSwwKzfxSg=; b=AB6uUu8m3iMUsX9kFqMTKXeJDl ftGIcNGj1QVe19RTXSi78bplSpnoAQDK4a0frNSuO4nuWCc6Cr9P5nNwWxFwXLXgXsJQ+U2j2i/Fm 5rhLOo1JhsJ8iPPkDYhJ6khzn; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:53570 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dL8dU-0004oz-RK; Wed, 14 Jun 2017 07:47:04 -0600 To: Ladislav Lhotka Cc: Xufeng Liu , draft-ietf-netmod-schema-mount@ietf.org, netmod@ietf.org References: <01b901d2e483$792089f0$6b619dd0$@gmail.com> From: Lou Berger Message-ID: <0bd02d7b-d762-fd9c-d6e8-7e7acb2d475d@labn.net> Date: Wed, 14 Jun 2017 09:47:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dL8dU-0004oz-RK X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:53570 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] Schema-mount question: Augmentation to the Mounted Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:47:12 -0000 Hi Lada, On 6/14/2017 9:22 AM, Ladislav Lhotka wrote: >> On 14 Jun 2017, at 13:43, Lou Berger wrote: >> >> Hi, >> >> (speaking as contributor...) >> >> >> On 6/14/2017 7:17 AM, Ladislav Lhotka wrote: >>> Hi Xufeng, >>> >>> please see my answers inline. >>> >>> Xufeng Liu writes: >>> >>>> Hi Lada, >>>> >>>> >>>> >>>> We have got two questions on how to specify the module entries in a schema: >>>> >>>> >>>> >>>> 1. Are augmentations of parent modules inherited when augmented module >>>> is listed in schema-mounts schema? >>>> >>>> For example, ietf-ospf module augments ietf-routing. When we include >>>> ietf-routing to the schema entry, is ietf-ospf automatically included? >>> No, you also have to include "ietf-ospf" in the "module" list inside the >>> corresponding "schema" entry, exactly as you do in the top level YANG >>> library, otherwise ietf-ospf won't be mounted. >> I agree. The draft should have text that makes this explicit. > Why? It should be sufficiently clear that modules that are not listed in "schema" are not present in the mounted schema. An augment is just a special mechanism of contributing schema nodes. Because it it ambiguous to one (very clueful) reader, it won't be clear to others (who may or may not be clueful)... > >>>> >>>> 2. When we have ietf-yang-library mounted under a parent (LNE), does >>>> ietf-yang-library have to contain exactly the same list of Yang modules as >>>> the list contained in the "schema" entry under "schema-mount"? >>> I am not sure I understand but do you mean an LNE mounted schema defined via >>> the "use-schema" case that also includes ietf-yang-library? This is a >>> corner case we probably haven't thought about but it IMO doesn't make >>> any sense to do so because the applicable YANG library that counts is >>> inside the "schema" entry. Martin, should we address this anomaly? >> I think this is a very real scenario for LNE. Consider a 'host' system >> that allows read only views of the LNE and wants the benefit of >> "use-schema". In this case, library under the mount point is still >> needed for client access within the mounted LNE. > In this case it would IMO be much better if the server inside the LNE provide YANG library data separately for its clients. The client of the host system needn't see it because it is just redundant. huh? The intent was for the same information to be available from both in this use case. All that is needed is a one or two sentences to cover this case. Do you want me to propose text? (Yes, we could do this in the LNE document, but these seems like a generic, not model-specific topic.) >> >> >> It seems to me that in this case the mounted library module data must >> exactly match what is listed in the corresponding "schema" entry under >> "schema-mount" in order to ensure deterministic client views/behavior. >> Again, I think this should be made explicit in the draft. > Another option is to ban ietf-yang-library in schemas mounted via "use-schema". I still think it is wrong to tout "inline" and "use-schema" as the same "schema mount" concept. If we clearly separated the two concepts, "inline" would become an absolute no-brainer requiring just a single YANG extension statement, and "use-schema" would also be easier to explain with no confusing exceptions and qualifications. It's just simple divide-and-conquer in terms of the spec, with no limitations compared to the current options. I don't see how this helps. The scenario being discussed doesn't have anything to do with inline case. This is the case of the LNE which can support the exposure of the same information (data) via multiple YANG servers. One (the hosts) that sees all information and the other that sees information from the (jailed) mount point. Lou > > Lada > >>> BTW, I think that normally LNE schema is supposed to be mounted using the >>> "inline" case, and then of course ietf-yang-library is required but >>> there is no "schema" entry under "schema-mounts" to worry about. >> Both inline and non-inline LNE usage is expected in real systems... >> >> Lou >>> Lada >>> >>>> For example, ietf-ospf module augments ietf-routing. When we mount >>>> ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in the mount >>>> module list? And also in ietf-yang-library? >>>> >>>> >>>> >>>> It would be great if these can be clarified. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> - Xufeng > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > From nobody Wed Jun 14 07:37:01 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5981127868 for ; Wed, 14 Jun 2017 07:36:59 -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, 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 4z7TIWsnmN0k for ; Wed, 14 Jun 2017 07:36:57 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82CC126E01 for ; Wed, 14 Jun 2017 07:36:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 341FB1540613; Wed, 14 Jun 2017 16:36:54 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wkbRD8Am4tZl; Wed, 14 Jun 2017 16:36:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id EAA9B154061B; Wed, 14 Jun 2017 16:36:53 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VpKwBn_1ikMn; Wed, 14 Jun 2017 16:36:53 +0200 (CEST) Received: from [192.168.209.116] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 9C94F1540613; Wed, 14 Jun 2017 16:36:53 +0200 (CEST) To: "Bogaert, Bart (Nokia - BE/Antwerp)" , Juergen Schoenwaelder , Robert Wilton References: <20170612172141.GA52797@elstar.local> <65e1aa8e-c37b-d323-a351-c17fa4e96b3e@transpacket.com> <20170614093943.GA56060@elstar.local> Cc: Andy Bierman , "netmod@ietf.org" From: Vladimir Vassilev Message-ID: <57ca71ae-b397-589a-dd74-1ae0df1bb7c5@transpacket.com> Date: Wed, 14 Jun 2017 16:36:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Question on intefaces-state model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 14:37:00 -0000 Hello, On 06/14/2017 01:18 PM, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > That's why these counters are optional in the model: if there is nothing to > return we should indeed not return 0... > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 14 June 2017 11:40 > To: Robert Wilton > Cc: Vladimir Vassilev ; Andy Bierman > ; Bogaert, Bart (Nokia - BE/Antwerp) > ; netmod@ietf.org > Subject: Re: [netmod] Question on intefaces-state model > > On Wed, Jun 14, 2017 at 10:15:22AM +0100, Robert Wilton wrote: >> Returning zero values here is not useful, in fact it is misleading. I >> think that if a server doesn't have a value to return for a particular >> node it is much better to return nothing than to return a false value. > +1. > > It took us years to kill this attitude in SNMP land. Saying a counter is > zero and never changes is largely misleading if you actually have no such > counter. It is easy to waste hours of expensive engineering time by given > people fake counters. > > /js > I agree that the statistics counter leafs as defined in ietf-interfaces are optional except the discontinuity-time ("mandatory true;") leaf. You were right it makes the entire /interfaces-state/interface/statistics container mandatory even if none of the optional counters are implemented. The context of the example was the statement by Andy who seemed to differ on the counters being optional. I was not sure what he ment and added an example of device not implementing some of the counters without breaking conformity with ietf-interfaces: On 06/13/2017 11:15 AM, Vladimir Vassilev wrote: > On 06/12/2017 08:31 PM, Andy Bierman wrote: an must > contain an instance of the mandatory leaf. >> The mandatory-stmt is very confusing for config=false nodes. >> Mandatory=true means >> Mandatory=false does not mean optional-to-implement although it sure >> looks that way for config=false nodes. Only if-feature can make a >> node optional to implement. > If we take serial interface with hardware that only has in-octets and > out-octets counters I would expect to only find these two in > /interfaces-state/interface/statistics + discontinuity-time. Do you > say the rest of the counters must be present (e.g. allways 0) for > proper implementation of ietf-interfaces? That said you probably also agree that a model with optional leafs is equivalent to an employment contract where the monthly salary is optional. State data models should avoid the entropy of allowing implementations to either implement or not leafs without this being formal conformance deviation (this being especially valid for basic counters part of the base ietf model like ietf-interfaces). That causes greater waste of not only engineering time but runtime traffic as well. Management applications have to be designed to poll the leafs and make conditional decisions for each instance and handle missing leafs to conform to the model. For example an option to do automated validation of all point to point links in a topology (by checking counters at source and destination ports - out-unicast-pkts=in-unicast-pkts ... etc.). All the devices implement the required capability - ietf-interfaces but some do not return out-unicast-pkts, out-broadcast-pkts, out-multicast-pkts since the hardware only provides them with out-total-pkts and in-total-pkts (not part of ietf-interfaces model). With that example in mind I have another relevant question: Is there consensus that this is valid YANG 1.1 and with a mandatory counters defined like that the stated conformance actually brings some guarantees the required counter will be implemented: ... yang-version 1.1; ... augment "/if:interfaces-state/if:interface/if:statistics" { leaf in-total-pkts { mandatory true; type yang:counter64; } leaf out-total-pkts { mandatory true; type yang:counter64; } } ... pyang does not like that ("cannot augment with mandatory node in-total-pkts") and I think it should be valid to add mandatory true counter leafs to /interfaces-state/interface/statistics Vladimir From nobody Wed Jun 14 08:10:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE40B126CBF; Wed, 14 Jun 2017 08:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy6N-Zfw4eew; Wed, 14 Jun 2017 08:10:44 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4A012420B; Wed, 14 Jun 2017 08:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2725; q=dns/txt; s=iport; t=1497453044; x=1498662644; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=fLzm11HY377SQtJ+offTHN3LKyfgyTM2UNT3d/MxAyw=; b=WMr25Iocrsp3Rm2Mm4D+ujnF+Inf2ub/e6rMRIrS5v42PsaVmm6PtQz2 JWWbRzuOqEbdwEUGekV1VxnyyLHWcPXkfRzl5o5gHBsYTMZG+LWYfA/C4 q9WXM2pdwAilnJQ3FtZfEC9WaPU/+6JMPnHyg6X7yn5xvA+wWw3RLEo6j w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAACoUUFZ/xbLJq1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ6gQ2ODnORA5YGghEohXwCgw4YAQIBAQEBAQEBayiFGAEBAQE?= =?us-ascii?q?CAThBDAICCxABBAEBAScHGysJCAYBDAYCAQGKIAiwV4s/AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHQWGXYFgK4J2hQsmhSwBBJ5Hk1KLFoZzjDmIQR84gQowIQgbFYd?= =?us-ascii?q?XPzaJewEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,340,1493683200"; d="scan'208";a="653599217" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 15:10:33 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5EFAWOG007025; Wed, 14 Jun 2017 15:10:32 GMT To: Xufeng Liu , Juergen Schoenwaelder References: <20170613200928.GA55527@elstar.local> Cc: "draft-dsdt-nmda-guidelines@ietf.org" , "netmod@ietf.org" From: Robert Wilton Message-ID: <2513fdd0-a8b3-b547-8c37-c736c575c4bc@cisco.com> Date: Wed, 14 Jun 2017 16:10:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:10:47 -0000 Hi Xufeng, On 14/06/2017 14:01, Xufeng Liu wrote: > Hi Juergen, > > Thanks for the confirmation. > As for the distinction between applied configuration and operational, I think that it has been determined to be useful in some use cases. We can create a separate leaf in such a case. Yes, I think that this is exactly the right approach. In the general case, a single leaf for applied configuration and the operational value is normally sufficient. But in some cases (e.g. where a value could be configured and/or negotiated via protocol) then it sometimes useful to both see the input into the protocol negotiation and also the resultant output value. Here, there is a choice to be made to decide whether the extra config false leaf represents the input value into the negotiation, or the output value. I think that the decision probably depends on the protocol semantics, but all things being equal, there is a benefit if the configured value and actual operational value end up being represented by the same leaf/path (since this in the case in the mainline case where extra config false leaves are not required). Thanks, Rob > > Regards, > - Xufeng > >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Tuesday, June 13, 2017 4:10 PM >> To: Xufeng Liu >> Cc: draft-dsdt-nmda-guidelines@ietf.org; netmod@ietf.org >> Subject: Re: Clarification Question on draft-dsdt-nmda-guidelines-01 >> >> Hi, >> >> the typical -state tree consists of config false nodes and hence it represents >> operational state. This is not a transitioning period question, this is how -state >> trees were designed. Note also that the applied configuration is part of the >> operational state in NMDA - for config true objects, there is no difference >> between the applied configuration value and the operationally used value - they >> are the same. >> >> /js >> >> On Tue, Jun 13, 2017 at 07:53:32PM +0000, Xufeng Liu wrote: >>> During discussing the adoption of this guidelines, a question came up w.r.t. the >> semantics of the non-NMDA "-state" module during the transitioning period: >>> What kind of state do the leaves in the "-state" module represent? The applied >> configuration or the actually used operational data? >>> Since only of the two types can be represented, what is the guideline to model >> the other type? >>> Thanks, >>> - Xufeng >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 > . > From nobody Wed Jun 14 08:24:00 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858D412EC2B; Wed, 14 Jun 2017 08:23:59 -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 NpGUPxxNITaZ; Wed, 14 Jun 2017 08:23:57 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0A112EB69; Wed, 14 Jun 2017 08:23:57 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id a70so1636109pge.3; Wed, 14 Jun 2017 08:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1RtjotP7TcplKypnkAIAbxtV0XLsVEblwbcalmEfr9I=; b=GwqRVsYiCgfLLgSggiI0DXkDp5YpyvWgzfQdZxfs52l1KSi+SGOOgkETlyJuna9uLZ ZofUZZLbg96k+RLc2r+Up5+w5fpI/+OtoC6vykCpkjJKSNGbYROzkvgsI6DeVhe/R9/1 qX3/paw7QLUuKrAJ5PL2TeZWf5QP+SKXKf9CQ5MR0juHHhMwPwSQAI6GD97GaBdaAXGu H6EEzJ6O4emS4r665WSFR14+V4vn922Y+pukrjGZE1MjsTePLsz4BPwWsWzLRSKH8Ov0 xBxDbePaqrGGn14rdrslzsGotqLvKgJWytNbmQp5JvSPx8sUhAbeBsu2puaOZO9cPCWK 51Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1RtjotP7TcplKypnkAIAbxtV0XLsVEblwbcalmEfr9I=; b=o3g/DTONDxI/rNCco//DUbhD92M3JOHDOd6U0Jk8hgphLOX8FIXRP7Q2sOJkvp3lpD 4ZGPzgXItZakhLfHRq2wYjhqJ3/tQ4fdidWm/lQpgqa2Bgx8jZ/sLiJZbtnMcN16TgVd Voj1rVQalmiSX8BnT5AEc/KRKPVGDOCfpDxB41AJwS/MFOEzDSy11rfitCi/7anKTHtj GDxsDZ232VL/GtjqvTwMbkWu5HcMrQYS4OXvsFvn0VWgCLa/mkc5DzcT5OPDKcOhJwEF EvRNOrGIARlk8irACT8S1MwQ+GF60lPpmBGNWqxOBdehdZKg92xXkdEfsaYF5Wj9GgID 0RRQ== X-Gm-Message-State: AKS2vOyyJuRPC4TI+OnbsafJHQhcPBOjJCxa3n36DkvXhMnlDuoyo81O LmQqy0rWf5dYFA== X-Received: by 10.99.66.135 with SMTP id p129mr577822pga.107.1497453837027; Wed, 14 Jun 2017 08:23:57 -0700 (PDT) Received: from sjc-mahesh-nitro7.cisco.com ([128.107.241.191]) by smtp.gmail.com with ESMTPSA id z4sm535773pgc.22.2017.06.14.08.23.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Jun 2017 08:23:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <2513fdd0-a8b3-b547-8c37-c736c575c4bc@cisco.com> Date: Wed, 14 Jun 2017 08:23:54 -0700 Cc: Xufeng Liu , Juergen Schoenwaelder , "netmod@ietf.org" , "draft-dsdt-nmda-guidelines@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0505FAA8-BB82-4BCB-B4A5-E8018260580D@gmail.com> References: <20170613200928.GA55527@elstar.local> <2513fdd0-a8b3-b547-8c37-c736c575c4bc@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:23:59 -0000 > On Jun 14, 2017, at 8:10 AM, Robert Wilton wrote: >=20 > Hi Xufeng, >=20 >=20 > On 14/06/2017 14:01, Xufeng Liu wrote: >> Hi Juergen, >>=20 >> Thanks for the confirmation. >> As for the distinction between applied configuration and operational, = I think that it has been determined to be useful in some use cases. We = can create a separate leaf in such a case. > Yes, I think that this is exactly the right approach. >=20 > In the general case, a single leaf for applied configuration and the = operational value is normally sufficient. >=20 > But in some cases (e.g. where a value could be configured and/or = negotiated via protocol) then it sometimes useful to both see the input = into the protocol negotiation and also the resultant output value. >=20 > Here, there is a choice to be made to decide whether the extra config = false leaf represents the input value into the negotiation, or the = output value. I think that the decision probably depends on the = protocol semantics, but all things being equal, there is a benefit if = the configured value and actual operational value end up being = represented by the same leaf/path (since this in the case in the = mainline case where extra config false leaves are not required). Another way to look at it is whether the input value is truly different = from the output value. For example, if the input value is = auto-negotiation, a boolean, but the output value is a speed of = 10/100/1000/10000, a uint32, then a separate leaf makes sense. >=20 > Thanks, > Rob >=20 >=20 >>=20 >> Regards, >> - Xufeng >>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Tuesday, June 13, 2017 4:10 PM >>> To: Xufeng Liu >>> Cc: draft-dsdt-nmda-guidelines@ietf.org; netmod@ietf.org >>> Subject: Re: Clarification Question on draft-dsdt-nmda-guidelines-01 >>>=20 >>> Hi, >>>=20 >>> the typical -state tree consists of config false nodes and hence it = represents >>> operational state. This is not a transitioning period question, this = is how -state >>> trees were designed. Note also that the applied configuration is = part of the >>> operational state in NMDA - for config true objects, there is no = difference >>> between the applied configuration value and the operationally used = value - they >>> are the same. >>>=20 >>> /js >>>=20 >>> On Tue, Jun 13, 2017 at 07:53:32PM +0000, Xufeng Liu wrote: >>>> During discussing the adoption of this guidelines, a question came = up w.r.t. the >>> semantics of the non-NMDA "-state" module during the transitioning = period: >>>> What kind of state do the leaves in the "-state" module represent? = The applied >>> configuration or the actually used operational data? >>>> Since only of the two types can be represented, what is the = guideline to model >>> the other type? >>>> Thanks, >>>> - Xufeng >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >> . >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Jun 14 08:54:11 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F3B12EB42; Wed, 14 Jun 2017 08:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWaLZwvZ2lbC; Wed, 14 Jun 2017 08:54:07 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38FB12EAEF; Wed, 14 Jun 2017 08:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3651; q=dns/txt; s=iport; t=1497455647; x=1498665247; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=OTPC41VHzdIl03C2d4f9PVUYpblZP4pAq7iPanOyKT4=; b=k74vZSh5S389olz9vvwaDNt25zen6BM76AE9HReNXvh2M4RrXlpQqfcV ntJW9+UZB9SEk46ntqGYQWhxd+7f8vBDe4u4BJ94WgGH+o5F5ESW5R5r3 9yImefud0x+Kcxey88T4lPiepXnsbpXrPP1SCgwN/D/TAMKYlKpm4vTUv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAAAWW0FZ/xbLJq1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ6gQ2ODnORA4grjVuCESELhS5KAoMOGAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEBATY2CwwCAgsOAgEEAQEBJwcbBgYfCQgGDQYCAQGKEAMNCBCwToc3D?= =?us-ascii?q?YN7AQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWGXYFgK4J2gliCMyaFLAWeDDuObIR?= =?us-ascii?q?mixaGc4tOa4hBHziBCjAhCBsVSIcPPzaJewEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,340,1493683200"; d="scan'208";a="653599919" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 15:54:04 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5EFs47M016270; Wed, 14 Jun 2017 15:54:04 GMT To: Mahesh Jethanandani References: <20170613200928.GA55527@elstar.local> <2513fdd0-a8b3-b547-8c37-c736c575c4bc@cisco.com> <0505FAA8-BB82-4BCB-B4A5-E8018260580D@gmail.com> Cc: Xufeng Liu , Juergen Schoenwaelder , "netmod@ietf.org" , "draft-dsdt-nmda-guidelines@ietf.org" From: Robert Wilton Message-ID: <5525cbb1-9ac7-bf24-67e1-68bb681be6ac@cisco.com> Date: Wed, 14 Jun 2017 16:54:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0505FAA8-BB82-4BCB-B4A5-E8018260580D@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:54:10 -0000 On 14/06/2017 16:23, Mahesh Jethanandani wrote: >> On Jun 14, 2017, at 8:10 AM, Robert Wilton wrote: >> >> Hi Xufeng, >> >> >> On 14/06/2017 14:01, Xufeng Liu wrote: >>> Hi Juergen, >>> >>> Thanks for the confirmation. >>> As for the distinction between applied configuration and operational, I think that it has been determined to be useful in some use cases. We can create a separate leaf in such a case. >> Yes, I think that this is exactly the right approach. >> >> In the general case, a single leaf for applied configuration and the operational value is normally sufficient. >> >> But in some cases (e.g. where a value could be configured and/or negotiated via protocol) then it sometimes useful to both see the input into the protocol negotiation and also the resultant output value. >> >> Here, there is a choice to be made to decide whether the extra config false leaf represents the input value into the negotiation, or the output value. I think that the decision probably depends on the protocol semantics, but all things being equal, there is a benefit if the configured value and actual operational value end up being represented by the same leaf/path (since this in the case in the mainline case where extra config false leaves are not required). > Another way to look at it is whether the input value is truly different from the output value. For example, if the input value is auto-negotiation, a boolean, but the output value is a speed of 10/100/1000/10000, a uint32, then a separate leaf makes sense. Yes, agreed. For cases like these (e.g. Ethernet auto-negotiation) a good approach seem to be to model the leaf "enabling auto" as a separate leaf from the explicitly configured/operational value. Thanks, Rob > >> Thanks, >> Rob >> >> >>> Regards, >>> - Xufeng >>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Tuesday, June 13, 2017 4:10 PM >>>> To: Xufeng Liu >>>> Cc: draft-dsdt-nmda-guidelines@ietf.org; netmod@ietf.org >>>> Subject: Re: Clarification Question on draft-dsdt-nmda-guidelines-01 >>>> >>>> Hi, >>>> >>>> the typical -state tree consists of config false nodes and hence it represents >>>> operational state. This is not a transitioning period question, this is how -state >>>> trees were designed. Note also that the applied configuration is part of the >>>> operational state in NMDA - for config true objects, there is no difference >>>> between the applied configuration value and the operationally used value - they >>>> are the same. >>>> >>>> /js >>>> >>>> On Tue, Jun 13, 2017 at 07:53:32PM +0000, Xufeng Liu wrote: >>>>> During discussing the adoption of this guidelines, a question came up w.r.t. the >>>> semantics of the non-NMDA "-state" module during the transitioning period: >>>>> What kind of state do the leaves in the "-state" module represent? The applied >>>> configuration or the actually used operational data? >>>>> Since only of the two types can be represented, what is the guideline to model >>>> the other type? >>>>> Thanks, >>>>> - Xufeng >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >>> . >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > Mahesh Jethanandani > mjethanandani@gmail.com > > > > . > From nobody Wed Jun 14 10:07:20 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A834B128D6F; Wed, 14 Jun 2017 10:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VcJqvCCbsRh; Wed, 14 Jun 2017 10:07:17 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DD12D127B60; Wed, 14 Jun 2017 10:07:16 -0700 (PDT) Received: from localhost (h-13-81.A165.priv.bahnhof.se [155.4.13.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 030FC1AE0335; Wed, 14 Jun 2017 19:07:15 +0200 (CEST) Date: Wed, 14 Jun 2017 19:07:14 +0200 (CEST) Message-Id: <20170614.190714.1094691660981968653.mbj@tail-f.com> To: lhotka@nic.cz Cc: lberger@labn.net, xufeng.liu.ietf@gmail.com, draft-ietf-netmod-schema-mount@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: 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: [netmod] Schema-mount question: Augmentation to the Mounted Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 17:07:19 -0000 Ladislav Lhotka wrote: > > > On 14 Jun 2017, at 13:43, Lou Berger wrote: > > > > Hi, > > > > (speaking as contributor...) > > > > > > On 6/14/2017 7:17 AM, Ladislav Lhotka wrote: > >> Hi Xufeng, > >> > >> please see my answers inline. > >> > >> Xufeng Liu writes: > >> > >>> Hi Lada, > >>> > >>> > >>> > >>> We have got two questions on how to specify the module entries in a > >>> schema: > >>> > >>> > >>> > >>> 1. Are augmentations of parent modules inherited when augmented module > >>> is listed in schema-mounts schema? > >>> > >>> For example, ietf-ospf module augments ietf-routing. When we include > >>> ietf-routing to the schema entry, is ietf-ospf automatically included? > >> No, you also have to include "ietf-ospf" in the "module" list inside > >> the > >> corresponding "schema" entry, exactly as you do in the top level YANG > >> library, otherwise ietf-ospf won't be mounted. > > > > I agree. The draft should have text that makes this explicit. > > Why? It should be sufficiently clear that modules that are not listed > in "schema" are not present in the mounted schema. An augment is just > a special mechanism of contributing schema nodes. Yes I agree. But let's see if we can clarify the text. Xufeng, what in the current text led you to believe that a module in the parent schema would be automatically present in the mounted schema? > >>> 2. When we have ietf-yang-library mounted under a parent (LNE), does > >>> ietf-yang-library have to contain exactly the same list of Yang > >>> modules as > >>> the list contained in the "schema" entry under "schema-mount"? > >> I am not sure I understand but do you mean an LNE mounted schema > >> defined via > >> the "use-schema" case that also includes ietf-yang-library? This is a > >> corner case we probably haven't thought about but it IMO doesn't make > >> any sense to do so because the applicable YANG library that counts is > >> inside the "schema" entry. Martin, should we address this anomaly? > > > > I think this is a very real scenario for LNE. Consider a 'host' > > system > > that allows read only views of the LNE and wants the benefit of > > "use-schema". In this case, library under the mount point is still > > needed for client access within the mounted LNE. > > In this case it would IMO be much better if the server inside the LNE > provide YANG library data separately for its clients. The client of > the host system needn't see it because it is just redundant. > > > > > > > It seems to me that in this case the mounted library module data must > > exactly match what is listed in the corresponding "schema" entry under > > "schema-mount" in order to ensure deterministic client views/behavior. > > Again, I think this should be made explicit in the draft. > > Another option is to ban ietf-yang-library in schemas mounted via > "use-schema". This won't help. The question is still the same - if you use "use-schema", and one of the mounted modules is "ietf-yang-library", does the contents of the yang library in both places have to be the same? Anyway, I think the answer is that from the current specification, it follows that the contents *will* be the same. /martin > I still think it is wrong to tout "inline" and > "use-schema" as the same "schema mount" concept. If we clearly > separated the two concepts, "inline" would become an absolute > no-brainer requiring just a single YANG extension statement, and > "use-schema" would also be easier to explain with no confusing > exceptions and qualifications. It's just simple divide-and-conquer in > terms of the spec, with no limitations compared to the current > options. > > Lada > > > > >> BTW, I think that normally LNE schema is supposed to be mounted using > >> the > >> "inline" case, and then of course ietf-yang-library is required but > >> there is no "schema" entry under "schema-mounts" to worry about. > > Both inline and non-inline LNE usage is expected in real systems... > > > > Lou > >> Lada > >> > >>> For example, ietf-ospf module augments ietf-routing. When we mount > >>> ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in the > >>> mount > >>> module list? And also in ietf-yang-library? > >>> > >>> > >>> > >>> It would be great if these can be clarified. > >>> > >>> > >>> > >>> Thanks, > >>> > >>> - Xufeng > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > From nobody Wed Jun 14 11:07:43 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83168128AB0 for ; Wed, 14 Jun 2017 11:07:40 -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, 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=yumaworks-com.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 x42449kWZ8rC for ; Wed, 14 Jun 2017 11:07:38 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598FD127866 for ; Wed, 14 Jun 2017 11:07:38 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id 36so11264706wry.3 for ; Wed, 14 Jun 2017 11:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0V6q6erfobjDqw9pJkVOUVnK/rLiE4W2PJhzb5rUes8=; b=YBsPxRdivIfBePnkBfi8TfLc1zmr8tSpSMBMI1afDfw67/tM8daUhq29gUbL0yW9xz gLl7MW+8GNQn444K0DOv3AjP4EU52PvGCPcowI0JoBp7MGVckhdsvOL/JL3npYVRImTp MqODnMpnsTQoyW4o4Z32JNJIMxSKVyoFrxqOQOVJSSN8rSxEiV8LdD2zHGAHAHtBSjug fHDBjG+gpMy8ujUoevwLOyNq25aoaYDgJpROKLZcgFgLjM8bs3KpxeQ6tCvQPNLlq2Qw VeVLKTrJ6Rl7Hmm2QewO5WiW4nUNxrJvhanifcoFuABhyONrAo2kyQlkoLkFr+upkUD8 aZYA== 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=0V6q6erfobjDqw9pJkVOUVnK/rLiE4W2PJhzb5rUes8=; b=QfJ8CtnP3a0siQFVXisITpMoY02dvtWwsWEoMKpnffmSa1FhH2FL8gfdoS62Tq+9Nk mxWgZQTIixKNrPQVJCXqpniyEYDbCfqGHUNzvxhZj5dgmJERvYVskvVlP9MxRmZ/Jb+O 7Bb+PNsXKaOoFTs/AASBcAvmdvbFRgzG0naEJh4objapA8fnXIcOXhopniJ8Cx9AbTci qlyJoDyGaWAqQvj7ErXkkBi917YEPUdNqnRvg8urYQwD8HgwfpUiH74qTCfTuOxoxwzr gO99+tjcH9PkukHFJvUWdulIWLuITotnfyixiJzyzJkqGkTKP2R7viYJ5zwB1s/odwzA XPxA== X-Gm-Message-State: AKS2vOyzuFh9vmLwJpiFqJ3GOfJOJJ2RUk3ZfgNUYHUiZ8rFpGC+uQA2 JjGe2Vi2Tv7LUrLtZsUCa1WLPk2CNse/KOE= X-Received: by 10.28.151.207 with SMTP id z198mr931187wmd.48.1497463656568; Wed, 14 Jun 2017 11:07:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.173 with HTTP; Wed, 14 Jun 2017 11:07:35 -0700 (PDT) From: Andy Bierman Date: Wed, 14 Jun 2017 11:07:35 -0700 Message-ID: To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a1144ea2a50780e0551ef6d3b" Archived-At: Subject: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 18:07:40 -0000 --001a1144ea2a50780e0551ef6d3b Content-Type: text/plain; charset="UTF-8" Hi, I don't know if getting rid of /foo-state is such a great idea, especially wrt/ counters and other objects that are not related to intended config vs. applied config. Q1) how does a client know the difference between an auto-generated foo-state.yang and a real foo-state.yang? Seem like a YANG extension is needed to flag an auto-generated foo-state.yang Q2) How does XPath reference an operational node if the /foo-state subtree has been moved to the /foo config subtree? module foo { container foo { leaf stat-collect-type { type enumeration { enum stat-set1; enum stat-set2; } } } container foo-state { config false; leaf stat-collect-type { type enumeration { enum stat-set1; enum stat-set2; } } container stat-set1 { when "../stat-collect-type = 'stat-set1'"; ... } container stat-set2 { when "../stat-collect-type = 'stat-set2'"; ... } } } In this example, there is a request stat collect type /foo/stat-collect-type and there is an operational value (what the server/device is capable of collecting -- e.g. client requests stat-set2 knowing the server will change it to stat-set1 if set2 not supported) So if /foo-state is folded into /foo (because that is the intent -- to get rid of this extra stat-collect-type leaf), then how do the when-stmts get applied to the operational value instead of the configured value? The same issue applies if the when-stmts are within an augment-stmt WANT: augment /foo-state { when "stat-collect-type = 'stat-set1'"; container stat-set1 { ... } } RD Provides: augment /foo { when "stat-collect-type = 'stat-set1'"; container stat-set1 { config false; ... } } There is no way to use when-stmt to reference the operational value. This is a rather common usage of the when-stmt, so it should not be removed if RD is used. Andy --001a1144ea2a50780e0551ef6d3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I don't know if getting rid of = /foo-state is such a great idea,
especially wrt/ counters and oth= er objects that are not
related to intended config vs. applied co= nfig.

Q1) how does a client know the difference be= tween an auto-generated
foo-state.yang and a real foo-state.yang?= =C2=A0 Seem like a YANG extension
is needed to flag an auto-gener= ated foo-state.yang

Q2) How does XPath reference a= n operational node if the /foo-state
subtree has been moved to th= e /foo config subtree?

module foo {
=
=C2=A0 =C2=A0 =C2=A0container foo {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 leaf stat-collect-type {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum stat-set1;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum stat-set2;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0container foo-state {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 config false;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 leaf stat-collect-type {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum stat-set1;
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum stat-set2;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0container stat-set1 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 when "../stat-collect-type =3D 'stat-set1'"= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0container stat-set2 {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when "../stat-collect-type =3D 'st= at-set2'";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0}
}

In this exampl= e, there is a request stat collect type /foo/stat-collect-type
an= d there is an operational value (what the server/device is capable
of collecting -- e.g. client requests stat-set2 knowing the server
<= div>will change it to stat-set1 if set2 not supported)

=
So if /foo-state is folded into /foo (because that is the intent -- to= get
rid of this extra stat-collect-type leaf), then how do the w= hen-stmts
get applied to the operational value instead of the con= figured value?
The same issue applies if the when-stmts are withi= n an augment-stmt

WANT:

<= div>=C2=A0augment /foo-state {
=C2=A0 =C2=A0 when "stat-coll= ect-type =3D 'stat-set1'";
=C2=A0 =C2=A0 container s= tat-set1 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0= }
=C2=A0}

RD Provides:
=
=C2=A0 augment /foo {
=C2=A0 =C2=A0 when "sta= t-collect-type =3D 'stat-set1'";
=C2=A0 =C2=A0 conta= iner stat-set1 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0config false;
=C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 }
=C2= =A0}

There is no way to use when-stmt to reference= the operational value.
This is a rather common usage of the when= -stmt, so it should not
be removed if RD is used.

<= /div>


Andy


<= /div>
--001a1144ea2a50780e0551ef6d3b-- From nobody Wed Jun 14 11:15:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D46129413; Wed, 14 Jun 2017 11:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v07XMspH5wXv; Wed, 14 Jun 2017 11:15:52 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 7EEDB1292FD; Wed, 14 Jun 2017 11:15:52 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id o83so6778701lff.3; Wed, 14 Jun 2017 11:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=MJcmGx47lMxiO0avLVl1EntABLsDvfmXDhzJvt02Vvc=; b=kugkl8rh0bWSr1XXoGTzQM4sRHNRflsvDUdXCZIvMqL7HxVs4qYY1Qbpgxzcp58G/f Y/xHreaSDniwyJFMpC0nszIMITvkZCZ3qGVvSqosGTBL5AmTuLjjhqDpY8Z7c1jPp56V v2FRgyveq41BqPr7lVmVUplZRdKIf5U4dO+sv6DGa/tHssQ4ycErSKZmKwc2tKjiDq/c w1INjFk43FxM6fNOve35Ku0NUzduS1EvZBC83RBoYMFeht6znBzt9Zv7E/lQ3nmaCQBA anhYCx8SAmOGGMww4qb2gYAC6bmrDgXfsgN5+kutwghnftWQmT6aQ8jhFST/lBLOp/PQ Tf3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=MJcmGx47lMxiO0avLVl1EntABLsDvfmXDhzJvt02Vvc=; b=t9maLdJR1LwHl/e5+gUiE3FO6vbbza1/cCZi+qYBFvxQadWzqLZ01FnULLOKWW6l0B 7q+kCp7bqI+ZUf0Ym7uEeNZQyQDTdl5ChfG/Otng1YTOZEKJ1m5PRag0yjfWb1r8bVDJ LWqPnuE4RXc2tpdTLBE4tfTNsrRgpNpxJIYtHa+r1a5fH0SqO6p/bq7aZ7VdWUKwnBxt sMqKmzcBcbrXqPeLyz5ginmCxaYlmYWbqCh77bnrGMQCdEVeba8O4+P1v07miWvDouOE B2fvS/3SB008TaRBYWfry/YHDkrMNZD82OjvkVcrvPZVy1LZGK5k2lWHff7rXoS/fcZb i6Sw== X-Gm-Message-State: AKS2vOzJ8fQBqvhEyx+GgCGj/gEUO2jntJPY7b6YVnH9WZ6jXZkWQb3K hHgEQiwGkEP4ZF76s8o= X-Received: by 10.25.167.19 with SMTP id q19mr466695lfe.138.1497464150419; Wed, 14 Jun 2017 11:15:50 -0700 (PDT) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id g13sm171168ljg.33.2017.06.14.11.15.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jun 2017 11:15:49 -0700 (PDT) From: "Xufeng Liu" To: "'Martin Bjorklund'" , Cc: , , References: <20170614.190714.1094691660981968653.mbj@tail-f.com> In-Reply-To: <20170614.190714.1094691660981968653.mbj@tail-f.com> Date: Wed, 14 Jun 2017 14:15:46 -0400 Message-ID: <025301d2e53a$40576960$c1063c20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIBaZOnae1JDJuoGLg5MaKPun0h7wI4bDntAVxxot4DPNYZCaGRDCMQ Content-Language: en-us x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTdhZTQ2MTExLTUxMmQtMTFlNy05YzE0LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFw3YWU0NjExMi01MTJkLTExZTctOWMxNC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjU3MjYiIHQ9IjEzMTQxOTM3NzQ2MTM4NjQ2MiIgaD0iMFQ2OVd5R0NjRXRFZE1VbWJ2aFoveXl2Um80PSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== Archived-At: Subject: Re: [netmod] Schema-mount question: Augmentation to the Mounted Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 18:15:55 -0000 Hi Martin, > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, June 14, 2017 1:07 PM > To: lhotka@nic.cz > Cc: lberger@labn.net; xufeng.liu.ietf@gmail.com; draft-ietf-netmod-schema- > mount@ietf.org; netmod@ietf.org > Subject: Re: [netmod] Schema-mount question: Augmentation to the Mounted > Module > > Ladislav Lhotka wrote: > > > > > On 14 Jun 2017, at 13:43, Lou Berger wrote: > > > > > > Hi, > > > > > > (speaking as contributor...) > > > > > > > > > On 6/14/2017 7:17 AM, Ladislav Lhotka wrote: > > >> Hi Xufeng, > > >> > > >> please see my answers inline. > > >> > > >> Xufeng Liu writes: > > >> > > >>> Hi Lada, > > >>> > > >>> > > >>> > > >>> We have got two questions on how to specify the module entries in > > >>> a > > >>> schema: > > >>> > > >>> > > >>> > > >>> 1. Are augmentations of parent modules inherited when augmented > > >>> module is listed in schema-mounts schema? > > >>> > > >>> For example, ietf-ospf module augments ietf-routing. When we > > >>> include ietf-routing to the schema entry, is ietf-ospf automatically > included? > > >> No, you also have to include "ietf-ospf" in the "module" list > > >> inside the corresponding "schema" entry, exactly as you do in the > > >> top level YANG library, otherwise ietf-ospf won't be mounted. > > > > > > I agree. The draft should have text that makes this explicit. > > > > Why? It should be sufficiently clear that modules that are not listed > > in "schema" are not present in the mounted schema. An augment is just > > a special mechanism of contributing schema nodes. > > Yes I agree. But let's see if we can clarify the text. Xufeng, what in the current > text led you to believe that a module in the parent schema would be > automatically present in the mounted schema? > [Xufeng] Thanks for looking at this. The confusion is because of the lack of text, I would say. The term "mount" has an analogy to the Unix file system "mount", where what we only specify the parent directory and child file system (the connecting relationship at the connection point). Also, similar is the command for the Unix soft/hard links, where we don't need to check if there are other links under the child. > > >>> 2. When we have ietf-yang-library mounted under a parent (LNE), does > > >>> ietf-yang-library have to contain exactly the same list of Yang > > >>> modules as the list contained in the "schema" entry under > > >>> "schema-mount"? > > >> I am not sure I understand but do you mean an LNE mounted schema > > >> defined via the "use-schema" case that also includes > > >> ietf-yang-library? This is a corner case we probably haven't > > >> thought about but it IMO doesn't make any sense to do so because > > >> the applicable YANG library that counts is inside the "schema" > > >> entry. Martin, should we address this anomaly? > > > > > > I think this is a very real scenario for LNE. Consider a 'host' > > > system > > > that allows read only views of the LNE and wants the benefit of > > > "use-schema". In this case, library under the mount point is still > > > needed for client access within the mounted LNE. > > > > In this case it would IMO be much better if the server inside the LNE > > provide YANG library data separately for its clients. The client of > > the host system needn't see it because it is just redundant. > > > > > > > > > > > It seems to me that in this case the mounted library module data > > > must exactly match what is listed in the corresponding "schema" > > > entry under "schema-mount" in order to ensure deterministic client > views/behavior. > > > Again, I think this should be made explicit in the draft. > > > > Another option is to ban ietf-yang-library in schemas mounted via > > "use-schema". > > This won't help. The question is still the same - if you use "use-schema", and > one of the mounted modules is "ietf-yang-library", does the contents of the > yang library in both places have to be the same? > > Anyway, I think the answer is that from the current specification, it follows that > the contents *will* be the same. > > > /martin > > > > > I still think it is wrong to tout "inline" and "use-schema" as the > > same "schema mount" concept. If we clearly separated the two concepts, > > "inline" would become an absolute no-brainer requiring just a single > > YANG extension statement, and "use-schema" would also be easier to > > explain with no confusing exceptions and qualifications. It's just > > simple divide-and-conquer in terms of the spec, with no limitations > > compared to the current options. > > > > Lada > > > > > > > >> BTW, I think that normally LNE schema is supposed to be mounted > > >> using the "inline" case, and then of course ietf-yang-library is > > >> required but there is no "schema" entry under "schema-mounts" to > > >> worry about. > > > Both inline and non-inline LNE usage is expected in real systems... > > > > > > Lou > > >> Lada > > >> > > >>> For example, ietf-ospf module augments ietf-routing. When we mount > > >>> ietf-routing ietf-yang-library to LNE, should we list ietf-ospf in > > >>> the mount module list? And also in ietf-yang-library? > > >>> > > >>> > > >>> > > >>> It would be great if these can be clarified. > > >>> > > >>> > > >>> > > >>> Thanks, > > >>> > > >>> - Xufeng > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > From nobody Thu Jun 15 04:59:37 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F82129BCE for ; Thu, 15 Jun 2017 04:59:35 -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, 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 I3FSPO5XF0SY for ; Thu, 15 Jun 2017 04:59:33 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE570129BC7 for ; Thu, 15 Jun 2017 04:59:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id B9F801540982; Thu, 15 Jun 2017 13:59:30 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 508L9_ZzeFwN; Thu, 15 Jun 2017 13:59:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 867DA1540984; Thu, 15 Jun 2017 13:59:30 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4766b7cBo8gb; Thu, 15 Jun 2017 13:59:30 +0200 (CEST) Received: from [192.168.209.116] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 603E41540982; Thu, 15 Jun 2017 13:59:30 +0200 (CEST) To: netmod@ietf.org, Robert Wilton References: <148943391240.20421.7015046968650807465@ietfa.amsl.com> From: Vladimir Vassilev Message-ID: Date: Thu, 15 Jun 2017 13:59:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <148943391240.20421.7015046968650807465@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 11:59:36 -0000 Hello, There is a problem with a mutually exclusive 'when' statements for the /interfaces/inteface/encapsulation container in ietf-interfaces-common@2017-03-13.yang (draft-ietf-netmod-intf-ext-yang-04) and ietf-if-l3-vlan@2017-03-13.yang models causing error with our validation tools. As defined in ietf-interfaces-common@2017-03-13.yang: ... container encapsulation { when "derived-from-or-self(../if:type, 'ianaift:ethernetCsmacd') or derived-from-or-self(../if:type, 'ianaift:ieee8023adLag') or derived-from-or-self(../if:type, 'ianaift:pos') or derived-from-or-self(../if:type, 'ianaift:atmSubInterface') or derived-from-or-self(../if:type, 'ethSubInterface')" { ... and here augmented in ietf-if-l3-vlan@2017-03-13.yang: augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + "if-cmn:encaps-type" { when "../if:type = 'ianaift:l2vlan' and derived-from-or-self(../if-cmn:forwarding-mode, 'if-cmn:network-layer')" { Short term fix I use is to add "or derived-from-or-self(../if:type, 'ianaift:l2vlan')" to the ietf-interfaces-common definition. Vladimir On 03/13/2017 08:38 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language of the IETF. > > Title : Sub-interface VLAN YANG Data Models > Authors : Robert Wilton > David Ball > Tapraj Singh > Selvakumar Sivaraj > Filename : draft-ietf-netmod-sub-intf-vlan-model-01.txt > Pages : 27 > Date : 2017-03-13 > > Abstract: > This document defines YANG modules to add support for classifying > traffic received on interfaces as Ethernet/VLAN framed packets to > sub-interfaces based on the fields available in the Ethernet/VLAN > frame headers. These modules allow configuration of Layer 3 and > Layer 2 sub-interfaces (e.g. attachment circuits) that can > interoperate with IETF based forwarding protocols; such as IP and > L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The > sub-interfaces also interoperate with VLAN tagged traffic orginating > from an IEEE 802.1Q compliant bridge. Primarily the classification > is based on VLAN identifiers in the 802.1Q VLAN tags, but the model > also has support for matching on some other layer 2 frame header > fields and is designed to be extensible to match on other arbitrary > header fields. > > The model differs from an IEEE 802.1Q bridge model in that the > configuration is interface/sub-interface based as opposed to being > based on membership of an 802.1Q VLAN bridge. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-sub-intf-vlan-model-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jun 15 05:27:22 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C857129BF5 for ; Thu, 15 Jun 2017 05:27:21 -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, RP_MATCHES_RCVD=-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 3H2pETGBRmgc for ; Thu, 15 Jun 2017 05:27:19 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3F1129BCF for ; Thu, 15 Jun 2017 05:27:18 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AE982F4B; Thu, 15 Jun 2017 14:27:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 72bGVdMjPU-u; Thu, 15 Jun 2017 14:27:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 15 Jun 2017 14:27:17 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E0B620091; Thu, 15 Jun 2017 14:27:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rXdV5mLTCkgM; Thu, 15 Jun 2017 14:27:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C3E720090; Thu, 15 Jun 2017 14:27:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E947F3FC2F6F; Thu, 15 Jun 2017 14:27:16 +0200 (CEST) Date: Thu, 15 Jun 2017 14:27:16 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: "netmod@ietf.org" Message-ID: <20170615122716.GB58434@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 12:27:21 -0000 Andy, section 5.1 of draft-ietf-netmod-revised-datastores-02.txt discusses the XPath context. An xpath expression in a config-false container will resolve to the operational state. /js On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote: > Hi, > > I don't know if getting rid of /foo-state is such a great idea, > especially wrt/ counters and other objects that are not > related to intended config vs. applied config. > > Q1) how does a client know the difference between an auto-generated > foo-state.yang and a real foo-state.yang? Seem like a YANG extension > is needed to flag an auto-generated foo-state.yang > > Q2) How does XPath reference an operational node if the /foo-state > subtree has been moved to the /foo config subtree? > > module foo { > > container foo { > leaf stat-collect-type { > type enumeration { > enum stat-set1; > enum stat-set2; > } > } > } > > container foo-state { > config false; > leaf stat-collect-type { > type enumeration { > enum stat-set1; > enum stat-set2; > } > } > container stat-set1 { > when "../stat-collect-type = 'stat-set1'"; > ... > } > container stat-set2 { > when "../stat-collect-type = 'stat-set2'"; > ... > } > } > } > > In this example, there is a request stat collect type /foo/stat-collect-type > and there is an operational value (what the server/device is capable > of collecting -- e.g. client requests stat-set2 knowing the server > will change it to stat-set1 if set2 not supported) > > So if /foo-state is folded into /foo (because that is the intent -- to get > rid of this extra stat-collect-type leaf), then how do the when-stmts > get applied to the operational value instead of the configured value? > The same issue applies if the when-stmts are within an augment-stmt > > WANT: > > augment /foo-state { > when "stat-collect-type = 'stat-set1'"; > container stat-set1 { > ... > } > } > > RD Provides: > > augment /foo { > when "stat-collect-type = 'stat-set1'"; > container stat-set1 { > config false; > ... > } > } > > There is no way to use when-stmt to reference the operational value. > This is a rather common usage of the when-stmt, so it should not > be removed if RD is used. > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jun 15 08:09:10 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815D612EA95 for ; Thu, 15 Jun 2017 08:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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=yumaworks-com.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 00CHBCcti75s for ; Thu, 15 Jun 2017 08:09:06 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A2D1241FC for ; Thu, 15 Jun 2017 08:09:05 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id x70so2313008wme.0 for ; Thu, 15 Jun 2017 08:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=u76QvT4GNvUTjvmq7I3/PcZncW29HB+AUMGuJunjCro=; b=vqiWqhOeImJdaL/xRMlYq3fHUSDdYkxIIht6yngwTO4nBqfD5JqRpr3Gh2Aqd92PTU lFNW1KiQsh55CBfiF4I4exfhbtjaAdNPQMOmDr7xEpka6yd9u31GmxgSlpR1QwYCiSEW Q2nF0TYNkz9udCQCq5RX+RsT6Qd9gMGhq/xqhqoxecH6bl7WyzmWVE7TdznRkSkB0Sp1 kAXwrIOqmGzm2xxdFsLLitPU8BrrZJvRnkcKEFstoWrtGD6ErcQ5sNJ5AaVMNPr9Tpxp +pJUsSdudBnSEDlf9La7YoMbzWdsOhI7G+Or6niH/vGR5M5mG3DEMtIo+OyECds2/AWa 3mpQ== 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; bh=u76QvT4GNvUTjvmq7I3/PcZncW29HB+AUMGuJunjCro=; b=ZB+B/hj6YxBkKEGviSIELrad/wMF/X1WxOI4JVWKhoSU7jPwZ/mKvoROa0jpXOr2B3 0a/AIpeEbWi2wCY8a9kH2iXKxV5hNvqxiDP02dJJgmYv7BnlSt3kHa03ETvAE+rWz952 oLDfgCz1iNfD35dAlg0aZa/2iuiNOI+fCIkVYeUoUWpLl3wmNEZyuTpbYlfAWbdr0Z/h Yf6dYOTGFKtk1zEJt0dK1soXDOZEdVBl9yjp/9RS5O2rGaTa6EeSL08fmFmTX49ifRT8 OfhdQ5VPOXoI0xmyACdf3Ml1Z/FBMRtP/W2zursxNJ8lkd1cZ/9Fh4KxVBGJBYt7W4bY FNPQ== X-Gm-Message-State: AKS2vOzRPtTNFUUQsd3MwBjXhVPCnHzsxtMeST2K6ze2i/lMPmNbbgT5 2UhJwGW2gB9u9i2bzTnC5hwE7fZj4fmo X-Received: by 10.28.30.3 with SMTP id e3mr2061419wme.60.1497539344222; Thu, 15 Jun 2017 08:09:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.173 with HTTP; Thu, 15 Jun 2017 08:09:03 -0700 (PDT) In-Reply-To: <20170615122716.GB58434@elstar.local> References: <20170615122716.GB58434@elstar.local> From: Andy Bierman Date: Thu, 15 Jun 2017 08:09:03 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114b3508a667be0552010ca9" Archived-At: Subject: Re: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 15:09:08 -0000 --001a114b3508a667be0552010ca9 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Andy, > > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt discusses > the XPath context. An xpath expression in a config-false container > will resolve to the operational state. > > So the usual method of "augment when" is broken: WRONG: Will evaluate when-stmt against config augment /foo { when "some condition"; container stats { } } Correct: Will evaluate when-stmt against operational: augment /foo { container stats { config false; when "different condition"; } } Forcing the augmenting node to be the XPath context node impacts the possible expressions. I think the RD draft should make all this clear. /js > Andy > > On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote: > > Hi, > > > > I don't know if getting rid of /foo-state is such a great idea, > > especially wrt/ counters and other objects that are not > > related to intended config vs. applied config. > > > > Q1) how does a client know the difference between an auto-generated > > foo-state.yang and a real foo-state.yang? Seem like a YANG extension > > is needed to flag an auto-generated foo-state.yang > > > > Q2) How does XPath reference an operational node if the /foo-state > > subtree has been moved to the /foo config subtree? > > > > module foo { > > > > container foo { > > leaf stat-collect-type { > > type enumeration { > > enum stat-set1; > > enum stat-set2; > > } > > } > > } > > > > container foo-state { > > config false; > > leaf stat-collect-type { > > type enumeration { > > enum stat-set1; > > enum stat-set2; > > } > > } > > container stat-set1 { > > when "../stat-collect-type = 'stat-set1'"; > > ... > > } > > container stat-set2 { > > when "../stat-collect-type = 'stat-set2'"; > > ... > > } > > } > > } > > > > In this example, there is a request stat collect type > /foo/stat-collect-type > > and there is an operational value (what the server/device is capable > > of collecting -- e.g. client requests stat-set2 knowing the server > > will change it to stat-set1 if set2 not supported) > > > > So if /foo-state is folded into /foo (because that is the intent -- to > get > > rid of this extra stat-collect-type leaf), then how do the when-stmts > > get applied to the operational value instead of the configured value? > > The same issue applies if the when-stmts are within an augment-stmt > > > > WANT: > > > > augment /foo-state { > > when "stat-collect-type = 'stat-set1'"; > > container stat-set1 { > > ... > > } > > } > > > > RD Provides: > > > > augment /foo { > > when "stat-collect-type = 'stat-set1'"; > > container stat-set1 { > > config false; > > ... > > } > > } > > > > There is no way to use when-stmt to reference the operational value. > > This is a rather common usage of the when-stmt, so it should not > > be removed if RD is used. > > > > > > > > Andy > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114b3508a667be0552010ca9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Andy,

section 5.1 of draft-ietf-netmod-revised-datastores-02.txt discusses the XPath context. An xpath expression in a config-false container
will resolve to the operational state.



So the usual method of = "augment when" is broken:

WRONG: Will ev= aluate when-stmt against config

=C2=A0 =C2=A0augme= nt /foo {
=C2=A0 =C2=A0 =C2=A0 =C2=A0when "some condition&qu= ot;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0container stats { }
=C2= =A0 }

=C2=A0Correct: Will evaluate when-stmt again= st operational:

=C2=A0 =C2=A0augment /foo {
=C2=A0 =C2=A0 =C2=A0 =C2=A0container stats {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0config false;
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0when "different condition";
=C2=A0 =C2=A0 =C2=A0= =C2=A0}
=C2=A0 =C2=A0}

Forcing th= e augmenting node to be the XPath context node impacts the possible express= ions.
I think the RD draft should make all this clear.
=


/js


Andy
=C2= =A0

On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote:
> Hi,
>
> I don't know if getting rid of /foo-state is such a great idea, > especially wrt/ counters and other objects that are not
> related to intended config vs. applied config.
>
> Q1) how does a client know the difference between an auto-generated > foo-state.yang and a real foo-state.yang?=C2=A0 Seem like a YANG exten= sion
> is needed to flag an auto-generated foo-state.yang
>
> Q2) How does XPath reference an operational node if the /foo-state
> subtree has been moved to the /foo config subtree?
>
> module foo {
>
>=C2=A0 =C2=A0 =C2=A0 container foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf stat-collect-type {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum stat-set1;=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum stat-set2;=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0 =C2=A0 container foo-state {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config false;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf stat-collect-type {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum stat-set1;=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum stat-set2;=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container stat-set1 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when "../st= at-collect-type =3D 'stat-set1'";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container stat-set2 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when "../st= at-collect-type =3D 'stat-set2'";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 }
> }
>
> In this example, there is a request stat collect type /foo/stat-collec= t-type
> and there is an operational value (what the server/device is capable > of collecting -- e.g. client requests stat-set2 knowing the server
> will change it to stat-set1 if set2 not supported)
>
> So if /foo-state is folded into /foo (because that is the intent -- to= get
> rid of this extra stat-collect-type leaf), then how do the when-stmts<= br> > get applied to the operational value instead of the configured value?<= br> > The same issue applies if the when-stmts are within an augment-stmt >
> WANT:
>
>=C2=A0 augment /foo-state {
>=C2=A0 =C2=A0 =C2=A0when "stat-collect-type =3D 'stat-set1'= ;";
>=C2=A0 =C2=A0 =C2=A0container stat-set1 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 }
>
> RD Provides:
>
>=C2=A0 =C2=A0augment /foo {
>=C2=A0 =C2=A0 =C2=A0when "stat-collect-type =3D 'stat-set1'= ;";
>=C2=A0 =C2=A0 =C2=A0container stat-set1 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 }
>
> There is no way to use when-stmt to reference the operational value. > This is a rather common usage of the when-stmt, so it should not
> be removed if RD is used.
>
>
>
> Andy

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


--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a114b3508a667be0552010ca9-- From nobody Thu Jun 15 08:41:51 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2916B128D2E for ; Thu, 15 Jun 2017 08:41:50 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAIoBEQsKjhn for ; Thu, 15 Jun 2017 08:41:47 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 22E81127876 for ; Thu, 15 Jun 2017 08:41:47 -0700 (PDT) Received: from localhost (h-13-81.A165.priv.bahnhof.se [155.4.13.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 172191AE0352; Thu, 15 Jun 2017 17:41:44 +0200 (CEST) Date: Thu, 15 Jun 2017 17:41:43 +0200 (CEST) Message-Id: <20170615.174143.206077667263578256.mbj@tail-f.com> To: andy@yumaworks.com Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170615122716.GB58434@elstar.local> 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: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 15:41:50 -0000 Andy Bierman wrote: > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > Andy, > > > > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt discusses > > the XPath context. An xpath expression in a config-false container > > will resolve to the operational state. > > > > > > So the usual method of "augment when" is broken: > > WRONG: Will evaluate when-stmt against config > > augment /foo { > when "some condition"; > container stats { } > } Do you mean that stats is a config true container? And presumably in the stats containter you have config false leafs? I think this works as expected. In a conventional datastore (e.g. running), the stats container exists if "some condition" is true in that datastore. In the operational state, the stats container exists if "some condition" is true in that the operational state datastore. > Correct: Will evaluate when-stmt against operational: > > augment /foo { > container stats { > config false; > when "different condition"; > } > } In this case the stats container will never exist in any conventional datastore, since it is config false. In the operational state, the stats container exists if "different condition" is true in that the operational state datastore. > Forcing the augmenting node to be the XPath context node impacts the > possible expressions. > I think the RD draft should make all this clear. This is not different from how it works today wrt candidate vs running for example. /martin > > > > /js > > > > > Andy > > > > > > On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote: > > > Hi, > > > > > > I don't know if getting rid of /foo-state is such a great idea, > > > especially wrt/ counters and other objects that are not > > > related to intended config vs. applied config. > > > > > > Q1) how does a client know the difference between an auto-generated > > > foo-state.yang and a real foo-state.yang? Seem like a YANG extension > > > is needed to flag an auto-generated foo-state.yang > > > > > > Q2) How does XPath reference an operational node if the /foo-state > > > subtree has been moved to the /foo config subtree? > > > > > > module foo { > > > > > > container foo { > > > leaf stat-collect-type { > > > type enumeration { > > > enum stat-set1; > > > enum stat-set2; > > > } > > > } > > > } > > > > > > container foo-state { > > > config false; > > > leaf stat-collect-type { > > > type enumeration { > > > enum stat-set1; > > > enum stat-set2; > > > } > > > } > > > container stat-set1 { > > > when "../stat-collect-type = 'stat-set1'"; > > > ... > > > } > > > container stat-set2 { > > > when "../stat-collect-type = 'stat-set2'"; > > > ... > > > } > > > } > > > } > > > > > > In this example, there is a request stat collect type > > /foo/stat-collect-type > > > and there is an operational value (what the server/device is capable > > > of collecting -- e.g. client requests stat-set2 knowing the server > > > will change it to stat-set1 if set2 not supported) > > > > > > So if /foo-state is folded into /foo (because that is the intent -- to > > get > > > rid of this extra stat-collect-type leaf), then how do the when-stmts > > > get applied to the operational value instead of the configured value? > > > The same issue applies if the when-stmts are within an augment-stmt > > > > > > WANT: > > > > > > augment /foo-state { > > > when "stat-collect-type = 'stat-set1'"; > > > container stat-set1 { > > > ... > > > } > > > } > > > > > > RD Provides: > > > > > > augment /foo { > > > when "stat-collect-type = 'stat-set1'"; > > > container stat-set1 { > > > config false; > > > ... > > > } > > > } > > > > > > There is no way to use when-stmt to reference the operational value. > > > This is a rather common usage of the when-stmt, so it should not > > > be removed if RD is used. > > > > > > > > > > > > Andy > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > From nobody Thu Jun 15 08:59:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E111292CE for ; Thu, 15 Jun 2017 08:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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=yumaworks-com.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 JxP5IIYIpK9k for ; Thu, 15 Jun 2017 08:59:31 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 B84AD1241FC for ; Thu, 15 Jun 2017 08:59:27 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id d73so3310825wma.0 for ; Thu, 15 Jun 2017 08:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JifA0oKdx0fvohdm52l49dz2VKdR0YqBkuQ4j0R3zQk=; b=17xM2dA7Wwq9CAclXRlX5i3OKuTRvEqhEZ7SHtRtRFGmgJuOkmr2UB0dnu5w9k75eV LWcqRtna/fohEliWlOnPeMNAud+tAYcPi9wVG7HzueWNlcp6WJy9ewWOioyUYvUVeK0X NOAesJiMrH5aj5GzoeUFmSkg4eJDdaXw5lipaHxTMs4g6k1C83nCRXFzvKlgWumIuMJb sF7Q9K20K/Uf+b6kyCkhHlSsy4UVEV5SWQsNSJf+Gv30XooDubxlKnkqfubMYgv8YNdJ UnZ2ykInrv/zXKYZNVw9hZVgTznqo5DUuMnlh4lylm9bsQ9/L9X9aXvepm9kvE149aZ7 ZOTw== 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; bh=JifA0oKdx0fvohdm52l49dz2VKdR0YqBkuQ4j0R3zQk=; b=WErJWJsdamSbqKhwoxRjcemRZ7IYXui+Z7Iy800JQ/cwG3kxOSfv0R+9Zq9W10nU5D WJ1JzRLtV6iJQizuxl9DYKq0PZQXtaVyOAh2NfU7m9FR+Odrw0o0isCHEV28zpajWhPd ONkF6rRHaQwiDJeJ7hXo4flwM0326XY6SYWZC88ajolMT/Gjgs2sRVnmJXJJpenJ2hfu srYSGL3QsNfs19eiIkewmbBHFyBZ5O5Lthf1ZGe+///PWupfCk2wCJYRWBz390soAssk MDXQe5buJRw+ymkGMfBE8y+QdcgYg+KM6uAunkI7xbT+apUnbFXo8xndDK4WN3aEZ7Hw efYg== X-Gm-Message-State: AKS2vOxdHJ4W5sQp4vHoxFkMshYCVHvZvEPTvh83JiD35Q+wJnoN4UfK D1jJILLD/Mw4Aso7DZbAiTyimzmd2E2x X-Received: by 10.28.191.29 with SMTP id p29mr3936020wmf.60.1497542366098; Thu, 15 Jun 2017 08:59:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.173 with HTTP; Thu, 15 Jun 2017 08:59:25 -0700 (PDT) In-Reply-To: <20170615.174143.206077667263578256.mbj@tail-f.com> References: <20170615122716.GB58434@elstar.local> <20170615.174143.206077667263578256.mbj@tail-f.com> From: Andy Bierman Date: Thu, 15 Jun 2017 08:59:25 -0700 Message-ID: To: Martin Bjorklund Cc: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c071c94c4948f055201c08d" Archived-At: Subject: Re: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 15:59:34 -0000 --94eb2c071c94c4948f055201c08d Content-Type: text/plain; charset="UTF-8" On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > Andy, > > > > > > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt discusses > > > the XPath context. An xpath expression in a config-false container > > > will resolve to the operational state. > > > > > > > > > > So the usual method of "augment when" is broken: > > > > WRONG: Will evaluate when-stmt against config > > > > augment /foo { > > when "some condition"; > > container stats { } > > } > > Do you mean that stats is a config true container? And presumably in > the stats containter you have config false leafs? > > no -- stats is a config false container > I think this works as expected. In a conventional datastore > (e.g. running), the stats container exists if "some condition" is true > in that datastore. > no -- in my example the desire is to augment the operational state based on the operational value of a config=true leaf > In the operational state, the stats container exists if "some > condition" is true in that the operational state datastore. > > > Correct: Will evaluate when-stmt against operational: > > > > augment /foo { > > container stats { > > config false; > > when "different condition"; > > } > > } > > In this case the stats container will never exist in any conventional > datastore, since it is config false. > > In the operational state, the stats container exists if "different > condition" is true in that the operational state datastore. > > > Forcing the augmenting node to be the XPath context node impacts the > > possible expressions. > > I think the RD draft should make all this clear. > > This is not different from how it works today wrt candidate vs running > for example. > no -- the datastore doesn't change based on the context node config-stmt value for candidate and running. > > > /martin > > > Andy > > > > > > > > > /js > > > > > > > > > Andy > > > > > > > > > > On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote: > > > > Hi, > > > > > > > > I don't know if getting rid of /foo-state is such a great idea, > > > > especially wrt/ counters and other objects that are not > > > > related to intended config vs. applied config. > > > > > > > > Q1) how does a client know the difference between an auto-generated > > > > foo-state.yang and a real foo-state.yang? Seem like a YANG extension > > > > is needed to flag an auto-generated foo-state.yang > > > > > > > > Q2) How does XPath reference an operational node if the /foo-state > > > > subtree has been moved to the /foo config subtree? > > > > > > > > module foo { > > > > > > > > container foo { > > > > leaf stat-collect-type { > > > > type enumeration { > > > > enum stat-set1; > > > > enum stat-set2; > > > > } > > > > } > > > > } > > > > > > > > container foo-state { > > > > config false; > > > > leaf stat-collect-type { > > > > type enumeration { > > > > enum stat-set1; > > > > enum stat-set2; > > > > } > > > > } > > > > container stat-set1 { > > > > when "../stat-collect-type = 'stat-set1'"; > > > > ... > > > > } > > > > container stat-set2 { > > > > when "../stat-collect-type = 'stat-set2'"; > > > > ... > > > > } > > > > } > > > > } > > > > > > > > In this example, there is a request stat collect type > > > /foo/stat-collect-type > > > > and there is an operational value (what the server/device is capable > > > > of collecting -- e.g. client requests stat-set2 knowing the server > > > > will change it to stat-set1 if set2 not supported) > > > > > > > > So if /foo-state is folded into /foo (because that is the intent -- > to > > > get > > > > rid of this extra stat-collect-type leaf), then how do the when-stmts > > > > get applied to the operational value instead of the configured value? > > > > The same issue applies if the when-stmts are within an augment-stmt > > > > > > > > WANT: > > > > > > > > augment /foo-state { > > > > when "stat-collect-type = 'stat-set1'"; > > > > container stat-set1 { > > > > ... > > > > } > > > > } > > > > > > > > RD Provides: > > > > > > > > augment /foo { > > > > when "stat-collect-type = 'stat-set1'"; > > > > container stat-set1 { > > > > config false; > > > > ... > > > > } > > > > } > > > > > > > > There is no way to use when-stmt to reference the operational value. > > > > This is a rather common usage of the when-stmt, so it should not > > > > be removed if RD is used. > > > > > > > > > > > > > > > > Andy > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > --94eb2c071c94c4948f055201c08d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > Andy,
> >
> > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt d= iscusses
> > the XPath context. An xpath expression in a config-false containe= r
> > will resolve to the operational state.
> >
> >
>
> So the usual method of "augment when" is broken:
>
> WRONG: Will evaluate when-stmt against config
>
>=C2=A0 =C2=A0 augment /foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 when "some condition";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container stats { }
>=C2=A0 =C2=A0}

Do you mean that stats is a config true container?=C2=A0 And presumably in<= br> the stats containter you have config false leafs?


no -- stats is a config false containe= r
=C2=A0
I think this works as expected.=C2=A0 In a conventional datastore
(e.g. running), the stats container exists if "some condition" is= true
in that datastore.


no --= in my example the desire is to augment the operational state based on the<= /div>
operational value of a config=3Dtrue leaf



In the operational state, the stats container exists if "some
condition" is true in that the operational state datastore.

>=C2=A0 Correct: Will evaluate when-stmt against operational:
>
>=C2=A0 =C2=A0 augment /foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container stats {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when "different condition"= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }

In this case the stats container will never exist in any conventional
datastore, since it is config false.

In the operational state, the stats container exists if "different
condition" is true in that the operational state datastore.

> Forcing the augmenting node to be the XPath context node impacts the > possible expressions.
> I think the RD draft should make all this clear.

This is not different from how it works today wrt candidate vs running
for example.

no -- the datastore doesn&= #39;t change based on the context node config-stmt value
for cand= idate and running.

=C2=A0


/martin




Andy
=C2=A0

>
>
>
> /js
> >
>
>
> Andy
>
>
> >
> > On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote:
> > > Hi,
> > >
> > > I don't know if getting rid of /foo-state is such a grea= t idea,
> > > especially wrt/ counters and other objects that are not
> > > related to intended config vs. applied config.
> > >
> > > Q1) how does a client know the difference between an auto-ge= nerated
> > > foo-state.yang and a real foo-state.yang?=C2=A0 Seem like a = YANG extension
> > > is needed to flag an auto-generated foo-state.yang
> > >
> > > Q2) How does XPath reference an operational node if the /foo= -state
> > > subtree has been moved to the /foo config subtree?
> > >
> > > module foo {
> > >
> > >=C2=A0 =C2=A0 =C2=A0 container foo {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf stat-collect-ty= pe {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumera= tion {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum = stat-set1;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum = stat-set2;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > >
> > >=C2=A0 =C2=A0 =C2=A0 container foo-state {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config false;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf stat-collect-ty= pe {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumera= tion {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum = stat-set1;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum = stat-set2;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container stat-set1= {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when &= quot;../stat-collect-type =3D 'stat-set1'";
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0... > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container stat-set2= {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when &= quot;../stat-collect-type =3D 'stat-set2'";
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0... > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 }
> > > }
> > >
> > > In this example, there is a request stat collect type
> > /foo/stat-collect-type
> > > and there is an operational value (what the server/device is= capable
> > > of collecting -- e.g. client requests stat-set2 knowing the = server
> > > will change it to stat-set1 if set2 not supported)
> > >
> > > So if /foo-state is folded into /foo (because that is the in= tent -- to
> > get
> > > rid of this extra stat-collect-type leaf), then how do the w= hen-stmts
> > > get applied to the operational value instead of the configur= ed value?
> > > The same issue applies if the when-stmts are within an augme= nt-stmt
> > >
> > > WANT:
> > >
> > >=C2=A0 augment /foo-state {
> > >=C2=A0 =C2=A0 =C2=A0when "stat-collect-type =3D 'sta= t-set1'";
> > >=C2=A0 =C2=A0 =C2=A0container stat-set1 {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> > >=C2=A0 =C2=A0 =C2=A0}
> > >=C2=A0 }
> > >
> > > RD Provides:
> > >
> > >=C2=A0 =C2=A0augment /foo {
> > >=C2=A0 =C2=A0 =C2=A0when "stat-collect-type =3D 'sta= t-set1'";
> > >=C2=A0 =C2=A0 =C2=A0container stat-set1 {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> > >=C2=A0 =C2=A0 =C2=A0}
> > >=C2=A0 }
> > >
> > > There is no way to use when-stmt to reference the operationa= l value.
> > > This is a rather common usage of the when-stmt, so it should= not
> > > be removed if RD is used.
> > >
> > >
> > >
> > > Andy
> >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinf= o/netmod
> >
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
> >

--94eb2c071c94c4948f055201c08d-- From nobody Thu Jun 15 09:08:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0501292CE for ; Thu, 15 Jun 2017 09:08:53 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNc-ng-grMv8 for ; Thu, 15 Jun 2017 09:08:51 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB54127B52 for ; Thu, 15 Jun 2017 09:08:51 -0700 (PDT) Received: from localhost (h-13-81.A165.priv.bahnhof.se [155.4.13.81]) by mail.tail-f.com (Postfix) with ESMTPSA id DAD6B1AE0352; Thu, 15 Jun 2017 18:08:50 +0200 (CEST) Date: Thu, 15 Jun 2017 18:08:50 +0200 (CEST) Message-Id: <20170615.180850.1310683464764148583.mbj@tail-f.com> To: andy@yumaworks.com Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170615.174143.206077667263578256.mbj@tail-f.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: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 16:08:54 -0000 Andy Bierman wrote: > On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > Andy, > > > > > > > > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt discusses > > > > the XPath context. An xpath expression in a config-false container > > > > will resolve to the operational state. > > > > > > > > > > > > > > So the usual method of "augment when" is broken: > > > > > > WRONG: Will evaluate when-stmt against config > > > > > > augment /foo { > > > when "some condition"; > > > container stats { } > > > } > > > > Do you mean that stats is a config true container? And presumably in > > the stats containter you have config false leafs? > > > > > no -- stats is a config false container Ok. Well, then this is also ok. The stats container will exist if "some condition" is true in the operational state datastore. > > I think this works as expected. In a conventional datastore > > (e.g. running), the stats container exists if "some condition" is true > > in that datastore. > > > > > no -- in my example the desire is to augment the operational state based on > the > operational value of a config=true leaf Yes, that will happen in both cases. > > In the operational state, the stats container exists if "some > > condition" is true in that the operational state datastore. > > > > > Correct: Will evaluate when-stmt against operational: > > > > > > augment /foo { > > > container stats { > > > config false; > > > when "different condition"; > > > } > > > } > > > > In this case the stats container will never exist in any conventional > > datastore, since it is config false. > > > > In the operational state, the stats container exists if "different > > condition" is true in that the operational state datastore. > > > > > Forcing the augmenting node to be the XPath context node impacts the > > > possible expressions. > > > I think the RD draft should make all this clear. > > > > This is not different from how it works today wrt candidate vs running > > for example. > > > > no -- the datastore doesn't change based on the context node config-stmt > value > for candidate and running. The datastore doesn't change with NMDA either - an XPath expression is always evaluated in a particular datastore, just like before. There is no mechanism to read data from a different datastore in the XPath expressions. /martin > > > > > > > > > /martin > > > > > > > > Andy > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote: > > > > > Hi, > > > > > > > > > > I don't know if getting rid of /foo-state is such a great idea, > > > > > especially wrt/ counters and other objects that are not > > > > > related to intended config vs. applied config. > > > > > > > > > > Q1) how does a client know the difference between an auto-generated > > > > > foo-state.yang and a real foo-state.yang? Seem like a YANG extension > > > > > is needed to flag an auto-generated foo-state.yang > > > > > > > > > > Q2) How does XPath reference an operational node if the /foo-state > > > > > subtree has been moved to the /foo config subtree? > > > > > > > > > > module foo { > > > > > > > > > > container foo { > > > > > leaf stat-collect-type { > > > > > type enumeration { > > > > > enum stat-set1; > > > > > enum stat-set2; > > > > > } > > > > > } > > > > > } > > > > > > > > > > container foo-state { > > > > > config false; > > > > > leaf stat-collect-type { > > > > > type enumeration { > > > > > enum stat-set1; > > > > > enum stat-set2; > > > > > } > > > > > } > > > > > container stat-set1 { > > > > > when "../stat-collect-type = 'stat-set1'"; > > > > > ... > > > > > } > > > > > container stat-set2 { > > > > > when "../stat-collect-type = 'stat-set2'"; > > > > > ... > > > > > } > > > > > } > > > > > } > > > > > > > > > > In this example, there is a request stat collect type > > > > /foo/stat-collect-type > > > > > and there is an operational value (what the server/device is capable > > > > > of collecting -- e.g. client requests stat-set2 knowing the server > > > > > will change it to stat-set1 if set2 not supported) > > > > > > > > > > So if /foo-state is folded into /foo (because that is the intent -- > > to > > > > get > > > > > rid of this extra stat-collect-type leaf), then how do the when-stmts > > > > > get applied to the operational value instead of the configured value? > > > > > The same issue applies if the when-stmts are within an augment-stmt > > > > > > > > > > WANT: > > > > > > > > > > augment /foo-state { > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > container stat-set1 { > > > > > ... > > > > > } > > > > > } > > > > > > > > > > RD Provides: > > > > > > > > > > augment /foo { > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > container stat-set1 { > > > > > config false; > > > > > ... > > > > > } > > > > > } > > > > > > > > > > There is no way to use when-stmt to reference the operational value. > > > > > This is a rather common usage of the when-stmt, so it should not > > > > > be removed if RD is used. > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > Fax: +49 421 200 3103 > > > > > > From nobody Thu Jun 15 09:15:30 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6E71200CF for ; Thu, 15 Jun 2017 09:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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=yumaworks-com.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 G4shHErdCbc5 for ; Thu, 15 Jun 2017 09:15:26 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 8470F126C22 for ; Thu, 15 Jun 2017 09:15:25 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id n195so3710465wmg.1 for ; Thu, 15 Jun 2017 09:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HpbMQ4z8ZsoBw/n6MQ9y6O3kK0UngiOuq82bvBS8vN8=; b=U2+jNcN7rDx9MfG48vkP9ncYMRmpI+z2JJ4xyaS0Q9dtJwykM6/ShM9467E3GMckQb KdzX5Lhjg3hGS7LsDREPmv87G9p7UxMHq9HOMkt0fhBIAjbDJDHltEGyRDrjM2/XTs+9 BmRh5wOD/CPuMJXMq0uLZ9BMkAV5DkCCTuvtLPjH8s0abP0Iw79ak6GUB7tvu2bsT0i6 ZZoXVOCICPPpY8ngKxZgz8aH+4OFsWxSAxOp1XbSRchguYvrRkxl+2ZhEuaZ7Tqce1RY 66uLodlWv6WFBneU0bHUTzaJ/qAZL92zCumEaRH0NtNKxO9cAVp7w1AAhn8nH6QfYEie 6b9g== 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; bh=HpbMQ4z8ZsoBw/n6MQ9y6O3kK0UngiOuq82bvBS8vN8=; b=nVY3U4QQfOudJUXc8TZ7qhAlSxpstxABuvccirDijayuzYtSa99MXr2dzcgAmspvIL Un0FfIT9/7cFQNqCzNza2YhcThsHWj0yBEzIKagZTgYQOaGY8AcOAJ2nGviSVB3lvULy u/aQyfJKgHJJy6iYJUNFQdecrVaAx1uFLwAhbDdLWDJboKxyLwSVY6SD+Cp3cOw+CPMD b3RpepFat91TNO68b4yTDOsqiZikYbLB6ShKn+MafBjCaQl/JUdqFEwpeswcGD4URU8F dcTeHgt20OA2ZH+2wZKnCskW0iSoJSzKRSmSygh8eZEHk+99bPwfmq+sDKHF8IsMTMy/ LwgA== X-Gm-Message-State: AKS2vOzvlUWKxjMnHvYeCHC6uK4nkP7ZZ2C4iL6hSdpHKvnwylTUfCsf 7pnpVHtXdSFtCz6evZfxR5yDjVM09sob X-Received: by 10.28.181.201 with SMTP id e192mr4257975wmf.48.1497543323898; Thu, 15 Jun 2017 09:15:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.173 with HTTP; Thu, 15 Jun 2017 09:15:23 -0700 (PDT) In-Reply-To: <20170615.180850.1310683464764148583.mbj@tail-f.com> References: <20170615.174143.206077667263578256.mbj@tail-f.com> <20170615.180850.1310683464764148583.mbj@tail-f.com> From: Andy Bierman Date: Thu, 15 Jun 2017 09:15:23 -0700 Message-ID: To: Martin Bjorklund Cc: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="f403045f55e2db6e1e055201f95f" Archived-At: Subject: Re: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 16:15:29 -0000 --f403045f55e2db6e1e055201f95f Content-Type: text/plain; charset="UTF-8" On Thu, Jun 15, 2017 at 9:08 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > Andy, > > > > > > > > > > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt > discusses > > > > > the XPath context. An xpath expression in a config-false container > > > > > will resolve to the operational state. > > > > > > > > > > > > > > > > > > So the usual method of "augment when" is broken: > > > > > > > > WRONG: Will evaluate when-stmt against config > > > > > > > > augment /foo { > > > > when "some condition"; > > > > container stats { } > > > > } > > > > > > Do you mean that stats is a config true container? And presumably in > > > the stats containter you have config false leafs? > > > > > > > > no -- stats is a config false container > > Ok. Well, then this is also ok. The stats container will exist if > "some condition" is true in the operational state datastore. > > > > I think this works as expected. In a conventional datastore > > > (e.g. running), the stats container exists if "some condition" is true > > > in that datastore. > > > > > > > > > no -- in my example the desire is to augment the operational state based > on > > the > > operational value of a config=true leaf > > Yes, that will happen in both cases. > > > > In the operational state, the stats container exists if "some > > > condition" is true in that the operational state datastore. > > > > > > > Correct: Will evaluate when-stmt against operational: > > > > > > > > augment /foo { > > > > container stats { > > > > config false; > > > > when "different condition"; > > > > } > > > > } > > > > > > In this case the stats container will never exist in any conventional > > > datastore, since it is config false. > > > > > > In the operational state, the stats container exists if "different > > > condition" is true in that the operational state datastore. > > > > > > > Forcing the augmenting node to be the XPath context node impacts the > > > > possible expressions. > > > > I think the RD draft should make all this clear. > > > > > > This is not different from how it works today wrt candidate vs running > > > for example. > > > > > > > no -- the datastore doesn't change based on the context node config-stmt > > value > > for candidate and running. > > The datastore doesn't change with NMDA either - an XPath expression is > always evaluated in a particular datastore, just like before. There > is no mechanism to read data from a different datastore in the XPath > expressions. > > > But in the first example the when-stmt is evaluated in the context of /foo which is config=true. Doesn't that mean the configuration values will be used? The config=false nodes added if the when-stmt is true are not the context nodes in the first form. Authors need to be careful to put the when-stmt in a config=false context node in order to evaluate in the operational datastore. > /martin > Andy > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote: > > > > > > Hi, > > > > > > > > > > > > I don't know if getting rid of /foo-state is such a great idea, > > > > > > especially wrt/ counters and other objects that are not > > > > > > related to intended config vs. applied config. > > > > > > > > > > > > Q1) how does a client know the difference between an > auto-generated > > > > > > foo-state.yang and a real foo-state.yang? Seem like a YANG > extension > > > > > > is needed to flag an auto-generated foo-state.yang > > > > > > > > > > > > Q2) How does XPath reference an operational node if the > /foo-state > > > > > > subtree has been moved to the /foo config subtree? > > > > > > > > > > > > module foo { > > > > > > > > > > > > container foo { > > > > > > leaf stat-collect-type { > > > > > > type enumeration { > > > > > > enum stat-set1; > > > > > > enum stat-set2; > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > container foo-state { > > > > > > config false; > > > > > > leaf stat-collect-type { > > > > > > type enumeration { > > > > > > enum stat-set1; > > > > > > enum stat-set2; > > > > > > } > > > > > > } > > > > > > container stat-set1 { > > > > > > when "../stat-collect-type = 'stat-set1'"; > > > > > > ... > > > > > > } > > > > > > container stat-set2 { > > > > > > when "../stat-collect-type = 'stat-set2'"; > > > > > > ... > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > In this example, there is a request stat collect type > > > > > /foo/stat-collect-type > > > > > > and there is an operational value (what the server/device is > capable > > > > > > of collecting -- e.g. client requests stat-set2 knowing the > server > > > > > > will change it to stat-set1 if set2 not supported) > > > > > > > > > > > > So if /foo-state is folded into /foo (because that is the intent > -- > > > to > > > > > get > > > > > > rid of this extra stat-collect-type leaf), then how do the > when-stmts > > > > > > get applied to the operational value instead of the configured > value? > > > > > > The same issue applies if the when-stmts are within an > augment-stmt > > > > > > > > > > > > WANT: > > > > > > > > > > > > augment /foo-state { > > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > > container stat-set1 { > > > > > > ... > > > > > > } > > > > > > } > > > > > > > > > > > > RD Provides: > > > > > > > > > > > > augment /foo { > > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > > container stat-set1 { > > > > > > config false; > > > > > > ... > > > > > > } > > > > > > } > > > > > > > > > > > > There is no way to use when-stmt to reference the operational > value. > > > > > > This is a rather common usage of the when-stmt, so it should not > > > > > > be removed if RD is used. > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > > Fax: +49 421 200 3103 > > > > > > > > > --f403045f55e2db6e1e055201f95f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 15, 2017 at 9:08 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder <<= br> > > > j.sc= hoenwaelder@jacobs-university.de> wrote:
> > >
> > > > Andy,
> > > >
> > > > section 5.1 of draft-ietf-netmod-revised-datastore= s-02.txt discusses
> > > > the XPath context. An xpath expression in a config-fals= e container
> > > > will resolve to the operational state.
> > > >
> > > >
> > >
> > > So the usual method of "augment when" is broken: > > >
> > > WRONG: Will evaluate when-stmt against config
> > >
> > >=C2=A0 =C2=A0 augment /foo {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 when "some condition";<= br> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container stats { }
> > >=C2=A0 =C2=A0}
> >
> > Do you mean that stats is a config true container?=C2=A0 And pres= umably in
> > the stats containter you have config false leafs?
> >
> >
> no -- stats is a config false container

Ok.=C2=A0 Well, then this is also ok.=C2=A0 The stats container will exist = if
"some condition" is true in the operational state datastore.

> > I think this works as expected.=C2=A0 In a conventional datastore=
> > (e.g. running), the stats container exists if "some conditio= n" is true
> > in that datastore.
> >
>
>
> no -- in my example the desire is to augment the operational state bas= ed on
> the
> operational value of a config=3Dtrue leaf

Yes, that will happen in both cases.

> > In the operational state, the stats container exists if "som= e
> > condition" is true in that the operational state datastore.<= br> > >
> > >=C2=A0 Correct: Will evaluate when-stmt against operational:<= br> > > >
> > >=C2=A0 =C2=A0 augment /foo {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container stats {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when "different condi= tion";
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 }
> >
> > In this case the stats container will never exist in any conventi= onal
> > datastore, since it is config false.
> >
> > In the operational state, the stats container exists if "dif= ferent
> > condition" is true in that the operational state datastore.<= br> > >
> > > Forcing the augmenting node to be the XPath context node imp= acts the
> > > possible expressions.
> > > I think the RD draft should make all this clear.
> >
> > This is not different from how it works today wrt candidate vs ru= nning
> > for example.
> >
>
> no -- the datastore doesn't change based on the context node confi= g-stmt
> value
> for candidate and running.

The datastore doesn't change with NMDA either - an XPath expression is<= br> always evaluated in a particular datastore, just like before.=C2=A0 There is no mechanism to read data from a different datastore in the XPath
expressions.




But in the first exampl= e the when-stmt is evaluated in the context of /foo which is config=3Dtrue.=
Doesn't that mean the configuration values will be used?

The config=3Dfalse nodes added if the when-stmt is tr= ue are not the context nodes in the first form.
Authors need to b= e careful to put the when-stmt in a config=3Dfalse context node in order
to evaluate in the operational datastore.

= =C2=A0
/martin


Andy
= =C2=A0




>
>
>
> >
> >
> > /martin
> >
> >
> >
>
> Andy
>
>
> >
> > >
> > >
> > >
> > > /js
> > > >
> > >
> > >
> > > Andy
> > >
> > >
> > > >
> > > > On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman = wrote:
> > > > > Hi,
> > > > >
> > > > > I don't know if getting rid of /foo-state is s= uch a great idea,
> > > > > especially wrt/ counters and other objects that ar= e not
> > > > > related to intended config vs. applied config.
> > > > >
> > > > > Q1) how does a client know the difference between = an auto-generated
> > > > > foo-state.yang and a real foo-state.yang?=C2=A0 Se= em like a YANG extension
> > > > > is needed to flag an auto-generated foo-state.yang=
> > > > >
> > > > > Q2) How does XPath reference an operational node i= f the /foo-state
> > > > > subtree has been moved to the /foo config subtree?=
> > > > >
> > > > > module foo {
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 container foo {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf stat-= collect-type {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ty= pe enumeration {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 enum stat-set1;
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 enum stat-set2;
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<= br> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 container foo-state {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config fal= se;
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf stat-= collect-type {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ty= pe enumeration {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 enum stat-set1;
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 enum stat-set2;
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<= br> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container= stat-set1 {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0when "../stat-collect-type =3D 'stat-set1'";
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0...
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container= stat-set2 {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0when "../stat-collect-type =3D 'stat-set2'";
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0...
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > > >=C2=A0 =C2=A0 =C2=A0 }
> > > > > }
> > > > >
> > > > > In this example, there is a request stat collect t= ype
> > > > /foo/stat-collect-type
> > > > > and there is an operational value (what the server= /device is capable
> > > > > of collecting -- e.g. client requests stat-set2 kn= owing the server
> > > > > will change it to stat-set1 if set2 not supported)=
> > > > >
> > > > > So if /foo-state is folded into /foo (because that= is the intent --
> > to
> > > > get
> > > > > rid of this extra stat-collect-type leaf), then ho= w do the when-stmts
> > > > > get applied to the operational value instead of th= e configured value?
> > > > > The same issue applies if the when-stmts are withi= n an augment-stmt
> > > > >
> > > > > WANT:
> > > > >
> > > > >=C2=A0 augment /foo-state {
> > > > >=C2=A0 =C2=A0 =C2=A0when "stat-collect-type = =3D 'stat-set1'";
> > > > >=C2=A0 =C2=A0 =C2=A0container stat-set1 {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> > > > >=C2=A0 =C2=A0 =C2=A0}
> > > > >=C2=A0 }
> > > > >
> > > > > RD Provides:
> > > > >
> > > > >=C2=A0 =C2=A0augment /foo {
> > > > >=C2=A0 =C2=A0 =C2=A0when "stat-collect-type = =3D 'stat-set1'";
> > > > >=C2=A0 =C2=A0 =C2=A0container stat-set1 {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> > > > >=C2=A0 =C2=A0 =C2=A0}
> > > > >=C2=A0 }
> > > > >
> > > > > There is no way to use when-stmt to reference the = operational value.
> > > > > This is a rather common usage of the when-stmt, so= it should not
> > > > > be removed if RD is used.
> > > > >
> > > > >
> > > > >
> > > > > Andy
> > > >
> > > > > _____________________________________________= __
> > > > > netmod mailing list
> > > > > netmod@ietf.org=
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > >
> > > > --
> > > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Jacobs University Bremen gGmbH
> > > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Campus Ring 1 | 28759 Bremen | Germany
> > > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<http://www.jacobs-university.de/>
> > > >
> >

--f403045f55e2db6e1e055201f95f-- From nobody Thu Jun 15 09:18:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C7F129486 for ; Thu, 15 Jun 2017 09:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTx7rypyYY0e for ; Thu, 15 Jun 2017 09:18:27 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47E81200CF for ; Thu, 15 Jun 2017 09:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4341; q=dns/txt; s=iport; t=1497543506; x=1498753106; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=w89w5WSapM7pw5apc+bSTOCbnLrkWJbgLaNQ5WeQop0=; b=hUEAHR4a/DeJzqKS+9cCxXTV01/B8mBj6U1Rv8EPynV8ZpIX6FpXLKrM 974/GrcgQZowu4PHBGxkxXHSYYe6vuGDhfjopgCm194dezLQpS6mVLaHs 58G71583TJ8y9xb9EpsE++7GoM0+zZo+iMu+rBDoQeHcuB9Z8uwEd39NZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAACQskJZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqBDY4Oc5EDlgeCESENhSxKAoMiGAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgEBATY2GwsYLicwBgEMBgIBAYogCBCtB4tBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R+GYoFgK4J3gyaHNwEElw6HO4cujCeCB1WEcYNLhnOMPIhDHziBCjAhCBsVHyq?= =?us-ascii?q?HED82hxUrghIBAQE?= X-IronPort-AV: E=Sophos;i="5.39,343,1493683200"; d="scan'208";a="652602222" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2017 16:18:24 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v5FGIOmK031770; Thu, 15 Jun 2017 16:18:24 GMT To: Vladimir Vassilev , netmod@ietf.org References: <148943391240.20421.7015046968650807465@ietfa.amsl.com> From: Robert Wilton Message-ID: Date: Thu, 15 Jun 2017 17:18:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 16:18:30 -0000 Hi Vladimir, Thanks for raising this. On 15/06/2017 12:59, Vladimir Vassilev wrote: > Hello, > > There is a problem with a mutually exclusive 'when' statements for the > /interfaces/inteface/encapsulation container in > ietf-interfaces-common@2017-03-13.yang > (draft-ietf-netmod-intf-ext-yang-04) and > ietf-if-l3-vlan@2017-03-13.yang models causing error with our > validation tools. > > As defined in ietf-interfaces-common@2017-03-13.yang: > > ... > > container encapsulation { > when > "derived-from-or-self(../if:type, > 'ianaift:ethernetCsmacd') or > derived-from-or-self(../if:type, > 'ianaift:ieee8023adLag') or > derived-from-or-self(../if:type, 'ianaift:pos') or > derived-from-or-self(../if:type, > 'ianaift:atmSubInterface') or > derived-from-or-self(../if:type, 'ethSubInterface')" { > > ... > > and here augmented in ietf-if-l3-vlan@2017-03-13.yang: > > augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + > "if-cmn:encaps-type" { > when "../if:type = 'ianaift:l2vlan' and > derived-from-or-self(../if-cmn:forwarding-mode, > 'if-cmn:network-layer')" { > > Short term fix I use is to add "or derived-from-or-self(../if:type, > 'ianaift:l2vlan')" to the ietf-interfaces-common definition. I suspect that probably the reverse fix is probably better. I.e. add derived-from-or-self(../if:type, 'ethSubInterface' to the encapsulation when statement replacing the l2vlan, since ethSubInterface derived from l2vlan anyway. Thanks, Rob > > > Vladimir > > > On 03/13/2017 08:38 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the NETCONF Data Modeling Language of >> the IETF. >> >> Title : Sub-interface VLAN YANG Data Models >> Authors : Robert Wilton >> David Ball >> Tapraj Singh >> Selvakumar Sivaraj >> Filename : draft-ietf-netmod-sub-intf-vlan-model-01.txt >> Pages : 27 >> Date : 2017-03-13 >> >> Abstract: >> This document defines YANG modules to add support for classifying >> traffic received on interfaces as Ethernet/VLAN framed packets to >> sub-interfaces based on the fields available in the Ethernet/VLAN >> frame headers. These modules allow configuration of Layer 3 and >> Layer 2 sub-interfaces (e.g. attachment circuits) that can >> interoperate with IETF based forwarding protocols; such as IP and >> L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The >> sub-interfaces also interoperate with VLAN tagged traffic orginating >> from an IEEE 802.1Q compliant bridge. Primarily the classification >> is based on VLAN identifiers in the 802.1Q VLAN tags, but the model >> also has support for matching on some other layer 2 frame header >> fields and is designed to be extensible to match on other arbitrary >> header fields. >> >> The model differs from an IEEE 802.1Q bridge model in that the >> configuration is interface/sub-interface based as opposed to being >> based on membership of an 802.1Q VLAN bridge. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-sub-intf-vlan-model-01 >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > . > From nobody Thu Jun 15 12:03:30 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13CA127078 for ; Thu, 15 Jun 2017 12:03:28 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZW7thumyAg2 for ; Thu, 15 Jun 2017 12:03:26 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CD00D127866 for ; Thu, 15 Jun 2017 12:03:25 -0700 (PDT) Received: from localhost (h-13-81.A165.priv.bahnhof.se [155.4.13.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 793F01AE0352; Thu, 15 Jun 2017 21:03:24 +0200 (CEST) Date: Thu, 15 Jun 2017 21:03:24 +0200 (CEST) Message-Id: <20170615.210324.866114685910056800.mbj@tail-f.com> To: andy@yumaworks.com Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170615.180850.1310683464764148583.mbj@tail-f.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: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 19:03:29 -0000 Andy Bierman wrote: > On Thu, Jun 15, 2017 at 9:08 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund > > wrote: > > > > > > > Andy Bierman wrote: > > > > > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder < > > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > > > Andy, > > > > > > > > > > > > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt > > discusses > > > > > > the XPath context. An xpath expression in a config-false container > > > > > > will resolve to the operational state. > > > > > > > > > > > > > > > > > > > > > > So the usual method of "augment when" is broken: > > > > > > > > > > WRONG: Will evaluate when-stmt against config > > > > > > > > > > augment /foo { > > > > > when "some condition"; > > > > > container stats { } > > > > > } > > > > > > > > Do you mean that stats is a config true container? And presumably in > > > > the stats containter you have config false leafs? > > > > > > > > > > > no -- stats is a config false container > > > > Ok. Well, then this is also ok. The stats container will exist if > > "some condition" is true in the operational state datastore. > > > > > > I think this works as expected. In a conventional datastore > > > > (e.g. running), the stats container exists if "some condition" is true > > > > in that datastore. > > > > > > > > > > > > > no -- in my example the desire is to augment the operational state based > > on > > > the > > > operational value of a config=true leaf > > > > Yes, that will happen in both cases. > > > > > > In the operational state, the stats container exists if "some > > > > condition" is true in that the operational state datastore. > > > > > > > > > Correct: Will evaluate when-stmt against operational: > > > > > > > > > > augment /foo { > > > > > container stats { > > > > > config false; > > > > > when "different condition"; > > > > > } > > > > > } > > > > > > > > In this case the stats container will never exist in any conventional > > > > datastore, since it is config false. > > > > > > > > In the operational state, the stats container exists if "different > > > > condition" is true in that the operational state datastore. > > > > > > > > > Forcing the augmenting node to be the XPath context node impacts the > > > > > possible expressions. > > > > > I think the RD draft should make all this clear. > > > > > > > > This is not different from how it works today wrt candidate vs running > > > > for example. > > > > > > > > > > no -- the datastore doesn't change based on the context node config-stmt > > > value > > > for candidate and running. > > > > The datastore doesn't change with NMDA either - an XPath expression is > > always evaluated in a particular datastore, just like before. There > > is no mechanism to read data from a different datastore in the XPath > > expressions. > > > > > > > > But in the first example the when-stmt is evaluated in the context of /foo > which is config=true. > Doesn't that mean the configuration values will be used? No, the values of these nodes in the operational state datastore will be used (these are the "applied configuration" values). > The config=false nodes added if the when-stmt is true are not the context > nodes in the first form. > Authors need to be careful to put the when-stmt in a config=false context > node in order > to evaluate in the operational datastore. No, see above. /martin > > > > > /martin > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I don't know if getting rid of /foo-state is such a great idea, > > > > > > > especially wrt/ counters and other objects that are not > > > > > > > related to intended config vs. applied config. > > > > > > > > > > > > > > Q1) how does a client know the difference between an > > auto-generated > > > > > > > foo-state.yang and a real foo-state.yang? Seem like a YANG > > extension > > > > > > > is needed to flag an auto-generated foo-state.yang > > > > > > > > > > > > > > Q2) How does XPath reference an operational node if the > > /foo-state > > > > > > > subtree has been moved to the /foo config subtree? > > > > > > > > > > > > > > module foo { > > > > > > > > > > > > > > container foo { > > > > > > > leaf stat-collect-type { > > > > > > > type enumeration { > > > > > > > enum stat-set1; > > > > > > > enum stat-set2; > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > container foo-state { > > > > > > > config false; > > > > > > > leaf stat-collect-type { > > > > > > > type enumeration { > > > > > > > enum stat-set1; > > > > > > > enum stat-set2; > > > > > > > } > > > > > > > } > > > > > > > container stat-set1 { > > > > > > > when "../stat-collect-type = 'stat-set1'"; > > > > > > > ... > > > > > > > } > > > > > > > container stat-set2 { > > > > > > > when "../stat-collect-type = 'stat-set2'"; > > > > > > > ... > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > In this example, there is a request stat collect type > > > > > > /foo/stat-collect-type > > > > > > > and there is an operational value (what the server/device is > > capable > > > > > > > of collecting -- e.g. client requests stat-set2 knowing the > > server > > > > > > > will change it to stat-set1 if set2 not supported) > > > > > > > > > > > > > > So if /foo-state is folded into /foo (because that is the intent > > -- > > > > to > > > > > > get > > > > > > > rid of this extra stat-collect-type leaf), then how do the > > when-stmts > > > > > > > get applied to the operational value instead of the configured > > value? > > > > > > > The same issue applies if the when-stmts are within an > > augment-stmt > > > > > > > > > > > > > > WANT: > > > > > > > > > > > > > > augment /foo-state { > > > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > > > container stat-set1 { > > > > > > > ... > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > RD Provides: > > > > > > > > > > > > > > augment /foo { > > > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > > > container stat-set1 { > > > > > > > config false; > > > > > > > ... > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > There is no way to use when-stmt to reference the operational > > value. > > > > > > > This is a rather common usage of the when-stmt, so it should not > > > > > > > be removed if RD is used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > _______________________________________________ > > > > > > > netmod mailing list > > > > > > > netmod@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > > > > > > Fax: +49 421 200 3103 > > > > > > > > > > > > From nobody Thu Jun 15 12:23:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA61A120227 for ; Thu, 15 Jun 2017 12:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=yumaworks-com.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 m7TjvpX_pskh for ; Thu, 15 Jun 2017 12:23: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 18446127078 for ; Thu, 15 Jun 2017 12:23:11 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id 36so27321662wry.3 for ; Thu, 15 Jun 2017 12:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fg9RDhs3lrDsB0Zn2Uy6EEKZ77/C+QiCgSabRWbBcKY=; b=vIT0nGEz2YhF2XQMzDWyc/eJUlOROrdkNLPUr8VTNYF2jw2ihOnCuj7uzrEhJTmFhe tCPUyKvVUgiSEKdJBR+aQ9C45w1EpxudAg+V/5EjIZnK1grmIQBWdy2GPNuWXwos1txV AfumhNYHF8NSbmdec3OC3OxQ+vTiV3Ff7WjfEn47HNk13tU42MDp8V37IONXhxTwPpBR RAB8hehm7qNHl6LAJBMp3JgOfAmR/dBP9ZwXmESg51612ofB134PRFlvRx9Yx8xQR9UB K3Y0yGnckdafB8rd3QYUcq7TK+TugT6oEMsySFQRsjhagdkAFwMtlDBk94FM8ZwIziyF fAxQ== 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; bh=Fg9RDhs3lrDsB0Zn2Uy6EEKZ77/C+QiCgSabRWbBcKY=; b=L636yPmjlBZRilWWbHLPqt0qmoenrzHbPBR8OT4SofrxN2MGWH3HFVvYIGpnS/xAJj GBDmJ0j9N1fyRLv4joXDfk8BsE3x0WaO1z3Yj/0lF6bIDGbqznGvwwRHFAMiSkqnlv68 6KbcwcRyKpdAhhGu9nU67U1qKE1lpzvSE3R7Vqz21qSzh1UMlSYG0WSp76xeJJ4p0y9i 6Yh5r9xUrH2RrU+2KId5kRcVeADi86H+ieYozYBlFMw4xTVP1UifYg5JSHPy+Jmcgn1S 8owmGBVV9ZHB3TRSVycEQmfPt3J4fEqL1Du/TbczrEwUpK77nQdG8lSGEGlioDr7FxEq NhTA== X-Gm-Message-State: AKS2vOwszgLa97j861qs9le2Eo5BhBAVzMdDDc9AgzVyn78N+J0poA/P /GQ44tRD1g10Hz0F+a/XhO4aXVAqoxBfeH8= X-Received: by 10.223.176.253 with SMTP id j58mr4626379wra.65.1497554590464; Thu, 15 Jun 2017 12:23:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.173 with HTTP; Thu, 15 Jun 2017 12:23:09 -0700 (PDT) In-Reply-To: <20170615.210324.866114685910056800.mbj@tail-f.com> References: <20170615.180850.1310683464764148583.mbj@tail-f.com> <20170615.210324.866114685910056800.mbj@tail-f.com> From: Andy Bierman Date: Thu, 15 Jun 2017 12:23:09 -0700 Message-ID: To: Martin Bjorklund Cc: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a11c0204c659a6b05520499d1" Archived-At: Subject: Re: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 19:23:16 -0000 --001a11c0204c659a6b05520499d1 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 15, 2017 at 12:03 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Jun 15, 2017 at 9:08 AM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund > > > wrote: > > > > > > > > > Andy Bierman wrote: > > > > > > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder < > > > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > > > > > Andy, > > > > > > > > > > > > > > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt > > > discusses > > > > > > > the XPath context. An xpath expression in a config-false > container > > > > > > > will resolve to the operational state. > > > > > > > > > > > > > > > > > > > > > > > > > > So the usual method of "augment when" is broken: > > > > > > > > > > > > WRONG: Will evaluate when-stmt against config > > > > > > > > > > > > augment /foo { > > > > > > when "some condition"; > > > > > > container stats { } > > > > > > } > > > > > > > > > > Do you mean that stats is a config true container? And presumably > in > > > > > the stats containter you have config false leafs? > > > > > > > > > > > > > > no -- stats is a config false container > > > > > > Ok. Well, then this is also ok. The stats container will exist if > > > "some condition" is true in the operational state datastore. > > > > > > > > I think this works as expected. In a conventional datastore > > > > > (e.g. running), the stats container exists if "some condition" is > true > > > > > in that datastore. > > > > > > > > > > > > > > > > > no -- in my example the desire is to augment the operational state > based > > > on > > > > the > > > > operational value of a config=true leaf > > > > > > Yes, that will happen in both cases. > > > > > > > > In the operational state, the stats container exists if "some > > > > > condition" is true in that the operational state datastore. > > > > > > > > > > > Correct: Will evaluate when-stmt against operational: > > > > > > > > > > > > augment /foo { > > > > > > container stats { > > > > > > config false; > > > > > > when "different condition"; > > > > > > } > > > > > > } > > > > > > > > > > In this case the stats container will never exist in any > conventional > > > > > datastore, since it is config false. > > > > > > > > > > In the operational state, the stats container exists if "different > > > > > condition" is true in that the operational state datastore. > > > > > > > > > > > Forcing the augmenting node to be the XPath context node impacts > the > > > > > > possible expressions. > > > > > > I think the RD draft should make all this clear. > > > > > > > > > > This is not different from how it works today wrt candidate vs > running > > > > > for example. > > > > > > > > > > > > > no -- the datastore doesn't change based on the context node > config-stmt > > > > value > > > > for candidate and running. > > > > > > The datastore doesn't change with NMDA either - an XPath expression is > > > always evaluated in a particular datastore, just like before. There > > > is no mechanism to read data from a different datastore in the XPath > > > expressions. > > > > > > > > > > > > > But in the first example the when-stmt is evaluated in the context of > /foo > > which is config=true. > > Doesn't that mean the configuration values will be used? > > No, the values of these nodes in the operational state datastore will > be used (these are the "applied configuration" values). > > > The config=false nodes added if the when-stmt is true are not the context > > nodes in the first form. > > Authors need to be careful to put the when-stmt in a config=false context > > node in order > > to evaluate in the operational datastore. > > No, see above. > > Sec 5.1 of the RD draft does not mention config=true nodes. augment /foo { when "blah"; } The XPatch context node for this when-stmt is /foo, which is a config=true node. Sec 5.1 says o If the XPath expression is defined in a substatement to a data node that represents system state, the accessible tree is all operational state in the server. The root node has all top-level data nodes in all modules as children. The augment is a top-level statement in this example, so this text does not apply > /martin > Andy > > > > > > > > > > > > /martin > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 14, 2017 at 11:07:35AM -0700, Andy Bierman wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I don't know if getting rid of /foo-state is such a great > idea, > > > > > > > > especially wrt/ counters and other objects that are not > > > > > > > > related to intended config vs. applied config. > > > > > > > > > > > > > > > > Q1) how does a client know the difference between an > > > auto-generated > > > > > > > > foo-state.yang and a real foo-state.yang? Seem like a YANG > > > extension > > > > > > > > is needed to flag an auto-generated foo-state.yang > > > > > > > > > > > > > > > > Q2) How does XPath reference an operational node if the > > > /foo-state > > > > > > > > subtree has been moved to the /foo config subtree? > > > > > > > > > > > > > > > > module foo { > > > > > > > > > > > > > > > > container foo { > > > > > > > > leaf stat-collect-type { > > > > > > > > type enumeration { > > > > > > > > enum stat-set1; > > > > > > > > enum stat-set2; > > > > > > > > } > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > container foo-state { > > > > > > > > config false; > > > > > > > > leaf stat-collect-type { > > > > > > > > type enumeration { > > > > > > > > enum stat-set1; > > > > > > > > enum stat-set2; > > > > > > > > } > > > > > > > > } > > > > > > > > container stat-set1 { > > > > > > > > when "../stat-collect-type = 'stat-set1'"; > > > > > > > > ... > > > > > > > > } > > > > > > > > container stat-set2 { > > > > > > > > when "../stat-collect-type = 'stat-set2'"; > > > > > > > > ... > > > > > > > > } > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > In this example, there is a request stat collect type > > > > > > > /foo/stat-collect-type > > > > > > > > and there is an operational value (what the server/device is > > > capable > > > > > > > > of collecting -- e.g. client requests stat-set2 knowing the > > > server > > > > > > > > will change it to stat-set1 if set2 not supported) > > > > > > > > > > > > > > > > So if /foo-state is folded into /foo (because that is the > intent > > > -- > > > > > to > > > > > > > get > > > > > > > > rid of this extra stat-collect-type leaf), then how do the > > > when-stmts > > > > > > > > get applied to the operational value instead of the > configured > > > value? > > > > > > > > The same issue applies if the when-stmts are within an > > > augment-stmt > > > > > > > > > > > > > > > > WANT: > > > > > > > > > > > > > > > > augment /foo-state { > > > > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > > > > container stat-set1 { > > > > > > > > ... > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > RD Provides: > > > > > > > > > > > > > > > > augment /foo { > > > > > > > > when "stat-collect-type = 'stat-set1'"; > > > > > > > > container stat-set1 { > > > > > > > > config false; > > > > > > > > ... > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > There is no way to use when-stmt to reference the operational > > > value. > > > > > > > > This is a rather common usage of the when-stmt, so it should > not > > > > > > > > be removed if RD is used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > netmod mailing list > > > > > > > > netmod@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > > Germany > > > > > > > Fax: +49 421 200 3103 de/> > > > > > > > > > > > > > > > > --001a11c0204c659a6b05520499d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 15, 2017 at 12:03 PM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Andy B= ierman <andy@yumaworks.com>= wrote:
> On Thu, Jun 15, 2017 at 9:08 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Andy Bierman <= andy@yumaworks.com> wrote:
> > > > > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwae= lder <
> > > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > > >
> > > > > > Andy,
> > > > > >
> > > > > > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt
> > discusses
> > > > > > the XPath context. An xpath expression in a c= onfig-false container
> > > > > > will resolve to the operational state.
> > > > > >
> > > > > >
> > > > >
> > > > > So the usual method of "augment when" is= broken:
> > > > >
> > > > > WRONG: Will evaluate when-stmt against config
> > > > >
> > > > >=C2=A0 =C2=A0 augment /foo {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 when "some conditi= on";
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container stats { }
> > > > >=C2=A0 =C2=A0}
> > > >
> > > > Do you mean that stats is a config true container?=C2= =A0 And presumably in
> > > > the stats containter you have config false leafs?
> > > >
> > > >
> > > no -- stats is a config false container
> >
> > Ok.=C2=A0 Well, then this is also ok.=C2=A0 The stats container w= ill exist if
> > "some condition" is true in the operational state datas= tore.
> >
> > > > I think this works as expected.=C2=A0 In a conventional= datastore
> > > > (e.g. running), the stats container exists if "som= e condition" is true
> > > > in that datastore.
> > > >
> > >
> > >
> > > no -- in my example the desire is to augment the operational= state based
> > on
> > > the
> > > operational value of a config=3Dtrue leaf
> >
> > Yes, that will happen in both cases.
> >
> > > > In the operational state, the stats container exists if= "some
> > > > condition" is true in that the operational state d= atastore.
> > > >
> > > > >=C2=A0 Correct: Will evaluate when-stmt against ope= rational:
> > > > >
> > > > >=C2=A0 =C2=A0 augment /foo {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container stats {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config false; > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when "diffe= rent condition";
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > > >=C2=A0 =C2=A0 }
> > > >
> > > > In this case the stats container will never exist in an= y conventional
> > > > datastore, since it is config false.
> > > >
> > > > In the operational state, the stats container exists if= "different
> > > > condition" is true in that the operational state d= atastore.
> > > >
> > > > > Forcing the augmenting node to be the XPath contex= t node impacts the
> > > > > possible expressions.
> > > > > I think the RD draft should make all this clear. > > > >
> > > > This is not different from how it works today wrt candi= date vs running
> > > > for example.
> > > >
> > >
> > > no -- the datastore doesn't change based on the context = node config-stmt
> > > value
> > > for candidate and running.
> >
> > The datastore doesn't change with NMDA either - an XPath expr= ession is
> > always evaluated in a particular datastore, just like before.=C2= =A0 There
> > is no mechanism to read data from a different datastore in the XP= ath
> > expressions.
> >
> >
> >
>
> But in the first example the when-stmt is evaluated in the context of = /foo
> which is config=3Dtrue.
> Doesn't that mean the configuration values will be used?

No, the values of these nodes in the operational state datastore will
be used (these are the "applied configuration" values).

> The config=3Dfalse nodes added if the when-stmt is true are not the co= ntext
> nodes in the first form.
> Authors need to be careful to put the when-stmt in a config=3Dfalse co= ntext
> node in order
> to evaluate in the operational datastore.

No, see above.


Sec 5.1 of the RD draft does not menti= on config=3Dtrue nodes.

=C2=A0 =C2=A0augment /foo = {

=C2=A0 =C2=A0 =C2=A0 =C2=A0when "blah"= ;

=C2=A0 =C2=A0}

The XPat= ch context node for this when-stmt is /foo, which is a config=3Dtrue node.<= /div>
Sec 5.1 says=C2=A0

=C2=A0 o If the XPath expression is= defined in a substatement to a data
      node that represe=
nts system state, the accessible tree is all
      operational state in the server.  The root node has all top-level
      data nodes in all modules as children.

The augment is a =
top-level statement in this example, so this text does not apply





/martin

Andy
=C2=A0







>

>

>

> > /martin

> >

>

>

> Andy

>

>

> >

> >

> >

> >

> > >

> > >

> > >

> > > >

> > > >

> > > > /martin

> > > >

> > > >

> > > >

> > >

> > > Andy

> > >

> > >

> > > >

> > > > >

> > > > >

> > > > >

> > > > > /js

> > > > > >

> > > > >

> > > > >

> > > > > Andy

> > > > >

> > > > >

> > > > > >

> > > > > > On Wed, Jun 14, 2017 at 11:07:35AM -0700, And=
y Bierman wrote:

> > > > > > > Hi,

> > > > > > >

> > > > > > > I don't know if getting rid of /foo-=
state is such a great idea,

> > > > > > > especially wrt/ counters and other objec=
ts that are not

> > > > > > > related to intended config vs. applied c=
onfig.

> > > > > > >

> > > > > > > Q1) how does a client know the differenc=
e between an

> > auto-generated

> > > > > > > foo-state.yang and a real foo-state.yang=
?=C2=A0 Seem like a YANG

> > extension

> > > > > > > is needed to flag an auto-generated foo-=
state.yang

> > > > > > >

> > > > > > > Q2) How does XPath reference an operatio=
nal node if the

> > /foo-state

> > > > > > > subtree has been moved to the /foo confi=
g subtree?

> > > > > > >

> > > > > > > module foo {

> > > > > > >

> > > > > > >=C2=A0 =C2=A0 =C2=A0 container foo {

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
leaf stat-collect-type {

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 type enumeration {

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 enum stat-set1;

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 enum stat-set2;

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 }

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 }

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}

> > > > > > >

> > > > > > >=C2=A0 =C2=A0 =C2=A0 container foo-state =
{

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
config false;

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
leaf stat-collect-type {

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 type enumeration {

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 enum stat-set1;

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 enum stat-set2;

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 }

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 }

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 container stat-set1 {

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0when "../stat-collect-type =3D 'stat-set1'"=
;

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0...

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 }

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 container stat-set2 {

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0when "../stat-collect-type =3D 'stat-set2'"=
;

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0...

> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 }

> > > > > > >=C2=A0 =C2=A0 =C2=A0 }

> > > > > > > }

> > > > > > >

> > > > > > > In this example, there is a request stat=
 collect type

> > > > > > /foo/stat-collect-type

> > > > > > > and there is an operational value (what =
the server/device is

> > capable

> > > > > > > of collecting -- e.g. client requests st=
at-set2 knowing the

> > server

> > > > > > > will change it to stat-set1 if set2 not =
supported)

> > > > > > >

> > > > > > > So if /foo-state is folded into /foo (be=
cause that is the intent

> > --

> > > > to

> > > > > > get

> > > > > > > rid of this extra stat-collect-type leaf=
), then how do the

> > when-stmts

> > > > > > > get applied to the operational value ins=
tead of the configured

> > value?

> > > > > > > The same issue applies if the when-stmts=
 are within an

> > augment-stmt

> > > > > > >

> > > > > > > WANT:

> > > > > > >

> > > > > > >=C2=A0 augment /foo-state {

> > > > > > >=C2=A0 =C2=A0 =C2=A0when "stat-colle=
ct-type =3D 'stat-set1'";

> > > > > > >=C2=A0 =C2=A0 =C2=A0container stat-set1 {=


> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

> > > > > > >=C2=A0 =C2=A0 =C2=A0}

> > > > > > >=C2=A0 }

> > > > > > >

> > > > > > > RD Provides:

> > > > > > >

> > > > > > >=C2=A0 =C2=A0augment /foo {

> > > > > > >=C2=A0 =C2=A0 =C2=A0when "stat-colle=
ct-type =3D 'stat-set1'";

> > > > > > >=C2=A0 =C2=A0 =C2=A0container stat-set1 {=


> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;=


> > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

> > > > > > >=C2=A0 =C2=A0 =C2=A0}

> > > > > > >=C2=A0 }

> > > > > > >

> > > > > > > There is no way to use when-stmt to refe=
rence the operational

> > value.

> > > > > > > This is a rather common usage of the whe=
n-stmt, so it should not

> > > > > > > be removed if RD is used.

> > > > > > >

> > > > > > >

> > > > > > >

> > > > > > > Andy

> > > > > >

> > > > > > > ___________________________________=
____________

> > > > > > > netmod mailing list

> > > > > > > netmo=
d@ietf.org

> > > > > > > https://www.ietf.org/=
mailman/listinfo/netmod

> > > > > >

> > > > > >

> > > > > > --

> > > > > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH

> > > > > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen |

> > Germany

> > > > > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

> > > > > >

> > > >

> >

--001a11c0204c659a6b05520499d1-- From nobody Thu Jun 15 12:59:09 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DE0127869 for ; Thu, 15 Jun 2017 12:59:08 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM0AkSA7waNv for ; Thu, 15 Jun 2017 12:59:06 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8046A1201F2 for ; Thu, 15 Jun 2017 12:59:06 -0700 (PDT) Received: from localhost (h-13-81.A165.priv.bahnhof.se [155.4.13.81]) by mail.tail-f.com (Postfix) with ESMTPSA id B410E1AE03CA; Thu, 15 Jun 2017 21:59:04 +0200 (CEST) Date: Thu, 15 Jun 2017 21:59:04 +0200 (CEST) Message-Id: <20170615.215904.29472750939400252.mbj@tail-f.com> To: andy@yumaworks.com Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170615.210324.866114685910056800.mbj@tail-f.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: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 19:59:09 -0000 Andy Bierman wrote: > On Thu, Jun 15, 2017 at 12:03 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Thu, Jun 15, 2017 at 9:08 AM, Martin Bjorklund > > wrote: > > > > > > > Andy Bierman wrote: > > > > > On Thu, Jun 15, 2017 at 8:41 AM, Martin Bjorklund > > > > wrote: > > > > > > > > > > > Andy Bierman wrote: > > > > > > > On Thu, Jun 15, 2017 at 5:27 AM, Juergen Schoenwaelder < > > > > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > > > > > > > Andy, > > > > > > > > > > > > > > > > section 5.1 of draft-ietf-netmod-revised-datastores-02.txt > > > > discusses > > > > > > > > the XPath context. An xpath expression in a config-false > > container > > > > > > > > will resolve to the operational state. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So the usual method of "augment when" is broken: > > > > > > > > > > > > > > WRONG: Will evaluate when-stmt against config > > > > > > > > > > > > > > augment /foo { > > > > > > > when "some condition"; > > > > > > > container stats { } > > > > > > > } > > > > > > > > > > > > Do you mean that stats is a config true container? And presumably > > in > > > > > > the stats containter you have config false leafs? > > > > > > > > > > > > > > > > > no -- stats is a config false container > > > > > > > > Ok. Well, then this is also ok. The stats container will exist if > > > > "some condition" is true in the operational state datastore. > > > > > > > > > > I think this works as expected. In a conventional datastore > > > > > > (e.g. running), the stats container exists if "some condition" is > > true > > > > > > in that datastore. > > > > > > > > > > > > > > > > > > > > > no -- in my example the desire is to augment the operational state > > based > > > > on > > > > > the > > > > > operational value of a config=true leaf > > > > > > > > Yes, that will happen in both cases. > > > > > > > > > > In the operational state, the stats container exists if "some > > > > > > condition" is true in that the operational state datastore. > > > > > > > > > > > > > Correct: Will evaluate when-stmt against operational: > > > > > > > > > > > > > > augment /foo { > > > > > > > container stats { > > > > > > > config false; > > > > > > > when "different condition"; > > > > > > > } > > > > > > > } > > > > > > > > > > > > In this case the stats container will never exist in any > > conventional > > > > > > datastore, since it is config false. > > > > > > > > > > > > In the operational state, the stats container exists if "different > > > > > > condition" is true in that the operational state datastore. > > > > > > > > > > > > > Forcing the augmenting node to be the XPath context node impacts > > the > > > > > > > possible expressions. > > > > > > > I think the RD draft should make all this clear. > > > > > > > > > > > > This is not different from how it works today wrt candidate vs > > running > > > > > > for example. > > > > > > > > > > > > > > > > no -- the datastore doesn't change based on the context node > > config-stmt > > > > > value > > > > > for candidate and running. > > > > > > > > The datastore doesn't change with NMDA either - an XPath expression is > > > > always evaluated in a particular datastore, just like before. There > > > > is no mechanism to read data from a different datastore in the XPath > > > > expressions. > > > > > > > > > > > > > > > > > > But in the first example the when-stmt is evaluated in the context of > > /foo > > > which is config=true. > > > Doesn't that mean the configuration values will be used? > > > > No, the values of these nodes in the operational state datastore will > > be used (these are the "applied configuration" values). > > > > > The config=false nodes added if the when-stmt is true are not the context > > > nodes in the first form. > > > Authors need to be careful to put the when-stmt in a config=false context > > > node in order > > > to evaluate in the operational datastore. > > > > No, see above. > > > > > Sec 5.1 of the RD draft does not mention config=true nodes. The operational state datastore's schema is all config true and all config false nodes. > > augment /foo { > > when "blah"; > > } > > The XPatch context node for this when-stmt is /foo, which is a config=true > node. > Sec 5.1 says > > o If the XPath expression is defined in a substatement to a data > > node that represents system state, the accessible tree is all > operational state in the server. The root node has all top-level > data nodes in all modules as children. > > > The augment is a top-level statement in this example, so this text > does not apply Ok, so is your point that this text needs to mention augment as well? This text was copied (and modified) from 6.4.1 of RFC 7950, and that text doesn't mention augment either... /martin From nobody Thu Jun 15 16:06:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFB6129C3B for ; Thu, 15 Jun 2017 16:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 67DHfgIt2Eqh for ; Thu, 15 Jun 2017 16:06:43 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0102.outbound.protection.outlook.com [104.47.36.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580891286D6 for ; Thu, 15 Jun 2017 16:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Vtk9mc4QkYLAxlDp9blXOJOsIEsdGHgGla03sQgzWEo=; b=NsMCRiQQHZQg1P4+uDRdhlsII2Mn2/fix6eIMmPZgMbodL/k2Tn2SRVfeU0TFhQLdl775RlutT4LsUCHXbJWmIRa21L/0lkDoQ+xXZ/hP+hiEPN9Adl5Hlyj62lHZuurWB8A7/Qz31T8bRv6PbH487OIoNSD55mKM0QPuoeoOds= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1378.namprd05.prod.outlook.com (10.160.117.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.10; Thu, 15 Jun 2017 23:06:41 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1178.016; Thu, 15 Jun 2017 23:06:41 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt Thread-Index: AQHSnSlHwAqIi04elk+0OsiclimezKGaqssAgAyBg4CAA4RCAIAPwKaAgGxpfgA= Date: Thu, 15 Jun 2017 23:06:41 +0000 Message-ID: <9B50C714-1D1E-4CF6-B80B-32F6B280F4CC@juniper.net> References: <148939875845.17039.4017763838166134753.idtracker@ietfa.amsl.com> <4D50BFD4-0E59-4DF8-BEC9-0D9BE50F5BA6@juniper.net> <86AA35DF-0D22-45E7-A954-E766133ED49D@juniper.net> <5C204D53-ECE0-4632-A34A-9BE96B913BD0@juniper.net> In-Reply-To: <5C204D53-ECE0-4632-A34A-9BE96B913BD0@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1378; 7:uPD62LVYVVHm7R+v3RCL+w/lgWVS7q6/BkdRctkZqh5KglRUdTAgl7pjxrgBfqVIXPW1lJZe5DYdWw6pWyWGs3isj5kxNVyxv/HwOab1udsYVutJlArDsD1zn3xjiQ744/aE4G5Ml2N4tqUJZkP2dTB6TIxbxzm2VirDDCkgS94yuTnJ6eIm1iWjNhnU1Com3VMLM7HvfEErksRgdw3mtEupqIayua6wn7/yzuB1ZR2pDzdwxdl+C71M5dQYSa/IkvBM6DOaixjcJ62tgMWyhIWDEHJIxAxZaxioISIS7hpf0QgJs/W4B7PO7DIKfaPPpxX2UEl72b0I7iEfjxa8Iw== x-ms-office365-filtering-correlation-id: 9dc9baf2-01ef-45f1-de3f-08d4b4432f57 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0501MB1378; x-ms-traffictypediagnostic: BN3PR0501MB1378: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(95692535739014)(177428888720325)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1378; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1378; x-forefront-prvs: 0339F89554 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39850400002)(39860400002)(39450400003)(39840400002)(377454003)(377424004)(24454002)(76104003)(45074003)(14454004)(478600001)(50986999)(6506006)(54356999)(4001350100001)(3846002)(76176999)(2501003)(606005)(2351001)(7736002)(77096006)(6436002)(93886004)(230783001)(53936002)(14971765001)(122556002)(66066001)(6116002)(229853002)(102836003)(3280700002)(3660700001)(54896002)(99286003)(8676002)(33656002)(1730700003)(8936002)(2900100001)(81166006)(38730400002)(966005)(2906002)(10710500007)(110136004)(53386004)(5640700003)(2420400007)(6916009)(36756003)(6306002)(15650500001)(2950100002)(236005)(6512007)(5660300001)(7110500001)(25786009)(7906003)(189998001)(53546009)(86362001)(6486002)(82746002)(83716003)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1378; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9B50C7141D1E4CF6B80B32F6B280F4CCjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2017 23:06:41.5084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1378 Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 23:06:48 -0000 --_000_9B50C7141D1E4CF6B80B32F6B280F4CCjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQpJIGtub3cgdGhhdCBpdCdzIGJlZW4gYSBsb25nIGRlbGF5IHNpbmNlIHRoZSBsYXN0 IHVwZGF0ZSB0byB0aGUgQUNMIGRyYWZ0LCBidXQgaGVyZSdzDQp0aGUgY3VycmVudCBzdGF0dXMs IHByZWZhY2VkIHdpdGggc29tZSBoaXN0b3J5Og0KDQogICogVGhlIExDIGZvciBkcmFmdC1pZXRm LW5ldG1vZC1hY2wtbW9kZWwtMDkgZW5kZWQgb24gT2N0IDI4LCBidXQgdGhlbiB3YXMNCiAgICAg ZXh0ZW5kZWQgdG8gRGVjIDE0DQogICogZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwIHdh cyBwb3N0ZWQgTWFyIDEzLCBidXQgRGF2aWQgQmFubmlzdGVyIHN0aWxsDQogICAgIGhhZCBzb21l IGNvbmNlcm5zIChzZWUgZW1haWxzIGZyb20gTWFyY2ggMjh0aCkNCiAgKiBJbiBDaGljYWdvLCBz b21lIGZvbGtzIHN1cHBvcnRpbmcgdmFyaW91cyBBQ0wgaW1wbGVtZW50YXRpb25zIG1ldCB0byBk aXNjdXNzDQogICAgIGFuZCBjYW1lIHRvIGFncmVlIHRoYXQgdGhlIGRyYWZ0IGRpZG4ndCBtZWV0 IHNvbWUgdXNlIGNhc2VzLg0KICAqIEF0IHRoaXMgcG9pbnQsIERlYW4gc2FpZCB0aGF0IGhlIGRp ZG4ndCBoYXZlIHRoZSBiYW5kd2lkdGggdG8gbWFrZSB0aGUgY2hhbmdlcywNCiAgICAgYW5kIHNv IHRoZSBwcm92ZXJiaWFsIHBlbiB3YXMgdHJhbnNmZXJyZWQgdG8gb3RoZXJzICh0aGFua3MgTWFo ZXNoIGFuZCBTb25hbCEpDQogICogVGhlIGhvcGUgd2FzIHRoYXQgc2ltcGxlIGZpeGVzIGNvdWxk IGJlIG1hZGUgYW5kIGFuIHVwZGF0ZWQgZHJhZnQgcHVzaGVkIG91dA0KICAgICBzaG9ydGx5IChu ZXZlciB3b3JrcyBvdXQgdGhlIHdheSB3ZSBob3BlISkNCiAgKiBUaGVyZSB3ZXJlIDQtNSBjYWxs cyAoYW5kIHNvbWUgUFRPcykgd2hpY2ggaGF2ZSB0YWtlbiB1cCB0aGUgdGltZSB1bnRpbCBub3cu DQogICogRGF2aWQgQi4gam9pbmVkIGEgY2FsbCBlYXJsaWVyIHRoaXMgd2VlayBhbmQgc3RhdGVk IHRoYXQgdGhlIG5ldyBtb2RlbCBhZGRyZXNzZXMNCiAgICAgaGlzIGNvbmNlcm5zIChhbGJlaXQg d2l0aCBhIGNvdXBsZSB0d2Vha3MgdGhhdCB3ZXJlIGFncmVlZCB0bykNCiAgKiBBIGRyYWZ0LWll dGYtbmV0bW9kLWFjbC1tb2RlbC0xMSBpcyBleHBlY3RlZCB0byBiZSBwb3N0ZWQgZW1pbmVudGx5 DQogICogR2l2ZW4gdGhlIHN1YnN0YW50aXZlIGNoYW5nZXMgbWFkZSwgdGhpcyBkcmFmdCB3aWxs IG5lZWQgdG8gZ28gYmFjayB0byB0aGUgV0cNCiAgICAgZm9yIGEgZnVsbCByZXZpZXcgb2YgY2hh bmdlcyBhbmQgdGhlbiwgb25jZSByZWFkeSwgaXQgd2lsbCBuZWVkIGdvIHRocm91Z2ggYW5vdGhl cg0KICAgICBJUFIgY2FsbCBhbmQgdGhlbiBhbm90aGVyIExhc3QgQ2FsbC4NCg0KVGhhbmtzLA0K S2VudCAgLy8gc2hlcGhlcmQNCg0KDQpPbiA0LzcvMTcsIDc6MzMgUE0sICJuZXRtb2Qgb24gYmVo YWxmIG9mIEtlbnQgV2F0c2VuIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v ZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yga3dhdHNlbkBqdW5pcGVyLm5ldDxtYWls dG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KDQoNCkkgcmVjZWl2ZWQgc29tZSBhZGRp dGlvbmFsIG9mZi1saXN0IGNvbW1lbnRzIHJlZ2FyZGluZyB0aGUgY29uY2VybnMgRGF2aWQNCnJh aXNlZCBiZWxvdy4gIFRoZXJlIGlzIGEgc21hbGwgZ3JvdXAgb2YgZm9sa3MgdGhhdCBhcmUgZm9y bXVsYXRpbmcgYSByZXNwb25zZS4NCkkgd2FzIGhvcGluZyB0byBzZW5kIHRoZSByZXNwb25zZSBp dHNlbGYgdG8gdGhlIGxpc3QgYnkgbm93LCBidXQgaXQncyBub3QgcmVhZHkNCnlldC4gIFNvLCBp bnN0ZWFkLCBJJ20ganVzdCBzZW5kaW5nIHRoaXMgbWVzc2FnZSB0byBsZXQgeW91IGtub3cgdGhh dCBhIHJlc3BvbnNlDQppcyBmb3J0aGNvbWluZy4NCg0KVGhhbmtzLA0KS2VudCAgLy8gc2hlcGhl cmQNCg0KDQpPbiAzLzI4LzE3LCAyOjU5IFBNLCAiRGF2aWQgQmFubmlzdGVyIiA8ZHBiQG5ldGZs aXguY29tPG1haWx0bzpkcGJAbmV0ZmxpeC5jb20+PiB3cm90ZToNCg0KSSB3b3VsZCBhZ3JlZSB0 aGF0IHRoZSBtaXggb2YgTDIgYW5kIEwzIGluIHRoZSBzYW1lIG9wZXJhdGlvbmFsIEFDTCBpcyBh IGJpdCBvdXQgb2YgdGhlIG9yZGluYXJ5LiAgSSBjb3VsZCBzZWUgd2hlcmUgYSBjb21iaW5lZCBh cHByb2FjaCBtYXkgYmUgYXBwZWFsaW5nIHRvIHNvbWUuICBBcyBhIG5ldHdvcmsgb3BlcmF0b3Ig SSBkbyBub3Qgc2VlIHRoaXMgYXMgYSBuZWdhdGl2ZS4gIEl0IHdvdWxkIGJlIG5pY2UgdG8gZ2l2 ZSB0aGUgdmVuZG9yIHRoZSBvcHRpb24gdG8gZGVmZXIgdGhlIEwyLzMgY29tYmluYXRpb24gYnV0 IGl0IGRvZXMgbm90IGxvb2sgYXR0YWluYWJsZSBpbiB0aGUgY3VycmVudCBtb2RlbC4NCg0KImF1 Z21lbnRlZCBieSBlYWNoIHZlbmRvciIgIFRoZXJlIGFyZSBtYW55IHRoaW5ncyBtaXNzaW5nIGlu IElFVEYgbW9kZWxzIGFuZCBzb21lIHRoaW5ncyB3aGljaCBhcmUgbm90IHVuZGVyIHRoZSBJRVRG IHVtYnJlbGxhLiAgSW4gdGhpcyBkaXNjdXNzaW9uIHRoZSBmaXJzdCB0aGF0IGNvbWVzIHRvIG1p bmQgaXMgYW4gODAyLnggbW9kZWwuICBJdCBpcyBnb29kIHRvIHNlZSB0aGVyZSBpcyBjdXJyZW50 bHkgYW4gSUVFRSBlZmZvcnQgdG8gZGV2ZWxvcCBvbmUuICBIb3dldmVyLCBpdCBkb2VzIG5vdCBl eGlzdCB0b2RheS4gIFRoZSB2YXJpb3VzIGV0aGVyIHR5cGVzIGFyZSBjb3ZlcmVkIGluIHNvbWUg b2YgdGhlIHZlbmRvciBtb2RlbHMgSSBoYXZlIHNlZW4uICBXZSB0YWtlIHRoZSBOZXdjbyBleGFt cGxlIGluIHRoZSBkcmFmdCB3aGljaCB0eXBlZGVmcyBhbiBlbnVtIG9mICdrbm93bi1ldGhlci10 eXBlLicgIE1lYW53aGlsZSBPbGRjbyBpcyB1c2luZyBhIHR5cGVkZWYgb2YgJ2V0aGVydHlwZS4n ICBCb3RoIE5ldyBhbmQgT2xkIGNvIGJvdGggYXVnbWVudCB0aGlzIGRyYWZ0LiBJbiB0aGlzIHNj ZW5hcmlvIHRoZSBuZXR3b3JrIG9wZXJhdG9yIGlzIHN0dWNrIHNvcnRpbmcgb3V0IHRoZSBsb2dp YyBpbiB3aGljaCB2ZW5kb3IgbW9kZWwgdG8gdXNlIGFuZCBoYXZpbmcgdG8gZGVhbCB3aXRoIHR3 byBkYXRhIHN0cnVjdHVyZXMgZm9yIHRoZSBzYW1lIGVudGl0eSAoZXRoZXItdHlwZSkuICAgVXNp bmcgbW9kZWxzIHRoaXMgd2F5IGRvZXMgbm90aGluZyB0byBzaW1wbGlmeSBuZXR3b3JrIGNvZGlu ZyBhbmQgbWFuYWdlbWVudC4gIEkgYW0gYWdhaW5zdCBhdWdtZW50YXRpb24gZnJvbSB2ZW5kb3Ig bW9kZWxzIGZvciBjb21tb24gaXRlbXMgYnV0IGl0IGlzIG9rIGZvciB2ZW5kb3IgdW5pcXVlIGl0 ZW1zLiAgRXRoZXItdHlwZSBpcyBub3QgdmVuZG9yIHVuaXF1ZS4gIEF1Z21lbnRhdGlvbiBoYXMg aXRzIHBsYWNlIGJ1dCBpdCBhcHBlYXJzIHRvIGJlIG92ZXJ1c2VkIGV2ZW4gd2l0aGluIHRoZSBj b250ZXh0IG9mIElFVEYgb25seSBtb2RlbHMuDQoNCk5vdCBzdXJlIGlmIHBvaW50aW5nIG91dCBp ZXRmLXJvdXRpbmcgd2FzIGEgZ29vZCBpZGVhLiBGaXZlIHllYXJzIGluIHRoZSBtYWtpbmcgYW5k IDQyIGF1Z21lbnRpbmcgbW9kZWxzLiA6LSkNCg0KSWYgd2UgY2FuIGdldCB0aGUgd2VsbCBrbm93 biBJRVRGIHN0YW5kYXJkaXplZCBtaXNzaW5nIGJpdHMgZnJvbSBMMywgTDQgZm9yIHY0IGFuZCB2 NiBpbnRvIHRoaXMgaXQgd291bGQgd29yayBmb3IgbWUgYnV0IEkgdGhpbmsgdGhlIElFVEYgbWF5 IGhhdmUgbWlzc2VkIHRoZSBib2F0IG9uIHRoaXMgb25lLg0KDQoNCg0KDQpPbiBTdW4sIE1hciAy NiwgMjAxNyBhdCAxOjE3IFBNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWls dG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KSEkgRGF2aWQsDQoNCkkgYmVsaWV2ZSBh biBhbmFsb2d5IHRvIHRoZSBpZXRmLXJvdXRpbmcgbW9kdWxlIGNhbiBhbmQgc2hvdWxkIGJlIG1h ZGUgaGVyZS4gIEluIGJvdGggY2FzZXMsIHRoZSBtb2R1bGUgcHJvdmlkZXMgYSBtaW5pbWFsIHNr ZWxldG9uIHRoYXQgaXMgaW50ZW5kZWQgdG8gYmUgZXh0ZW5kZWQgYnkgYXVnbWVudGF0aW9ucy4g ICBJZiBhbnl0aGluZywgSSBjb3VsZCBhcmd1ZSB0aGF0IHRoZSBhY2wgbW9kdWxlIGRvZXNuJ3Qg Z28gZmFyIGVub3VnaCwgaW4gdGhhdCB0aGVyZSBpcyBubyBmZWF0dXJlIHN0YXRlbWVudCBvbiB0 aGUgImFjZS1pcCIgYW5kICJhY2UtZXRoIiBjYXNlIHN0YXRlbWVudHMsIGFzIGlmIGl0J3MgYXNz dW1pbmcgdGhhdCBhbGwgc2VydmVycyBpbXBsZW1lbnQgTDMgYW5kIEwyIEFDTHMsIHdoaWNoIEkg ZmluZCBzdXNwaWNpb3VzLi4uDQoNCllvdSB3cml0ZSBiZWxvdyAiYXVnbWVudGVkIGJ5IGVhY2gg dmVuZG9yIiwgYnV0IEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgdGhlIGludGVudCwgc28g bXVjaCBhcyAoanVzdCBsaWtlIHdpdGggdGhlIGlldGYtcm91dGluZykgdGhhdCBmdXR1cmUgSUVU RiBtb2R1bGVzIHdpbGwgYmUgZGVmaW5lZCB0byBmbGVzaCBpdCBvdXQuICBJbiBwYXJ0aWN1bGFy LCB0aGUgZXhpc3RpbmcgImFjZS1pcCIgYW5kICJhY2UtZXRoIiBjYXNlIHN0YXRlbWVudHMgY2Fu IGJlIGF1Z21lbnRlZCwgYXMgd2VsbCBhcyBicmFuZCBuZXcgY2FzZSBzdGF0ZW1lbnRzIGFkZGVk LiAgIEkgYWdyZWUgdGhhdCwgaW4gaXRzIGN1cnJlbnQgZm9ybSwgdGhpcyBkcmFmdCBpcyBvZiBs aW1pdGVkIHVzZSwgYnV0IGtlZXAgaW4gbXkgdGhhdCB0aGUgaWV0Zi1yb3V0aW5nIG1vZHVsZSBu b3cgaGFzIDQyIG90aGVyIG1vZHVsZXMgYXVnbWVudGluZyBpdCwgc28gdGhlcmUncyBob3BlIHRo YXQgdGhlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCBtb2R1bGUgd2lsbCBzaW1pbGFybHkgYmUg Zmxlc2hlZCBvdXQgaW4gc2hvcnQgb3JkZXIuDQoNCldoYXQgZG8geW91IHRoaW5rPyAgRG8geW91 IHRoaW5rIHdlIHNob3VsZCBwdXQgZmVhdHVyZSBzdGF0ZW1lbnRzIG9uIHRoZSB0d28gY2FzZSBz dGF0ZW1lbnRzLCBvciBldmVuIG1vdmUgdGhlc2UgaW50byBvdGhlciBtb2R1bGVzIChpbiB0aGUg c2FtZSBkcmFmdCkgc28gdGhhdCB0aGVyZSBpcyBubyBzcGVjaWFsbmVzcyBpbXBhcnRlZCBvbiB0 aGVtPw0KDQpXaGF0IGFib3V0IG90aGVycz8gIEknbSBjb25jZXJuZWQgdGhhdCB3ZSBtYXkgbm90 IGhhdmUgc3VmZmljaWVudCBkb21haW4gZXhwZXJ0aXNlIGluIHRoZSBORVRNT0QgV0cgLSBzaW1p bGFyIHRvIHRoZSByb3V0aW5nLWNmZyBkcmFmdCwgdW50aWwgdGhlIHJ0Z3dnIHN0YXJ0ZWQgdG8g Zm9jdXMgb24gaXQuDQoNCktlbnQgIC8vIHNoZXBoZXJkDQoNCg0KT24gMy8xOC8xNywgOToxOCBB TSwgIkRhdmlkIEJhbm5pc3RlciIgPGRwYkBuZXRmbGl4LmNvbTxtYWlsdG86ZHBiQG5ldGZsaXgu Y29tPj4gd3JvdGU6DQoNCihzZWNvbmQgdHJ5KQ0KVGhlcmUgd2VyZSBubyBjaGFuZ2VzIHRvIHRo ZSBtb2RlbCBzbyBteSBjb25jZXJucyByZW1haW4gdGhlIHNhbWUuICBBdWdtZW50YXRpb24gaXMg bm90IGEgc2NhbGFibGUgc29sdXRpb24gd2hlbiBkZWFsaW5nIHdpdGggYSBtdXRsaS12ZW5kb3Ig b3IgaW4gc29tZSBpbnN0YW5jZXMgYSBtdWx0aS1idXNpbmVzcy11bml0IGVudmlyb25tZW50LiAg VGhlICduZXdjbycgZXhhbXBsZSBpbiB0aGUgZHJhZnQgaWxsdXN0cmF0ZXMgdGhpcyBwcm9ibGVt LiAgVGhlIElFVEYgcHJvZHVjZXMgYSAnc3RhbmRhcmQnIGZvciBhbiBBQ0wgZHJhZnQgd2hpY2gg aXMgc28gc3BhcnNlIGluIG5hdHVyZSB0aGF0IGl0IG11c3QgYmUgYXVnbWVudGVkIGJ5IGVhY2gg dmVuZG9yLiAgSW4gdGhlIGJlc3QgY2FzZSB0aGlzIGdpdmVzIG1lIGEgdW5pcXVlIG1vZGVsIHBl ciB2ZW5kb3IgYmVjYXVzZSB3ZSBrbm93IHRoZSB2ZW5kb3JzIGFyZSBub3QgZ29pbmcgdG8gZ2V0 IHRvZ2V0aGVyIHRvIGRlZmluZSB0aGUgbWlzc2luZyBwaWVjZXMuICBUaGUgdmVuZG9ycyB3aWxs IHVzZSBhIHZhcmlldHkgb2YgbWVjaGFuaXNtcyB0byBjb21wbGV0ZSB0aGUgbW9kZWwgZnJvbSB1 c2luZyBhIHNjcmlwdCB0byBidWlsZCB0aGVpciBtb2RlbHMgZnJvbSBzb3VyY2UgY29kZSwgaGFu ZGxpbmcgdGhlIG1pc3NpbmcgcGllY2VzIGFzIGFyYml0cmFyeSBjb2RlIChhbnl4bWwpLCBvciBl dmVyeXRoaW5nIGFzIGEgc3RyaW5nLiAgVGhlbiB0aGVyZSBpcyB0aGUgd29yc2UgY2FzZSB3aGVy ZSBhIHZlbmRvciBoYXMgbm8gaW50ZXJuYWwgc3RhbmRhcmRpemF0aW9uICh5b3Uga25vdyB3aG8g eW91IGFyZSkgYW5kIHRoZWlyIG93biBwcm9kdWN0IGxpbmVzIHdpbGwgbm90IGFsaWduIGludG8g YSBjb21tb24gbW9kZWwuICBUaGUgb2JqZWN0IGhlcmUsIGZvciBtZSwgaXMgdG8gZ2V0IHRvIGEg c2luZ2xlIG1vZGVsIGZvciBhbGwgdmVuZG9ycyBiYXJyaW5nIGEgdW5pcXVlIGZlYXR1cmUgdGhh dCBiZWxvbmdzIHRvIG9uZSB2ZW5kb3IgaW4gd2hpY2ggY2FzZSBhdWdtZW50YXRpb24gaXMgYWNj ZXB0YWJsZS4NCg0KQ291bGQgeW91IGFkZCB0byB0aGlzIGluIHRoZSBmdXR1cmUgYW5kIHJldiB1 cCB0aGUgUkZDPyAgU3VyZS4gIEhvd2V2ZXIsIEkgYW0gbm90IHN1cmUgd2hhdCB2YWx1ZSB0aGF0 IGJyaW5ncyB0byB0aGUgY29tbXVuaXR5LiAgSW4gaXRzIGN1cnJlbnQgZm9ybSBJIHdvdWxkIG5v dCBhc2sgYW55IG9mIG15IHZlbmRvcnMgdG8gaW1wbGVtZW50IHRoaXMgZHJhZnQuICBJbnN0ZWFk IEkgd291bGQgcHVzaCB0aGVtIHRvd2FyZHMgdGhlIE9wZW5Db25maWcgQUNMIG1vZGVsLg0KDQpP biBUdWUsIE1hciAxNCwgMjAxNyBhdCA5OjEyIFBNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5p cGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KSGkgRGF2aWQsDQoN CkNhbiB5b3UgcGxlYXNlIGNvbmZpcm0gdGhhdCB0aGUgYWRkaXRpb25hbCBleGFtcGxlcyBhZGRy ZXNzIHlvdXIgY29uY2Vybj8gIEFuZCwgaWYgbm90LCBwbGVhc2UNCmV4cGxhaW4gaWYgdGhlcmUg aXMgYW55IHJlYXNvbiB3aHkgd2hhdCB5b3UncmUgbG9va2luZyBmb3IgY291bGRuJ3QgYmUgYWRk ZWQgb3IgYXVnbWVudGVkIGluDQppbiB0aGUgZnV0dXJlLg0KDQpUaGFua3MsDQpLZW50IC8vIHNo ZXBoZXJkDQoNCk9uIDMvMTMvMTcsIDU6NTcgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIERlYW4g Qm9nZGFub3ZpYyIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGl2YW5kZWFuQGdtYWlsLmNvbTxtYWlsdG86aXZhbmRl YW5AZ21haWwuY29tPj4gd3JvdGU6DQoNCkhlcmUgaXMgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBB Q0wgZHJhZnQuIFNpbmNlIERlY2VtYmVyIGFuZCBzb21lIGFkZGl0aW9uYWwgY29tbWVudHMgYWJv dXQgdGhlIEFDTCBtb2RlbCwgSSBzcG9rZSB3aXRoIG1hbnkgb3BlcmF0b3JzIGFuZCBob3cgdGhl eSB1c2UgQUNMcy4gSSBoYXZlIGFsc28gcmVjZWl2ZWQgbG90IG9mIGRldGFpbGVkIEFDTCBjb25m aWd1cmF0aW9ucy4gSW4gbW9zdCBjYXNlcywgdGhlIG1vZGVsIGlzIGVhc2lseSBhZGFwdGVkIHRv IHRoZSBjdXJyZW50IHVzZSBjYXNlcyBpbiBvcGVyYXRpb25zLiBCdXQgdG8gYW5zd2VyIHRoZSBj b21tZW50cywgdGhlIGF1dGhvcnMgaGF2ZSBhZGRlZCBhIGRldGFpbGVkIGV4YW1wbGUgaW4gdGhl IGFkZGVuZHVtIHNlY3Rpb24gaG93IHRoZSBtb2RlbCBjYW4gYmUgZXh0ZW5kZWQgYW5kIGhvdyB0 aGlzIG1vZGVsIGNhbiBiZSB1c2VkLg0KDQpDaGVlcnMsDQoNCkRlYW4NCg0KDQpCZWdpbiBmb3J3 YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMC50eHQNCkRhdGU6IE1hcmNoIDEz LCAyMDE3IGF0IDEwOjUyOjM4IEFNIEdNVCsxDQpUbzogPG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc8 bWFpbHRvOm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc+PiwgIktpcmFuIEtvdXNoaWsiIDxra291c2hp a0BjaXNjby5jb208bWFpbHRvOmtrb3VzaGlrQGNpc2NvLmNvbT4+LCAiTGlzYSBIdWFuZyIgPGx5 aWh1YW5nMTZAZ21haWwuY29tPG1haWx0bzpseWlodWFuZzE2QGdtYWlsLmNvbT4+LCAiRGVhbiBC b2dkYW5vdmljIiA8aXZhbmRlYW5AZ21haWwuY29tPG1haWx0bzppdmFuZGVhbkBnbWFpbC5jb20+ PiwgIkRhbmEgQmxhaXIiIDxkYmxhaXJAY2lzY28uY29tPG1haWx0bzpkYmxhaXJAY2lzY28uY29t Pj4sICJLaXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhIiA8a2tvdXNoaWtAY2lzY28uY29tPG1haWx0 bzpra291c2hpa0BjaXNjby5jb20+Pg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1p ZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IERlYW4gQm9nZGFub3ZpYyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5 Lg0KDQpOYW1lOiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwNClJldmlzaW9uOiAxMA0KVGl0 bGU6IE5ldHdvcmsgQWNjZXNzIENvbnRyb2wgTGlzdCAoQUNMKSBZQU5HIERhdGEgTW9kZWwNCkRv Y3VtZW50IGRhdGU6IDIwMTctMDMtMTMNCkdyb3VwOiBuZXRtb2QNClBhZ2VzOiAzMg0KVVJMOiAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRm LW5ldG1vZC1hY2wtbW9kZWwtMTAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1hY2wt bW9kZWwtMTANCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwDQoNCkFic3RyYWN0Og0KICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhIGRhdGEgbW9kZWwgb2YgQWNjZXNzIENvbnRyb2wgTGlzdCAoQUNM KQ0KICBiYXNpYyBidWlsZGluZyBibG9ja3MuDQoNCiAgRWRpdG9yaWFsIE5vdGUgKFRvIGJlIHJl bW92ZWQgYnkgUkZDIEVkaXRvcikNCg0KICBUaGlzIGRyYWZ0IGNvbnRhaW5zIG1hbnkgcGxhY2Vo b2xkZXIgdmFsdWVzIHRoYXQgbmVlZCB0byBiZSByZXBsYWNlZA0KICB3aXRoIGZpbmFsaXplZCB2 YWx1ZXMgYXQgdGhlIHRpbWUgb2YgcHVibGljYXRpb24uICBUaGlzIG5vdGUNCiAgc3VtbWFyaXpl cyBhbGwgb2YgdGhlIHN1YnN0aXR1dGlvbnMgdGhhdCBhcmUgbmVlZGVkLiAgUGxlYXNlIG5vdGUN CiAgdGhhdCBubyBvdGhlciBSRkMgRWRpdG9yIGluc3RydWN0aW9ucyBhcmUgc3BlY2lmaWVkIGFu eXdoZXJlIGVsc2UgaW4NCiAgdGhpcyBkb2N1bWVudC4NCg0KICBBcnR3b3JrIGluIHRoaXMgZG9j dW1lbnQgY29udGFpbnMgc2hvcnRoYW5kIHJlZmVyZW5jZXMgdG8gZHJhZnRzIGluDQogIHByb2dy ZXNzLiAgUGxlYXNlIGFwcGx5IHRoZSBmb2xsb3dpbmcgcmVwbGFjZW1lbnRzDQoNCiAgbyAgIlhY WFgiIC0tPiB0aGUgYXNzaWduZWQgUkZDIHZhbHVlIGZvciB0aGlzIGRyYWZ0Lg0KDQogIG8gIFJl dmlzaW9uIGRhdGUgaW4gbW9kZWwgKE9jdCAxMiwgMjAxNikgbmVlZHMgdG8gZ2V0IHVwZGF0ZWQg d2l0aA0KICAgICB0aGUgZGF0ZSB0aGUgZHJhZnQgZ2V0cyBhcHByb3ZlZC4gIFRoZSBkYXRlIGFs c28gbmVlZHMgdG8gZ2V0DQogICAgIHJlZmxlY3RlZCBvbiB0aGUgbGluZSB3aXRoIDxDT0RFIEJF R0lOUz4uDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rv b2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg== --_000_9B50C7141D1E4CF6B80B32F6B280F4CCjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <9C9E8E47DD0C254F9108A1A85334A670@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIgMCA1IDMgMCAwIDAgMiAwIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLm00NDM3MDk2NzA3Mzk3NzM5NDhtLTU5MjMxNTUx NjAyMzY5OTM2NTZhcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTptXzQ0MzcwOTY3MDcz OTc3Mzk0OG0tNTkyMzE1NTE2MDIzNjk5MzY1NmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxT dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJ dGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0KCXZlcnRp Y2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJZm9udC12YXJpYW50Om5v cm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9u ZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2VsaW5l O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHls ZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSI+QWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSI+SSBrbm93IHRoYXQgaXQncyBiZWVuIGEgbG9uZyBkZWxheSBzaW5jZSB0aGUgbGFz dCB1cGRhdGUgdG8gdGhlIEFDTCBkcmFmdCwgYnV0IGhlcmUncw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmkiPnRoZSBjdXJyZW50IHN0YXR1cywgcHJlZmFjZWQgd2l0aCBzb21lIGhpc3Rvcnk6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgKiBUaGUg TEMgZm9yIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0wOSBlbmRlZCBvbiBPY3QgMjgsIGJ1 dCB0aGVuIHdhcw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO2V4dGVuZGVkIHRvIERlYyAxNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgKiBk cmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTAgd2FzIHBvc3RlZCBNYXIgMTMsIGJ1dCBEYXZp ZCBCYW5uaXN0ZXIgc3RpbGwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtoYWQgc29tZSBjb25jZXJucyAoc2VlIGVtYWlscyBmcm9tIE1hcmNoIDI4 dGgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyAqIEluIENoaWNhZ28sIHNvbWUgZm9sa3Mg c3VwcG9ydGluZyB2YXJpb3VzIEFDTCBpbXBsZW1lbnRhdGlvbnMgbWV0IHRvIGRpc2N1c3MNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthbmQgY2Ft ZSB0byBhZ3JlZSB0aGF0IHRoZSBkcmFmdCBkaWRuJ3QgbWVldCBzb21lIHVzZSBjYXNlcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7ICogQXQgdGhpcyBwb2ludCwgRGVhbiBzYWlkIHRoYXQg aGUgZGlkbid0IGhhdmUgdGhlIGJhbmR3aWR0aCB0byBtYWtlIHRoZSBjaGFuZ2VzLA0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FuZCBzbyB0aGUg cHJvdmVyYmlhbCBwZW4gd2FzIHRyYW5zZmVycmVkIHRvIG90aGVycyAodGhhbmtzIE1haGVzaCBh bmQgU29uYWwhKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgKiBUaGUgaG9wZSB3YXMgdGhh dCBzaW1wbGUgZml4ZXMgY291bGQgYmUgbWFkZSBhbmQgYW4gdXBkYXRlZCBkcmFmdCBwdXNoZWQg b3V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtzaG9ydGx5 IChuZXZlciB3b3JrcyBvdXQgdGhlIHdheSB3ZSBob3BlISk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+ Jm5ic3A7ICogVGhlcmUgd2VyZSA0LTUgY2FsbHMgKGFuZCBzb21lIFBUT3MpIHdoaWNoIGhhdmUg dGFrZW4gdXAgdGhlIHRpbWUgdW50aWwgbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsg KiBEYXZpZCBCLiBqb2luZWQgYSBjYWxsIGVhcmxpZXIgdGhpcyB3ZWVrIGFuZCBzdGF0ZWQgdGhh dCB0aGUgbmV3IG1vZGVsIGFkZHJlc3NlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaGlzIGNvbmNlcm5zIChhbGJlaXQgd2l0aCBhIGNvdXBsZSB0d2Vha3Mg dGhhdCB3ZXJlIGFncmVlZCB0byk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7ICogQSBkcmFm dC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTEgaXMgZXhwZWN0ZWQgdG8gYmUgcG9zdGVkIGVtaW5l bnRseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgKiBHaXZlbiB0aGUgc3Vic3RhbnRpdmUg Y2hhbmdlcyBtYWRlLCB0aGlzIGRyYWZ0IHdpbGwgbmVlZCB0byBnbyBiYWNrIHRvIHRoZSBXRw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2ZvciBh IGZ1bGwgcmV2aWV3IG9mIGNoYW5nZXMgYW5kIHRoZW4sIG9uY2UgcmVhZHksIGl0IHdpbGwgbmVl ZCBnbyB0aHJvdWdoIGFub3RoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IElQUiBjYWxsIGFuZCB0aGVuIGFub3RoZXIgTGFzdCBDYWxsLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzLCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5LZW50Jm5ic3A7 IC8vIHNoZXBoZXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDQvNy8xNywgNzozMyBQTSwgJnF1b3Q7bmV0bW9kIG9uIGJlaGFsZiBv ZiBLZW50IFdhdHNlbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGll dGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVm PSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpIj5JIHJlY2VpdmVkIHNvbWUgYWRkaXRpb25hbCBvZmYtbGlzdCBjb21tZW50cyBy ZWdhcmRpbmcgdGhlIGNvbmNlcm5zIERhdmlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPnJhaXNlZCBi ZWxvdy4mbmJzcDsgVGhlcmUgaXMgYSBzbWFsbCBncm91cCBvZiBmb2xrcyB0aGF0IGFyZSBmb3Jt dWxhdGluZyBhIHJlc3BvbnNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5JIHdhcyBob3BpbmcgdG8g c2VuZCB0aGUgcmVzcG9uc2UgaXRzZWxmIHRvIHRoZSBsaXN0IGJ5IG5vdywgYnV0IGl0J3Mgbm90 IHJlYWR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPnlldC4mbmJzcDsgU28sIGluc3RlYWQsIEknbSBq dXN0IHNlbmRpbmcgdGhpcyBtZXNzYWdlIHRvIGxldCB5b3Uga25vdyB0aGF0IGEgcmVzcG9uc2U8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSI+aXMgZm9ydGhjb21pbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki PktlbnQgJm5ic3A7Ly8gc2hlcGhlcmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMy8yOC8xNywgMjo1OSBQTSwgJnF1b3Q7RGF2aWQg QmFubmlzdGVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHBiQG5ldGZsaXguY29tIj5kcGJA bmV0ZmxpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGFncmVlIHRoYXQgdGhlIG1p eCBvZiBMMiBhbmQgTDMgaW4gdGhlIHNhbWUgb3BlcmF0aW9uYWwgQUNMIGlzIGEgYml0IG91dCBv ZiB0aGUgb3JkaW5hcnkuJm5ic3A7IEkgY291bGQgc2VlIHdoZXJlIGEgY29tYmluZWQgYXBwcm9h Y2ggbWF5IGJlIGFwcGVhbGluZyB0byBzb21lLiZuYnNwOyBBcyBhIG5ldHdvcmsgb3BlcmF0b3Ig SSBkbyBub3Qgc2VlIHRoaXMgYXMgYSBuZWdhdGl2ZS4mbmJzcDsgSXQgd291bGQgYmUgbmljZQ0K IHRvIGdpdmUgdGhlIHZlbmRvciB0aGUgb3B0aW9uIHRvIGRlZmVyIHRoZSBMMi8zIGNvbWJpbmF0 aW9uIGJ1dCBpdCBkb2VzIG5vdCBsb29rIGF0dGFpbmFibGUgaW4gdGhlIGN1cnJlbnQgbW9kZWwu DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O2F1 Z21lbnRlZCBieSBlYWNoIHZlbmRvciZxdW90OyAmbmJzcDtUaGVyZSBhcmUgbWFueSB0aGluZ3Mg bWlzc2luZyBpbiBJRVRGIG1vZGVscyBhbmQgc29tZSB0aGluZ3Mgd2hpY2ggYXJlIG5vdCB1bmRl ciB0aGUgSUVURiB1bWJyZWxsYS4mbmJzcDsgSW4gdGhpcyBkaXNjdXNzaW9uIHRoZSBmaXJzdCB0 aGF0IGNvbWVzIHRvIG1pbmQgaXMgYW4gODAyLnggbW9kZWwuJm5ic3A7IEl0IGlzIGdvb2QgdG8g c2VlIHRoZXJlIGlzIGN1cnJlbnRseSBhbg0KIElFRUUgZWZmb3J0IHRvIGRldmVsb3Agb25lLiZu YnNwOyBIb3dldmVyLCBpdCBkb2VzIG5vdCBleGlzdCB0b2RheS4mbmJzcDsgVGhlIHZhcmlvdXMg ZXRoZXIgdHlwZXMgYXJlIGNvdmVyZWQgaW4gc29tZSBvZiB0aGUgdmVuZG9yIG1vZGVscyBJIGhh dmUgc2Vlbi4mbmJzcDsgV2UgdGFrZSB0aGUgTmV3Y28gZXhhbXBsZSBpbiB0aGUgZHJhZnQgd2hp Y2ggdHlwZWRlZnMgYW4gZW51bSBvZiAna25vd24tZXRoZXItdHlwZS4nICZuYnNwO01lYW53aGls ZSBPbGRjbyBpcyB1c2luZyBhDQogdHlwZWRlZiBvZiAnZXRoZXJ0eXBlLicgJm5ic3A7Qm90aCBO ZXcgYW5kIE9sZCBjbyBib3RoIGF1Z21lbnQgdGhpcyBkcmFmdC4gSW4gdGhpcyBzY2VuYXJpbyB0 aGUgbmV0d29yayBvcGVyYXRvciBpcyBzdHVjayBzb3J0aW5nIG91dCB0aGUgbG9naWMgaW4gd2hp Y2ggdmVuZG9yIG1vZGVsIHRvIHVzZSBhbmQgaGF2aW5nIHRvIGRlYWwgd2l0aCB0d28gZGF0YSBz dHJ1Y3R1cmVzIGZvciB0aGUgc2FtZSBlbnRpdHkgKGV0aGVyLXR5cGUpLiAmbmJzcDsgVXNpbmcg bW9kZWxzDQogdGhpcyB3YXkgZG9lcyBub3RoaW5nIHRvIHNpbXBsaWZ5IG5ldHdvcmsgY29kaW5n IGFuZCBtYW5hZ2VtZW50LiZuYnNwOyBJIGFtIGFnYWluc3QgYXVnbWVudGF0aW9uIGZyb20gdmVu ZG9yIG1vZGVscyBmb3IgY29tbW9uIGl0ZW1zIGJ1dCBpdCBpcyBvayBmb3IgdmVuZG9yIHVuaXF1 ZSBpdGVtcy4mbmJzcDsgRXRoZXItdHlwZSBpcyBub3QgdmVuZG9yIHVuaXF1ZS4mbmJzcDsgQXVn bWVudGF0aW9uIGhhcyBpdHMgcGxhY2UgYnV0IGl0IGFwcGVhcnMgdG8gYmUgb3ZlcnVzZWQNCiBl dmVuIHdpdGhpbiB0aGUgY29udGV4dCBvZiBJRVRGIG9ubHkgbW9kZWxzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Qgc3VyZSBpZiBwb2lu dGluZyBvdXQgaWV0Zi1yb3V0aW5nIHdhcyBhIGdvb2QgaWRlYS4gRml2ZSB5ZWFycyBpbiB0aGUg bWFraW5nIGFuZCA0MiBhdWdtZW50aW5nIG1vZGVscy4gOi0pPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIGNhbiBnZXQgdGhlIHdlbGwg a25vd24gSUVURiBzdGFuZGFyZGl6ZWQgbWlzc2luZyBiaXRzIGZyb20gTDMsIEw0IGZvciB2NCBh bmQgdjYgaW50byB0aGlzIGl0IHdvdWxkIHdvcmsgZm9yIG1lIGJ1dCBJIHRoaW5rIHRoZSBJRVRG IG1heSBoYXZlIG1pc3NlZCB0aGUgYm9hdCBvbiB0aGlzIG9uZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBNYXIgMjYs IDIwMTcgYXQgMToxNyBQTSwgS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0c2Vu QGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhJIERhdmlkLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkkgYmVsaWV2ZSBhbiBhbmFsb2d5 IHRvIHRoZSBpZXRmLXJvdXRpbmcgbW9kdWxlIGNhbiBhbmQgc2hvdWxkIGJlIG1hZGUgaGVyZS4m bmJzcDsgSW4gYm90aCBjYXNlcywgdGhlIG1vZHVsZSBwcm92aWRlcyBhIG1pbmltYWwgc2tlbGV0 b24gdGhhdCBpcyBpbnRlbmRlZA0KIHRvIGJlIGV4dGVuZGVkIGJ5IGF1Z21lbnRhdGlvbnMuJm5i c3A7ICZuYnNwO0lmIGFueXRoaW5nLCBJIGNvdWxkIGFyZ3VlIHRoYXQgdGhlIGFjbCBtb2R1bGUg ZG9lc24ndCBnbyBmYXIgZW5vdWdoLCBpbiB0aGF0IHRoZXJlIGlzIG5vIGZlYXR1cmUgc3RhdGVt ZW50IG9uIHRoZSAmcXVvdDthY2UtaXAmcXVvdDsgYW5kICZxdW90O2FjZS1ldGgmcXVvdDsgY2Fz ZSBzdGF0ZW1lbnRzLCBhcyBpZiBpdCdzIGFzc3VtaW5nIHRoYXQgYWxsIHNlcnZlcnMgaW1wbGVt ZW50IEwzIGFuZCBMMiBBQ0xzLCB3aGljaA0KIEkgZmluZCBzdXNwaWNpb3VzLi4uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+WW91IHdyaXRlIGJl bG93ICZxdW90O2F1Z21lbnRlZCBieSBlYWNoIHZlbmRvciZxdW90OywgYnV0IEkgZG9uJ3QgYmVs aWV2ZSB0aGF0IHRoaXMgaXMgdGhlIGludGVudCwgc28gbXVjaCBhcyAoanVzdCBsaWtlIHdpdGgg dGhlIGlldGYtcm91dGluZykgdGhhdCBmdXR1cmUNCiBJRVRGIG1vZHVsZXMgd2lsbCBiZSBkZWZp bmVkIHRvIGZsZXNoIGl0IG91dC4mbmJzcDsgSW4gcGFydGljdWxhciwgdGhlIGV4aXN0aW5nICZx dW90O2FjZS1pcCZxdW90OyBhbmQgJnF1b3Q7YWNlLWV0aCZxdW90OyBjYXNlIHN0YXRlbWVudHMg Y2FuIGJlIGF1Z21lbnRlZCwgYXMgd2VsbCBhcyBicmFuZCBuZXcgY2FzZSBzdGF0ZW1lbnRzIGFk ZGVkLiZuYnNwOyZuYnNwOyBJIGFncmVlIHRoYXQsIGluIGl0cyBjdXJyZW50IGZvcm0sIHRoaXMg ZHJhZnQgaXMgb2YgbGltaXRlZCB1c2UsIGJ1dCBrZWVwIGluIG15DQogdGhhdCB0aGUgaWV0Zi1y b3V0aW5nIG1vZHVsZSBub3cgaGFzIDQyIG90aGVyIG1vZHVsZXMgYXVnbWVudGluZyBpdCwgc28g dGhlcmUncyBob3BlIHRoYXQgdGhlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCBtb2R1bGUgd2ls bCBzaW1pbGFybHkgYmUgZmxlc2hlZCBvdXQgaW4gc2hvcnQgb3JkZXIuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+V2hhdCBkbyB5b3UgdGhpbms/ Jm5ic3A7IERvIHlvdSB0aGluayB3ZSBzaG91bGQgcHV0IGZlYXR1cmUgc3RhdGVtZW50cyBvbiB0 aGUgdHdvIGNhc2Ugc3RhdGVtZW50cywgb3IgZXZlbiBtb3ZlIHRoZXNlIGludG8gb3RoZXIgbW9k dWxlcyAoaW4gdGhlIHNhbWUNCiBkcmFmdCkgc28gdGhhdCB0aGVyZSBpcyBubyBzcGVjaWFsbmVz cyBpbXBhcnRlZCBvbiB0aGVtPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmkiPldoYXQgYWJvdXQgb3RoZXJzPyZuYnNwOyBJJ20gY29uY2VybmVkIHRo YXQgd2UgbWF5IG5vdCBoYXZlIHN1ZmZpY2llbnQgZG9tYWluIGV4cGVydGlzZSBpbiB0aGUgTkVU TU9EIFdHIC0gc2ltaWxhciB0byB0aGUgcm91dGluZy1jZmcgZHJhZnQsIHVudGlsIHRoZQ0KIHJ0 Z3dnIHN0YXJ0ZWQgdG8gZm9jdXMgb24gaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+S2VudCZuYnNwOyAvLyBzaGVwaGVyZDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIDMvMTgvMTcsIDk6MTggQU0sICZxdW90O0RhdmlkIEJhbm5pc3RlciZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRwYkBuZXRmbGl4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRw YkBuZXRmbGl4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdCI+KHNlY29uZCB0cnkpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQi PlRoZXJlIHdlcmUgbm8gY2hhbmdlcyB0byB0aGUgbW9kZWwgc28gbXkgY29uY2VybnMgcmVtYWlu IHRoZSBzYW1lLiZuYnNwOyBBdWdtZW50YXRpb24gaXMgbm90IGEgc2NhbGFibGUgc29sdXRpb24g d2hlbiBkZWFsaW5nIHdpdGggYSBtdXRsaS12ZW5kb3Igb3IgaW4NCiBzb21lIGluc3RhbmNlcyBh IG11bHRpLWJ1c2luZXNzLXVuaXQgZW52aXJvbm1lbnQuJm5ic3A7IFRoZSAnbmV3Y28nIGV4YW1w bGUgaW4gdGhlIGRyYWZ0IGlsbHVzdHJhdGVzIHRoaXMgcHJvYmxlbS4mbmJzcDsgVGhlIElFVEYg cHJvZHVjZXMgYSAnc3RhbmRhcmQnIGZvciBhbiBBQ0wgZHJhZnQgd2hpY2ggaXMgc28gc3BhcnNl IGluIG5hdHVyZSB0aGF0IGl0IG11c3QgYmUgYXVnbWVudGVkIGJ5IGVhY2ggdmVuZG9yLiZuYnNw OyBJbiB0aGUgYmVzdCBjYXNlIHRoaXMgZ2l2ZXMNCiBtZSBhIHVuaXF1ZSBtb2RlbCBwZXIgdmVu ZG9yIGJlY2F1c2Ugd2Uga25vdyB0aGUgdmVuZG9ycyBhcmUgbm90IGdvaW5nIHRvIGdldCB0b2dl dGhlciB0byBkZWZpbmUgdGhlIG1pc3NpbmcgcGllY2VzLiZuYnNwOyBUaGUgdmVuZG9ycyB3aWxs IHVzZSBhIHZhcmlldHkgb2YgbWVjaGFuaXNtcyB0byBjb21wbGV0ZSB0aGUgbW9kZWwgZnJvbSB1 c2luZyBhIHNjcmlwdCB0byBidWlsZCB0aGVpciBtb2RlbHMgZnJvbSBzb3VyY2UgY29kZSwgaGFu ZGxpbmcgdGhlDQogbWlzc2luZyBwaWVjZXMgYXMgYXJiaXRyYXJ5IGNvZGUgKGFueXhtbCksIG9y IGV2ZXJ5dGhpbmcgYXMgYSBzdHJpbmcuJm5ic3A7IFRoZW4gdGhlcmUgaXMgdGhlIHdvcnNlIGNh c2Ugd2hlcmUgYSB2ZW5kb3IgaGFzIG5vIGludGVybmFsIHN0YW5kYXJkaXphdGlvbiAoeW91IGtu b3cgd2hvIHlvdSBhcmUpIGFuZCB0aGVpciBvd24gcHJvZHVjdCBsaW5lcyB3aWxsIG5vdCBhbGln biBpbnRvIGEgY29tbW9uIG1vZGVsLiZuYnNwOyBUaGUgb2JqZWN0IGhlcmUsIGZvcg0KIG1lLCBp cyB0byBnZXQgdG8gYSBzaW5nbGUgbW9kZWwgZm9yIGFsbCB2ZW5kb3JzIGJhcnJpbmcgYSB1bmlx dWUgZmVhdHVyZSB0aGF0IGJlbG9uZ3MgdG8gb25lIHZlbmRvciBpbiB3aGljaCBjYXNlIGF1Z21l bnRhdGlvbiBpcyBhY2NlcHRhYmxlLiAmbmJzcDs8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Q291bGQgeW91IGFkZCB0 byB0aGlzIGluIHRoZSBmdXR1cmUgYW5kIHJldiB1cCB0aGUgUkZDPyZuYnNwOyBTdXJlLiZuYnNw OyBIb3dldmVyLCBJIGFtIG5vdCBzdXJlIHdoYXQgdmFsdWUgdGhhdCBicmluZ3MgdG8gdGhlIGNv bW11bml0eS4mbmJzcDsgSW4gaXRzIGN1cnJlbnQgZm9ybQ0KIEkgd291bGQgbm90IGFzayBhbnkg b2YgbXkgdmVuZG9ycyB0byBpbXBsZW1lbnQgdGhpcyBkcmFmdC4mbmJzcDsgSW5zdGVhZCBJIHdv dWxkIHB1c2ggdGhlbSB0b3dhcmRzIHRoZSBPcGVuQ29uZmlnIEFDTCBtb2RlbC4gJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gVHVlLCBNYXIgMTQsIDIwMTcgYXQgOToxMiBQTSwgS2VudCBXYXRzZW4gJmx0Ozxh IGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+a3dhdHNl bkBqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIERh dmlkLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki PkNhbiB5b3UgcGxlYXNlIGNvbmZpcm0gdGhhdCB0aGUgYWRkaXRpb25hbCBleGFtcGxlcyBhZGRy ZXNzIHlvdXIgY29uY2Vybj8mbmJzcDsgQW5kLCBpZiBub3QsIHBsZWFzZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmkiPmV4cGxhaW4gaWYgdGhlcmUgaXMgYW55IHJlYXNvbiB3aHkgd2hhdCB5b3UncmUg bG9va2luZyBmb3IgY291bGRuJ3QgYmUgYWRkZWQgb3IgYXVnbWVudGVkIGluPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSI+aW4gdGhlIGZ1dHVyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+S2Vu dCAvLyBzaGVwaGVyZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIDMvMTMvMTcsIDU6NTcgQU0sICZxdW90O25ldG1vZCBvbiBiZWhhbGYgb2YgRGVhbiBC b2dkYW5vdmljJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxm IG9mDQo8YSBocmVmPSJtYWlsdG86aXZhbmRlYW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ aXZhbmRlYW5AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGVyZSBpcyB0aGUgbmV3IHZlcnNp b24gb2YgdGhlIEFDTCBkcmFmdC4gU2luY2UgRGVjZW1iZXIgYW5kIHNvbWUgYWRkaXRpb25hbCBj b21tZW50cyBhYm91dCB0aGUgQUNMIG1vZGVsLCBJIHNwb2tlIHdpdGggbWFueSBvcGVyYXRvcnMg YW5kIGhvdyB0aGV5IHVzZSBBQ0xzLiBJIGhhdmUgYWxzbyByZWNlaXZlZA0KIGxvdCBvZiBkZXRh aWxlZCBBQ0wgY29uZmlndXJhdGlvbnMuIEluIG1vc3QgY2FzZXMsIHRoZSBtb2RlbCBpcyBlYXNp bHkgYWRhcHRlZCB0byB0aGUgY3VycmVudCB1c2UgY2FzZXMgaW4gb3BlcmF0aW9ucy4gQnV0IHRv IGFuc3dlciB0aGUgY29tbWVudHMsIHRoZSBhdXRob3JzIGhhdmUgYWRkZWQgYSBkZXRhaWxlZCBl eGFtcGxlIGluIHRoZSBhZGRlbmR1bSBzZWN0aW9uIGhvdyB0aGUgbW9kZWwgY2FuIGJlIGV4dGVu ZGVkIGFuZCBob3cgdGhpcw0KIG1vZGVsIGNhbiBiZSB1c2VkLiA8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EZWFuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5Gcm9tOg0KPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPjxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwLnR4dDwvc3Bhbj48L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+RGF0 ZToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7Ij5NYXJjaCAxMywgMjAxNyBhdCAxMDo1MjozOCBBTSBHTVQmIzQzOzE8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+VG86 DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1 ZSZxdW90OyI+Jmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtY2hhaXJzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bmV0bW9kLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDtLaXJhbiBL b3VzaGlrJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2tvdXNoaWtAY2lzY28uY29tIiB0YXJn ZXQ9Il9ibGFuayI+a2tvdXNoaWtAY2lzY28uY29tPC9hPiZndDssICZxdW90O0xpc2EgSHVhbmcm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpseWlodWFuZzE2QGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmx5aWh1YW5nMTZAZ21haWwuY29tPC9hPiZndDssDQogJnF1b3Q7RGVhbiBCb2dkYW5v dmljJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aXZhbmRlYW5AZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+aXZhbmRlYW5AZ21haWwuY29tPC9hPiZndDssICZxdW90O0RhbmEgQmxhaXImcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkYmxhaXJAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZGJsYWlyQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDtLaXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNh JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2tvdXNoaWtAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+a2tvdXNoaWtAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMC50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IERlYW4gQm9nZGFub3ZpYyBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklF VEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOjxzcGFuIGNsYXNzPSJtNDQzNzA5NjcwNzM5 NzczOTQ4bS01OTIzMTU1MTYwMjM2OTkzNjU2YXBwbGUtdGFiLXNwYW4iPiA8L3NwYW4+DQpkcmFm dC1pZXRmLW5ldG1vZC1hY2wtbW9kZWw8YnI+DQpSZXZpc2lvbjo8c3BhbiBjbGFzcz0ibTQ0Mzcw OTY3MDczOTc3Mzk0OG0tNTkyMzE1NTE2MDIzNjk5MzY1NmFwcGxlLXRhYi1zcGFuIj4gPC9zcGFu Pg0KMTA8YnI+DQpUaXRsZTo8c3BhbiBjbGFzcz0ibTQ0MzcwOTY3MDczOTc3Mzk0OG0tNTkyMzE1 NTE2MDIzNjk5MzY1NmFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPg0KTmV0d29yayBBY2Nlc3MgQ29u dHJvbCBMaXN0IChBQ0wpIFlBTkcgRGF0YSBNb2RlbDxicj4NCkRvY3VtZW50IGRhdGU6PHNwYW4g Y2xhc3M9Im00NDM3MDk2NzA3Mzk3NzM5NDhtLTU5MjMxNTUxNjAyMzY5OTM2NTZhcHBsZS10YWIt c3BhbiI+DQo8L3NwYW4+MjAxNy0wMy0xMzxicj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJtNDQzNzA5 NjcwNzM5NzczOTQ4bS01OTIzMTU1MTYwMjM2OTkzNjU2YXBwbGUtdGFiLXNwYW4iPiA8L3NwYW4+ DQpuZXRtb2Q8YnI+DQpQYWdlczo8c3BhbiBjbGFzcz0ibTQ0MzcwOTY3MDczOTc3Mzk0OG0tNTky MzE1NTE2MDIzNjk5MzY1NmFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPg0KMzI8YnI+DQpVUkw6ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTAudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0x MC50eHQ8L2E+PGJyPg0KU3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLzwvYT48YnI+ DQpIdG1saXplZDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0x MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW5ldG1vZC1hY2wtbW9kZWwtMTA8L2E+PGJyPg0KRGlmZjogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTA8L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5i c3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBkYXRhIG1vZGVsIG9mIEFjY2VzcyBD b250cm9sIExpc3QgKEFDTCk8YnI+DQombmJzcDsmbmJzcDtiYXNpYyBidWlsZGluZyBibG9ja3Mu PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7RWRpdG9yaWFsIE5vdGUgKFRvIGJlIHJlbW92ZWQgYnkg UkZDIEVkaXRvcik8YnI+DQo8YnI+DQombmJzcDsmbmJzcDtUaGlzIGRyYWZ0IGNvbnRhaW5zIG1h bnkgcGxhY2Vob2xkZXIgdmFsdWVzIHRoYXQgbmVlZCB0byBiZSByZXBsYWNlZDxicj4NCiZuYnNw OyZuYnNwO3dpdGggZmluYWxpemVkIHZhbHVlcyBhdCB0aGUgdGltZSBvZiBwdWJsaWNhdGlvbi4m bmJzcDsgVGhpcyBub3RlPGJyPg0KJm5ic3A7Jm5ic3A7c3VtbWFyaXplcyBhbGwgb2YgdGhlIHN1 YnN0aXR1dGlvbnMgdGhhdCBhcmUgbmVlZGVkLiZuYnNwOyBQbGVhc2Ugbm90ZTxicj4NCiZuYnNw OyZuYnNwO3RoYXQgbm8gb3RoZXIgUkZDIEVkaXRvciBpbnN0cnVjdGlvbnMgYXJlIHNwZWNpZmll ZCBhbnl3aGVyZSBlbHNlIGluPGJyPg0KJm5ic3A7Jm5ic3A7dGhpcyBkb2N1bWVudC48YnI+DQo8 YnI+DQombmJzcDsmbmJzcDtBcnR3b3JrIGluIHRoaXMgZG9jdW1lbnQgY29udGFpbnMgc2hvcnRo YW5kIHJlZmVyZW5jZXMgdG8gZHJhZnRzIGluPGJyPg0KJm5ic3A7Jm5ic3A7cHJvZ3Jlc3MuJm5i c3A7IFBsZWFzZSBhcHBseSB0aGUgZm9sbG93aW5nIHJlcGxhY2VtZW50czxicj4NCjxicj4NCiZu YnNwOyZuYnNwO28gJm5ic3A7JnF1b3Q7WFhYWCZxdW90OyAtLSZndDsgdGhlIGFzc2lnbmVkIFJG QyB2YWx1ZSBmb3IgdGhpcyBkcmFmdC48YnI+DQo8YnI+DQombmJzcDsmbmJzcDtvICZuYnNwO1Jl dmlzaW9uIGRhdGUgaW4gbW9kZWwgKE9jdCAxMiwgMjAxNikgbmVlZHMgdG8gZ2V0IHVwZGF0ZWQg d2l0aDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBkYXRlIHRoZSBkcmFm dCBnZXRzIGFwcHJvdmVkLiZuYnNwOyBUaGUgZGF0ZSBhbHNvIG5lZWRzIHRvIGdldDxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlZmxlY3RlZCBvbiB0aGUgbGluZSB3aXRoICZs dDtDT0RFIEJFR0lOUyZndDsuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_9B50C7141D1E4CF6B80B32F6B280F4CCjunipernet_-- From nobody Fri Jun 16 02:58:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C6E1317B3; Fri, 16 Jun 2017 02:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqQmY3IpQm1g; Fri, 16 Jun 2017 02:58:47 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499EE1317B5; Fri, 16 Jun 2017 02:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=151847; q=dns/txt; s=iport; t=1497607126; x=1498816726; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=EGJ1VbktRHf2N3sCIL2X/Lq7pXV0iPN9gMQD1oCqA+w=; b=FnVbbhMaNMJdhv/MG+zbKHwZUO0oC6TlBkRbP4KDUXpuZLJ31Fj4agFm 0X54Ou7RnKUUle48tS5TVHBfTYbMyiq7mPwT2QFCouPxWHZiHx8gi42/z snqyDSwiJkytsPfit0h08jA5WxsU2te2riQPHIUwrsA/NnbZzAbUIg0u9 I=; X-Files: clbomfldgonblahj.png : 103279 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AAB9qkNZ/xbLJq1eGwEBAQMBAQEJA?= =?us-ascii?q?QEBhDqBDY4Dc5EIgl6Nb4U6ghEHASSFeAKDJxgBAgEBAQEBAQFrKIUYAQMDBWs?= =?us-ascii?q?JEBwDAQIGAQEBJgIVAQ4pCAYNBQECAQEChzeCbxCrPiqLFwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQ4PhmOCC4FsWIU1CYVTAQSdPIEbhjABfoM8iG+CXog8hnSMQYh?= =?us-ascii?q?DHzg/SzAhCBsVh1o+NgEBAQGHDiuCEgEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,346,1493683200"; d="png'150?scan'150,208,217,150";a="653641079" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2017 09:58:43 +0000 Received: from [10.55.221.38] (ams-bclaise-nitro5.cisco.com [10.55.221.38]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5G9wh4u026842; Fri, 16 Jun 2017 09:58:43 GMT References: To: NETMOD Working Group Cc: Henrik Levkowetz , YANG Doctors From: Benoit Claise X-Forwarded-Message-Id: Message-ID: <532b83f9-1d77-c901-b2d8-87a37ba43dd1@cisco.com> Date: Fri, 16 Jun 2017 11:58:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EDDF964F9B1C52A2620AFADC" Content-Language: en-US Archived-At: Subject: [netmod] YANG-related addition (New datatracker release: v6.55.0) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 09:58:50 -0000 This is a multi-part message in MIME format. --------------EDDF964F9B1C52A2620AFADC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, Great YANG-related addition to the tracker, thanks to Henrik. For the development mode tracker New datatracker release: v6.55.0 will be installed shortly. Regards, Benoit -------- Forwarded Message -------- Subject: New datatracker release: v6.55.0 Date: Fri, 16 Jun 2017 02:38:52 -0700 From: Henrik Levkowetz To: codesprints@ietf.org, iesg@ietf.org, wgchairs@ietf.org Hi, This is an automatic notification about a new datatracker release, v6.55.0, generated when running the mkrelease script. Release notes: ietfdb (6.55.0) ietf; urgency=medium **Improved Yang validation support** This release updates and expands the Yang support in the datatracker. In addition to checking yang modules in submitted drafts using pyang, it now also does a yanglint check. The yang validation results are available by clicking on the red or green yin/yang symbols which show for drafts that contain yang models. For drafts where one or more models were found at submission time, the pyang and yanglint checks are re-run once per day, to catch newly arrived models in the library directories (both rfc and draft models). Additional details, from the commit log: * Added a new yang checker, 'yanglint', to the existing Yang checker class, in addition to the existing 'pyang' checker. * Added modal overlay displays showing the yang check results every place the yin/yang symbol is shown (red or green) to indicate the presencee and result of yang checks. Added a Yang Validation: line in the document meta-information section on the document's page in the datatracker. * Added the result of the xym extaction to the yang check results, to make extration failures visible. * Added the version of the used xym, pyang, and yanglint commands to the check results. * Added an action to move successfully extracted and validated modules to the module library directories immediately on submission. * Added the xym repository as an svn:external component, rather than listing it in requirements.txt, as there has been delays of many months between essential features appearing in the repository, and an actual release of same. We may get occasional buildbot failures if broken code is pulled in from the repository, but better that than the functionality failure of severely outdated componets. * Added a new management command to re-run yang validation for active drafts for which yang modules were found at submission time, in order to pick up imported models which may have arrived in the model libraries after the draft's submission. Run daily from bin/daily. * Added a table to hold version information for external commands. The yang checker output should include the version information of the used checkers, but seems unnecessary to run each command with its --version switch every time we check a module... * Added a new management command to collect version information for external commands on demand. To be run daily from bin/daily. * Added tests to verify that xym, pyang and yanglint information is available on the submission confirmation page, and updated the yang module contained in the test document to validate under both pyang and yanglint. * Updated admin.py and resource.py files as needed. -- Henrik Levkowetz 16 Jun 2017 09:15:22 +0000 The new version is available for installation through SVN checkout, with 'svn checkout https://svn.tools.ietf.org/svn/tools/ietfdb/tags/6.55.0' For development, copy the new development version instead: 'svn copy https://svn.tools.ietf.org/svn/tools/ietfdb/tags/dev/6.55.1.dev0' Regards, Henrik (via the mkrelease script) . --------------EDDF964F9B1C52A2620AFADC Content-Type: multipart/related; boundary="------------E551C56C7D77B73F699BC083" --------------E551C56C7D77B73F699BC083 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Dear all,

Great YANG-related addition to the tracker, thanks to Henrik.

For the development mode tracker



New datatracker release: v6.55.0 will be installed shortly.

Regards, Benoit


-------- Forwarded Message --------
Subject: New datatracker release: v6.55.0
Date: Fri, 16 Jun 2017 02:38:52 -0700
From: Henrik Levkowetz <henrik@levkowetz.com>
To: codesprints@ietf.org, iesg@ietf.org, wgchairs@ietf.org 


Hi,

This is an automatic notification about a new datatracker release, 
v6.55.0, generated when running the mkrelease script.

Release notes:

ietfdb (6.55.0) ietf; urgency=medium

  **Improved Yang validation support**

  This release updates and expands the Yang support in the datatracker.  In
  addition to checking yang modules in submitted drafts using pyang, it now
  also does a yanglint check.  The yang validation results are available by
  clicking on the red or green yin/yang symbols which show for drafts that
  contain yang models.

  For drafts where one or more models were found at submission time, the pyang
  and yanglint checks are re-run once per day, to catch newly arrived models
  in the library directories (both rfc and draft models).

  Additional details, from the commit log:

  * Added a new yang checker, 'yanglint', to the existing Yang checker class,
    in addition to the existing 'pyang' checker.

  * Added modal overlay displays showing the yang check results every place
    the yin/yang symbol is shown (red or green) to indicate the presencee and
    result of yang checks.  Added a Yang Validation: line in the document
    meta-information section on the document's page in the datatracker.

  * Added the result of the xym extaction to the yang check results, to make
    extration failures visible.

  * Added the version of the used xym, pyang, and yanglint commands to the
    check results.

  * Added an action to move successfully extracted and validated modules to
    the module library directories immediately on submission.

  * Added the xym repository as an svn:external component, rather than listing
    it in requirements.txt, as there has been delays of many months between
    essential features appearing in the repository, and an actual release of
    same.  We may get occasional buildbot failures if broken code is pulled in
    from the repository, but better that than the functionality failure of
    severely outdated componets.

  * Added a new management command to re-run yang validation for active drafts
    for which yang modules were found at submission time, in order to pick up
    imported models which may have arrived in the model libraries after the
    draft's submission.  Run daily from bin/daily.

  * Added a table to hold version information for external commands.  The yang
    checker output should include the version information of the used
    checkers, but seems unnecessary to run each command with its --version
    switch every time we check a module...

  * Added a new management command to collect version information for external
    commands on demand.  To be run daily from bin/daily.

  * Added tests to verify that xym, pyang and yanglint information is
    available on the submission confirmation page, and updated the yang module
    contained in the test document to validate under both pyang and yanglint.

  * Updated admin.py and resource.py files as needed.

 -- Henrik Levkowetz <henrik@levkowetz.com>  16 Jun 2017 09:15:22 +0000

The new version is available for installation through SVN checkout, with
  'svn checkout https://svn.tools.ietf.org/svn/tools/ietfdb/tags/6.55.0'

For development, copy the new development version instead:
  'svn copy https://svn.tools.ietf.org/svn/tools/ietfdb/tags/dev/6.55.1.dev0' <YOURBRANCH>

Regards,

	Henrik
	(via the mkrelease script)

.
--------------E551C56C7D77B73F699BC083 Content-Type: image/png; name="clbomfldgonblahj.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="clbomfldgonblahj.png" iVBORw0KGgoAAAANSUhEUgAABtQAAAOGCAIAAADzp+NtAAAgAElEQVR4nOy9e2wjd2LnqT8O A+wFE7Fw7bgltd0SqQdbFN8sPkVRFEWxJYpSq9WUmi2x1XpQ7wcpUuKzbQETxAvcAI3F4A4e DA47HUx24IXvjPM5dzdo3Cwmzu7OjjuO7XjG8dq5jIOsx5dNJ+fpS6J5ZHR/1JusIosSKam7 vx98/rBYv6r61a+qSP++/av6NRSCAQghhBBCCCGEEEIIIay5DWdeAwghhBBCCCGEEEII4VNp QyE4BCGEEEIIIYQQQgghhDUX4SOEEEIIIYQQQgghhLAuNhRG/BBCCCGEEEIIIYQQQlhzET5C CCGEEEIIIYQQQgjrYkN+2A8hhBBCCCGEEEIIIYQ19/TCx2xwaHd8dG0qvBcayY2Il8kN+xMT oa3JieT4aE5qOyP+xHhoa3IiORaUKgMhhBBCCCGEEEIIITxzG/LDg6dgdmQocS20Mj21MDOz Oh1mckNBmczIUOJaaPnm9OJMZG0qvDsezJeUyQ374xOhlempxVsRajvZkeIyEEIIIYQQQggh hBDC82BDfthXb3PDfip5nI/OzkWj89HZtakbu+PB7LCfLZMJDiWuhZYj03ei0bnb0YWZmbWp cGpsJMcrkx0Rbmd2ZnUqnByn8se6HwWEEEIIIYQQQgghhLAqG/JXfXV02Jcd9ifHgivTU3ei 0bnbtynvRGfXwjeSoZHc8GD+qi874k+Mj65Mh9kCc7dvz8/OrIVvpELDqavevUDf3vDA7nhw ZXp6PjrLFYtG18OTybGR9LBvz+/OBQbqezgQQgghhBBCCCGEEELZNuQDvvqZG/anQsOxm9P8 5JGXLU6mg4FcwJccC65Oh+dKysxFoyvh6ysjjtWAcXXUHRMrMz87u3JjYmPEs+LTpvzubMBb 1yOCEEIIIYQQQgghhBDK9PjhY65igau+zIh/dzy4eCsiGiwuT0/tjV7NDg/uTIRikenSMrej M5Ebw4k5dWHp0u6cZmb62m2RMrORyaE7E92ZO5fu+JVxvy0nnT/mqMz1rBsdQgghhBBCCCGE EMJnwYZ8YKBas8OD8fHQ9sR4KjScC/hEy2SG/Ynx0c3JCapkLHJTkC1GoyvTU9sT4/Froc3J a4nx0a3r47HIND9VnJ2ZvhUeit/pXpkxLt00r81o4/PamelgdCbClIlGo7PR6cDKLf1mtGsp Yt2deXF7TJ0MUPljUZ19ifHg1vXx3bFg7qp4nSGEEEIIIYQQQgghhDW06vAxM+yPj4eWb04v RSJr4cndULA0f8wFfPFxZk7qqTCdLd5kxjZGoyvT4a2J8a2J8eXp6cWZyFp4cntibGtifClC j5GcnZmeiwTWZrSrM9q5iH9mOjQ37VmNdK1H9XdmgtHZW3O3b0ejM9OTgZVbuq05w+rcwGxk fHPenZjp2gp1bfnI3BCXP2avDu6Ggmx9dseCeYnMFEIIIYQQQgghhBBCWCsb8gGvHNN+T8bf n77qS4wHl5kYcT46uzoV3gsGcgEfU3IgO+xLhoaXp6eoMneisxs3rifGg5uT15YiN+dnZ2KR m9sToe2JseXpKXYg5Fp4Mj4+unV9fCkSid6anosEVmbMO3NXIjf8szPTt6PRmciNmxO98bmO tah1biY4eyscjYzOTfZs3e5enfNFo9G527ej0ejWvGNjWrU63JEKOHJD/fmANzvs2w2NsO+U nJ+dXZ0Kp4KB9JA34+/P+r35IVktACGEEEIIIYQQQgghrMqG/JBXjksOcslpXQl4l8PX5mam b8/evB29eXv25vyt8OpkaG+4PxNwZ/2edGBgNzSyVPKQ9Vp4cmd8dHtidDUyER8P7lwLrQhn j5mfmVkLT6aCgY2J0O3rvvUZ3c7clenJQDQ6w7zbMRqdjdya9MTnOtdmdDOTroUpbSamXIoO 8h7Evj0TCa/POfbn2jaCnelhR27YnRofXJ8eW5ibZl2KhlfCoSWPa8ll2/a4Mn6PzEaAEEII IYQQQgghhBDKtyHv98rxt77yld/6ylfM3c/PjF2JjHdHxjWUt8a7Z0LqueH2+YByaUAT83uK k8fbt6nxjyuTE4nJ3txS+9o1/wIzLpIfUN6Jzi7enFoKuFIzHWsz2kjYH43OzN0WhJjR2Ujk unst0pWLvZCJKReiobnoLf6mbkejc9HI2pyvEGu5u/TCS0sv3o29WFhuza+08WyNz77wO4p/ 8Vtf+Yqr7fKOxyWzESCEEEIIIYQQQgghhPKVGz42NDQ0NDQ49L+dnHuh1NTcpb1oy97si9sR 7ex08DYzXJE1OhNZj3r2bndsz7Tuz3UtzgxHZ0TKzIQDydnO7etdK+OuhfCE2BzZs0sTwZWQ bWO8Z2fSvhgJiwSds7PL02OJCWN8omNnsn1zSr0a6Vm9pWVdifTcGuv6b//Ff9PQ0EC+eCmO 8BFCCCGEEEIIIYQQwjrYkPf3y9HV9qKr7XKkT70XJXcWXTuLvduLvduLvfF5x/6spTCtK0xp M+Eru1NX1qOmW9Nj/GwxOju7OjewGdWu3uqev+nYmOnYnDMuRYejs1yZ2ZnpucjQelS/Pqtd muxbG7vKn3+GN0d2eHt8dC0UWBwf2hwb3poIxSLTgse3o7OrU+F4aDg55E4GyN0AuTXqiE0O 3I4Ms85NB6Ihj6dT5Wq7PG3U7g+4ZTYChBBCCCGEEEIIIYRQvg15v0eOaZ877evbC/h2xkOL VCYYjc7PzixPhxOhkZzfmx/07A24docN+7OqhWlbNBKKRm/djkZvRyOx6HBiXrMS6YmEfTOR 8Mxk72a0a3POuBANRqOzt6PR6ExkLhJYvmXcnlPPhP23I1Nr4cn4eHBzYpy3r9nYzen4eDA+ HlwJ31i4FVkLTyZHhzevj3MPekejy9PhRGg45/eyNc8EfPHx4BKznTvR2dj09M54cN/fn/b1 ZX2e/KCsFoAQQgghhBBCCCGEEFZlQ37QI9/coCcd8G1dCy3eiszPzCxPh+OhYM7fzxbY97m2 /br8nReXI+RsJBSdmZ6fGc4sta3e6r590x+duXU7Gp25dWvmhntjpnN3QRONTERnIjPTwxtR w/ac+sY16j2P3PwzmxPjSxFuX7vB4ZXp8B0maly7cT0eojPKO9HZpZvTidBwZshbVO1MYGBn LLhIb2dqZyyY81dx1BBCCJ8Fc74+CCGEEEIIIXy6Pf2uVnXhY37Qk/PTWd7mxPju6HDWL0j6 cj5P2ufa8hn3Z1TLEePtsCOz1DY3eSU6HYjORG5Ho/S81TPT0WnPaqRrf1EVHnduR7s2otqZ ad4MM9EoFTgmg4HNifGN69d2xoKJ0eHYzek70Vn+PDZr4cl4aCQRGl67cT01MpT1e3OidR7y xkPB9cmJeChYmk7WWdLfRBSh6ibrvbt67uLJNtbdRBAE0dQVO+ua5Ac9eWPraV0Y58RTvh2e PR1dKoKwGMu2v1JX+/1SV3I9tlx/c44uFf+KVOoq/2AbWwmiadBx9v/fIOUNJUE0dS0Vf66z EISqmzzz6kEIIYQQQgjP3FPrczXkfZ5qzQ16MkPedMCX9XtFlvr69gdcu8O6xFTXTrRj/WbX 7HQgOjN9Wzgn9eytG3NTnvUp5U5UFZvquT3ti87cLJr/en52Zm1yIjE6nBr2J0LDK1PhO9HZ ohlm5mdm1icndoOB/auDWX9/rmyd9wO+zJBXqky9dHSrisMWgg6/6rJHI0kQBEGQdt+pHuYT I+lvIQiCUBn7zr4mTQRBtAz5xwuTlAP+lia/48ybqK46/JcIosvBHPJ4wa9XEQRBtIbPvm5P hW6tiiCIFvGvFzp57zTXfr+2doIgiBZNfb7Wam9uoI9yqfsiQRAqozd/fSx/fSx/3WEhCIK4 OGjvY8uIaG0niJbB3rJlztQbnQRxqWep+HOThSBUOvuZVw9CCCGEEEJ4rqxr/6sh7+urh3sD jlRQl5zoXh+1LkxPzvGGK9LOzCxOBjeGDXuT6rWQfWFyTGxu6+hqeHJv2J/19yeDgdj0lMjc 1tHZ9cmJvWF/nQ6kBlraCYLJmK6PF66PLxtb6AFfV8ja785IRZ0d4eBZH3hldVQn3+84zZ0y 4azNd7aHH24jCKIjfD1UCLAf+goT/D+fSh3+S1T4xXwSGC5cd5B0HH/m1auJOgtBEG26s9l7 r1Yl+fWioy5+Qfsfy9iVi8V3bjBYuD5emBg+68avrOAn1tGlIgiVsT8/OpAbcOcG3LmBofyE 3UIQRHPXEv2J+0YbQRCtNwbcWVZSRRAtgy7eJ+fMGx0Ecalnsfhzk4UglDr7mVcPQgghhBBC WD9zshSNIOtiQ97nroc5n3vP69gdsKX8ns1roSXhnNTUzDA7oeE9X++u15bye7bHR4vK3InO xiLT8dBwxu/N+fr2AwNb7Fw3wu3EQ8MZf3+dDuTkxrQtdBoYYD4M9Q9dogLJK7E67e6StuZb rrnhNioHsRUCdd8Xp0OjIgiCaPF7zvTwja0EQZCu4JmfhVPXzoSP/A8DVCJPGs+8ejXRTBKl x3ha9vaoiBays4Ug2sLCRbErzcSlDlKk/as2pm8hiBZ/75k3dRWW/ND25gZ6b6gIgui4MTqQ G+jNcg4tGVoIgrAY6E8mOwiCUE3yy5AqgmgedPHXOl9OdhBEi2ax+HMqfLSdefUghBBCCCGE Z2hOREGPqbbdsXqFj3yzPs/WtdAib07qpZvTO6Fg1u9hy6SHBrbHRxdmbrFlYtNT8dBI1seV yQ56tq6F+HNbL0VuUunkmXdryxjuIErSQF+4kx77yKUD/Hf/tWnzPgv9arw2LbcpKq0jLvrt /D8JgiAsRuHuOkleHbQWrmBr0R5VVyy8AvSWmb1f9NvdeTvzNjSqJuyfTV38fFO8Mm30RmJX LhKCXfCrJLI1bkdNXTEftzq1ZfZP1RVLcXnxrVlK3jPIy4LLrVi3q6KdIIiOcLBMGa2FuOi3 MzVnK8avLXe+mGPkXS1Fn8SuXCTatILVSwuXnME6aPe3EERHSfjl1akIgmjnVUnySEuXMle1 sbW4JP8Te5eKaA3zr1WqVXm3nuCKEi4qvnfatKJ3Fu9SF9ZctML1sLdHRRCkXqcqOsX2LhVB kA4rSRS1v+BmLDr1/Pua2VrJzcv7ZuAaULqJJJpXUEDQjIIL9TiWZo6U2QHzYAs1PLDkx7hf qyQIZY85Y+tUCmupVJsz3t4MqSKIZp/L7ONq+rzP1pvxck4KLp8e/udKtXlR/bzoWrVysp0g mjWLxZ+bLASh1NqYP3vMhET9BQfOW2TrVBKXJ9kVeccFIYQQQgghPLdWk0XWPoJsyA+4T8G0 37s9PkqNW4xNTyWCVzP+fn6BnM+d9nt3QsNsmXhoOOvzFJXJ+Pu3xun8cSkyvRsMZPz9Od9p HMJxtdBvGDQIPqcjQqI9TP3J7+ETBEEQqit2OqBs0cSoteydVHhBOkcLgZL+P5VxsLvTu+h9 GS8XF2zqpDYY0zYTBKHqaBO8krKZWko9m9zu1/CTlGb/FcHWSCN1OOUr06JqLjo2bd5Y1J0v bp/8gDtvVhEEQXT2CHLD5k6/oK3aqAYsSXwIok2bF7abgE5rvuKK9b4qLmlj5cqYSYIgiCa/ L1SYCBWuDbNnk3SGChOhwkQo3Mk2tTs/wIR63BYEn8R0LQRBEM09yxOhwkSoMKhX8Q6Wfgac WjRhI7nN1tzSerrzA+58wO2/xLvayx0pvVRl9FJLl43N9IGQ7fRwPHaz/E96e+g7yMG1gKrp ItFuZbbTQhBN7F5iVy4SRPPQIFUH79AlgiAuh7nNEgTR7Ocvpe6s0GhhwkYSBNFpK0yEChOj hQBzj9CfhArOdvY2rL1U+GgbDncSBNHMHk5YRRCX9MsjZjp85N0dvJZsIaj8kbpKmwiiRV9y wQwxJVvoxhkfYver0tl5LS/RRNwlxzZvqODsINivlKKz30GorliO3SA5L2sva5bWYCEIosNC /Znp5+m3WAiCaDdk/IHseHCygyCI9snxYGYsmAn2p/tdabNKoVAoFBd93mBmLJgZ8wy2KBRN HQv9rnS/K91v8l1UKJp1i2PBzFgwM6BTKhSK1p50vyvd77rerlAoFEqtOzMWzIyNZPzUKjX2 ertC0axZKP7caFYolForV8kWtpJapeLF61Qx/YsKhcJspw4teL1DoVA877O60v2utFOjVCgU irbr1FqhwXpUHkIIIYQQQnhsM5JyXZ6sV8ScQLonVZOO6imFjzmfOz3k3QkNr4QnExKJIZU/ bo8F169fo5+kFt0OVWbyWmJ0OOP3nO/k0Z23X6HzDtsA/3N++MjkX3T0Q2eOHcaYnnpeW0UH lNSGOm2FETOdx9FZho1+iaGZ3V2Lv38gP8DL3aiSzg46DrDz60B38rnBmAPuvF1Dr9iiW+ZW JAiiPcz7kyTd+QHpytAJJsGEFF76YfMOc6yvj9kIE3iFBoqajspGCYJQGby86hFEh433Z3t4 gAtYqQyFeaWmMjzgzg+Y/dRmLlEZCl0HOpylV6QzFHpFNv+qo0aSIIiWnorho8roKQS4T/zN 1AXAfDLuHbpEECoqQJQTPrYM+a7SSwNXl40tzMVg9rcQRCfJrOgvTAR5+62tEuEj9TndJuWP lFnKXjOhYGHcnx+QFT6qjF56s4Gr4U6CIFqGvH66cL9ORV+67vyAVtj+AwWfXsWmY2Q7QRCk k22lgWVDCy/pEwZ8zA1FOpgdjYwUrl0taYEaSYWPpDs/biMJ5p8T7J0qgiAdV4vqRieSXEt6 hi4RRLs2P+DOG9vELhhlmHc5CZpaLHyUbCI69ORd3lR50p2n7/2OMHf2Rb4f5MiLHd3CzJHR 1q0kCKLdlOnv5f8kp/tdVEinaO6mwrvr7QqFQnWd/4tuVikUCrP9amaQ+qQ/Y2tXKJrohE7f qlA0D3r9dOFB/4K+WaFou85urUW7MNJf1//huN6uUDR3zxd/bjQrFMoeKnzUmxUKpY5ZNOjP jAWoMr4mhaKDzASYRaOkWaFQXjGm+11pZ7dSoTDbA2f+f1QQQgghhBDCahXNIqVTSHetIsiG vLf3dMwNuNN+z+6wP+Pz5Abc0mW8ewFf2t9fZlNpvzcV8GUGJbdzjqSG7xEt/j7+52ZqfCJx SRuzUflgy5BvJO/tzXt7qMBOpXfSs8cSzX5bb54t5vXHrjQRBEFc0i2P+fPe3rxBye2C3l17 ONCb9/bSeSVbso+eiYI0c3VQGb2Fkd68t5fJOtvDXLU7wuOBvLeXGcTEVJL509/XW64ytm5m qGawEOjNe23MqExnPuCls8VL2phE04XbmUxz1Jv39jJPr9M74h5m9zLxIlNS0G6GNqbmgby3 N+81MLPNePPeHougesxJ6bTU/8Iw0eEjez3wRneqrpjZMiqdjVvLdkVFtR63HW+4kyAIZdjL NG+HibdU8ElM18JeGMwG25mLwbvMvOGu/sdeWk/e51SblD9SkaWMVNTokvjERQ0J9HLXWAdB XNIts20SsJAEodKamSu5xe/hCtOrk7zN8m9qG3/XJpIQHmOg108NnKx78/Lr6affpGnoDasI 4pJueaSobj0kQagEJ507O+F2YeOwlxD338KmdlHhI3PFlm2imKa5uHnp8LE37+3Ne6hnxnuO 3Qi5fr6uXL8rKzTjcWU8roxDoyQIRbsh7XHy3e9z7vcZqPBxvs+x3+eYUCkUCuVEn2Ofcc+s VCiaB1yOvT5G6hO7Y6/PMaFUKFp65ge5pXd6mqkt7FFba+6+08dbtw5K7MVgVijaeix7fY69 voGJdoVCcXHAIixj6WpTKMzkgPha9u42hcJsrm/lIYQQQgghhNW6X06qm+Ms6vukPc4MrSvj Ke435Wi57tWx+2inFz7SfcITF2CLySx5tjLD99rDQ7zPbfRwSJWe6oSX0hEe9eaHSZIK8ly9 YSWTrw0xGVkRnbbCELO7FirRY3NMZr+uHhWXDDJjJJn+P/1Ybos2xla7kxQcRYtueajooMpV hkswh6kK8IM/JlvskEr66C2TNj//T+ZYmP12WNjGZEr2Mtloe3iIl2BS7U/noS3+vt68vvjR b4Ig6HFwdb8wnFzQ5u3Ne72FcebR1BY2vikJH0uyszwdGbdXET7yq9Gn5dK00SA3CbvaXM9j lwofDVwgW/5IxZbyTn2l8JHkloY7+GdB2Ob0VVQMHU2W31Fp+Oj1Fsa9Q3QDX/Tb6nl18Q9z lBr8eFFFEKQjUFI3Eyl6kC3dMTbfL6aZqrzc8FGiieircahoKVPtoUDBp2PeLdsp9e8TUpZP HunYkfqhHTSZFQpFu4H5JXbsc7/cBpNCoVAZqT+p8PGa25FiNSkVimavXfyTa9Qz2cU0eS3M 0ubuOf7W6qDEXvQmhaJNY6H/HB6+1k5XztjDlLF3t4lWX6lll5pM9a08hBBCCCGE8IRWyiiL s0jRCLJW+WND3uuC9ZMOv1q0Mf6HdOrV4vd4wyURh8rYX5gYzntddERFEKSGGvbYEQ758159 SV7QMuQLFUJ+bncd5rzXxQ08tHmp/TJBZ3vY7+LGSPqpWrFxnpmX9DkFR0Ftlv2zk6xQGRVb zMWrT4vf7SrdRbE2Na+wi90Rcyzsn35ubKmbaV4V2+Yle+EddaynJPbttBUmggX/KVwY3nAH QRCqcPHnNj8dPrp4QRiz1KVREQRJClaJ6VoIotlvc/FCPcHW2E+Y8NElucFgsDARokOfps5Y hUM4tqX15C4Plb638pGKLaWl4y2JT0pWDHcQRIuGd6S8Nifb6Yt5QmjQW3lHXMAnOOlUxEyF vCq1uV5Xl+Aw/QVHB31tD5fWzUTSXzjCYxwPMI2jWy5axNwgTPhYvF/uii3bRCJXIx0+Mn/6 A4WJUGGif6iFIIiLfpvcw89xv45Oyiwj8w96jjTjfp99oFmhaFbP99n3GFNue8ptT1nUbQpF W48t5bYn3bZrdPhoS7KalApFU7+N94mR+2RcpVA0aeZGr6YEDqX62aXq2/yt1UGJveiNCkWb xsx9cvVqavRqilQpFArF5StJty1pU7cpFEayqPJXU1f7uaXG+lYeQgghhBBCWBPpDg5Ptu+z T+vY7+N6SRmPg+o6sT2pHCfd2zpGRxXhY12lxx6ysV3e68rrmTlbOq0Fv4uZnNpWmBilDXqZ wlRERahamgmCUBndea8r76VfpEg6mPJcXsaOFhzMe+ksgJfKsY8Vk3kvE7219NDJi56exoW0 DZYkfewISgd/Oyq9Q05lmLWY6LNFu+x3Mbugxl2KNV1RNqpnnuamjoWfY5JFKSp/vCd9IGwg ws9DYzpmOCfb8qHB07s2qEee9UWf88NHo2j4qOoRhFbhdvbYqVDPWLQ19pOYrrk47jSr+KEt rZ8edFZSt1pZWk/28mCuh/JHKraUllQRRLMw8OJ9Ujl85LU5qSIIgjRLHEX5HVH3Rckx0gap QaZtJdFzjSw6zGH3UEvLkJe9tvl1M5IEQbTrRbcjkY8z50vXXNwCxeFjuSaiV7cVLS3NlL2F cc9QC0Eoe+Qce6Xk0ZHhYkfHfp99v69vQkUNSOR+iekfaUObQqEwmnt3e227vbZxpUKhaB3v te2yGlsViov9NvFPRMrzHFcqFE3qqMTSWileB3NXK++4OAcHk2SbQvF8v9m2a1O3KhStV/Ti W7apWxUKo7G+lYcQQgghhBDW1tI4sjSF5OWPjtrmjw35fhesl1Z27KGP+iSmZudWbg+HfPl+ Jnxs6Y6JbYF+FJrKyIL9+X5Xvp/O+1Q9ppLdqendka58vyvvpCeNUXWb8v2umJp6rWDLkNeX 76dHL6r01Iod3PQyw2y1W/xu4VFYqQow0aS1v1xlBMVc7B6JDnO+nw0Tm/1O8abjslH+n1T2 1O/Km3iBIx0+EqTele93hVuZ5g1y1SPa9fzGV+kc+X4X8/C4Knwm18awe6iFIIjLwr1b/S2E SmtlTzTz3658vyvvd/lbCKJFzbtUTPREMf2ufH9/uEN4IVHXQ4eRblJtc9HBhlVMFlxUNyeT XtXl2K10+Cj4UEMSBNFJFvwyjlRkKaO7R0UQpEl4jOxlVnJcdPjIbYHX5tRLD1Qa8aOgcjSn 1CdMwCfRCKXnopYWH2Z/YXykwJ1lft189Js0RbfD5uOShyBsAadGxb9iyzeRtZ0QninqHhe7 6kQvGHHpH0KPM+dxZnlm+pyZPke6z5Huc+y7Hftu+57bvue2p3rtKbemTaFQtKqTvbZdF23C peu/qFA0dd/2WeNOa9xpHVMqFIrWkJP+M+60xg2tjY0XPaTEJ6a2xsZGg4a3lGdI2djY1DUr tqiWitZB29rY2OSxiZVn6++xepoaG5vaxWtIdrU2NhoMda48hBBCCCGEsEYmXJxsryfZa0v2 2lK9dkqqi7Tvtu+76a5Tps+R6RN0rKiuFh0+VinCx3pKZ2QltOiWrw3TZWylr5a76LcyW7DS S0lHgNmsj5v3maWpI9bPpY30J/5AaUmVoa/gd9FRTjHt4fEAr9olSd+wK98vHIRYpjJFCSaz Ryr4YxPD4uNlFCSV/bwHvak/6Qere2L9bIongHQMi7VV85ChnWDzEY+29PRYJKKWOthf8FJv teMfftnwsb+/4GgnCEKlpqPemLqJTZPz/cyDyfTWNBaimexsEYaP7FI6imWuK5O/iatGrLuZ O921tyRLosYCt+iWQz55R0ovJVo17Bbokn4zPzGMqS8SHe3k8cLHfh81CQ9bh3y/xkJd2/0V w0eHv6UoCO5QsesKIuM6WCE7Fgaj1EXI1c0VbmWuBPrO4l2fbDv3i6SH1YWPReE78+8fVLVj 6ou8HalVvH+/KWNOLHzM9BUnj1zs2GtP9tqS/QNz2iaFQqF4QZ1wUb/NWs/zjY2NFz2u/h0n ueMktx3kzJWLjY3P9xnIbQej/nJj4/N9FolPvDbPxcbGxue4VbovXW7XUv892tbYeLHzloO3 bj2k63BplP3E0Ha5sfGyxrbTR33SqeMtHZUpdosAACAASURBVL3c2HhRPdNHbjscO+bWxsbG xhc6ma1p+36HKWnpvNzYqNfXufIQQgghhBDCWkh1aiiL4sjSFJKJIAX5IxtB8sPHavPHhrzH CetkWCR7bA+PBwtjQ1yxq1fpJIULzvqWncxSd4+KIIhOW+Eqb8uhoDBTaw97XTGPk05eCCa2 8zjzIQ8vmGsZ8gULQU/e42THSHJ02grjVwXV7rQI/mzpiXmceY+TGZOoXfaXq0ysW1iMHZVp 9eQ9zvxVfmLYHvYXNZ2Gee7bx/9TpXPkPc68x8g80O3Ke5x5j6cwZiP5FRgPcs0VYhe1h8dH Cp4eOh/xOPP+IW5SC2r7Bs+y23h6V4h/qDAeLE5vO2z0OfIwQRh/latXhXVuD4+PFNjWC47w ttbk940UbO1ESzd94rRF77hsHvIxDWXVhfXtwkVX63bg1pLgu3nIJ7wpKh5p8V2j8lt1MY8z 7/EJ1monCyG3v4UgTc68x0mnchbeHUqFj9x+hW0eHCm+N/XmsNWZ9zjzFipH41VY8ImnYOet 2KqJmcx+/vwtVNJapxYuOUyhTPjIXYT824cgOrRhk5E+irGi65Nt56Jb+KLf6uTCR5EGEWui Mf63kzJMPexvceY9xrBVy6+SyuARfAFKmOujdOT6HNk+R5b+pXRk3PY09S94vba9Xttery3V a0u6rEmXdddl3XVaE/7BhLu7tZFHm3EnMLDttmzZLVt285bdvDWg13OLm4M286bucmPj826z edPGKPjEtuUfCLbxN3rZrVdHbOZNmznY2th4sTNi461bF0vr0Kg3DWwN2OgCao27+3newtag 300v8ni2XOrL/Npf6QqqzZs286a583Jjo15X78pDCCGEEEIIjyPdhRFo2bJbtu2WbYdl22HZ cVh2HGTcQcadZMJJ7jqtuy4r1UVKMZ2m/V7bvtuedtszbjvVsaI6WTlaZ66vuo5qQ97jOKY+ T97vzfs8ssu7836vwJOs6/fm/f15j7O++z2ho8HCeJFXRYoFrgrKBDz5QWbRoL8wHiyM+spu +Wp+kDoiH/chvYqnEGKLDRfYzRqVTKBTVJ63cfYT6s+Qn/5zZFjwp1RliopRBzIeLAQcJRUr bROfsDDz54hHsO6Ip7i8yNZ8gs+parArsrVitz94WteG1EXCnQif8BiFl4RU03FbGy4MOvKB q+wpiGmbBWecfz0M+vIj/IuQt6j28k992d2VP1LBXXO1EPCJrDXqo3cX4C0KCJuLfyWXtnnR vTnio+/NwNXiahd9wl9x1JcP+Ar8Ey3Yaa0tPUyBvpKvFJ/gGEf9+QCvBYR3N9fOpd8tRTdX xSYq+hIwKgmixd/ryHs8+UDJjVnpqJmfQHuuz55lzPTZM25b2m3bd9v2e217vdZUrzXlsiZd 5K6L3HWSCadl025atRpidseSp3eR1W1dMOmEWrmlHueCSbfgcC56nItWXpnST9y9/LUWHVbu 8z5byS7qo6AOvYsOfoWtiy5n8XGxWm2CFV22BQfvc0dNKwkhhBBCCCE8XRfNuphFv2o1bNpN Cadl10nuusiki0y5rKle616vdb/Xtu+2pd22jNuW4fWzcrSOXF8VHdWGnMdxPF9aXX45m31p dVlm+bszkZezWb4nWfflbPbl5G7e76nrfp9WlzTMGxXPuibw1KTfM3jW1YBQXLOKIJr9juOs m+1jtWcY0312Knbcc1OjHa3JXuuui9x1kQknGXdadpyWmEWfnxx/8G++8xd/9sGvf/WrIwAA AAAAAAB4Nvj1r371F3/2wYN/852XIzdiFv2O0xJ3WhJOkuo0JXupCNK256YjyDSvt5Xts7O9 MJm9thOEj5sbBwcHL21uyCx/d272QMhJ1j04OHg5m837++u636dV5o2KpvxZ1wSemggf4bly qet5ZZeR+bPbQv1ziO84m5KfPCZcZNxJxp2WbYclZjX+/u997Rf/9E9n/aMPAAAAAAAAAGfG r3/1q9fufT1GGrYdlrjTEneSiWryR5m9toYc98x2db60uX5wcPDS5rrM8lQI+HKhcHdh7u7c 7N252UJ4Qua6hfHg3bnZuwtzLxcKBwcHL+1s352bvTsTyXt767rfp9RuC/UCO9vAWdcEnp50 +HjW1YCQMtZH+vmvIe2wFkL+fPXboZNHtz1LvY7EbU+77WnqHSW9tj2XLUW93tFJJpxk3EHu OCw7dkvMov+Df/l7Z/0rDwAAAAAAAADngn977+sxi37HbtlxWOIO6l2QZNJlTbmsey66e5Xu taWZbhfVBRO+CLKcDTm3/Xhy4aO88nfnZg4ODl7O5wtTk4WJUGEilA8GqtpjftDzcjZzcHBw d25G/lon3+9Tpzc/NlIYG8kHzrwm8PTMDw8XxgL5s64GhJR5nzcfGimMMQa9x9sO/ZvXa8sw pnttaZd132Xdc1lTTjLpJHcdloTDErdbduzmHZt5nTS8snjn73/2s7P+fQcAAAAAAACAc8GX //Vv/uXS/Dpp2LGZd+zmuN2ScFh2HZakk0w5yT2Xdd9lTbusaV7PK9tro7pjcjpuDTm37Xjy wkdZ5e/enil5/FnuupRc+Hh7Rv5aJ98vhBDC82nWbcv2WrO91kyvNdNrTfda0y5y30XuuciU 05JyWpIOy67DHLebd+ymHZtpy2ZcNuv/z2//67P+cQcAAAAAAACAc8T/8a//p2Wzfstm3LGZ duymuN286zAnHRaqY7XnIvddZNpFppnOF9URy8rruCF8hBBC+ESaFQsf96nw0UmmnJak07Lr MCfs5rjdtGMzbduMm1bjorHnJ//x35/1LzsAAAAAAAAAnCN+/B///aKxZ9Nq3LYZd2ymuN2U oPJHKnx0klRXqzR8lJM/nnb4+HI+XwhfZx5/Hqpqj3nf8cPHk+wXQgjhOZQNH0WHPSadll2H JeEQJI8bpGHB2IO5rQEAAAAAAACAzy/+6Z8WjD0bpEGQPzrMuw5LsszgR7nhY6/teL60sX5w cPDSxrrM8nejM/TEL/Nzd6Mzd6MzhclrVe0x7+ujw8fojPy16P1mM3lf37EPFkII4bkyS+my Zl3WjMuacVnTLuu+k9x3knsOMuWwJO2WXbs5YTfv2EzbVtMWadwgDesWw4Kh56x/1gEAAAAA AADg3LFg6Fm3GDZIwxZp3LaadmymhN28azcn7ZaUw7LnIKkOV5rpglHdMaprVr771pDrtR5P XvgoqzwVAgoef5a9LmXe5+aFj3LX4oWP7mMfLIQQwnMlPcjfRWYY005y32nZc1r2HJakw7xr NyfsprjNtGM1blkNm6Rh3aJfNesWDJqz/k0HAAAAAAAAgHPHgkGzatatW/SbpGHLatixGuM2 U8Ju2rWbkw7znsOy57TsOy1pJ9cLy7pIqmtWvvvWkHNZjycXPsorLx4+VrNHQfgoey1B+Hjc g4UQQniupP+RzUlmnGTGSaadZNpB7jssew5Lym5O2s27NlPCZtqxGrdJw6bFsGHRr5l1Kybd gh7hIwAAAAAAAAAUs6DXrJh0a2bdhkW/aTFsk4YdqzFhM+3aTEm7OWU37zks+w5L2kGmmY5Y 1klSXbPy3beGnIuEEEIInyyzlE5LxmnJOC1pp2XfYd53mPfs5pTdlLSbEjZj3GrcIQ1bpH7D ol8361ZN2mVjz4K++6x/0wEAAAAAAADg3LGg71429qyatOtm3YZFv0Xqd0hD3GpM2IxJuyll N+3ZzVS3K810xLJOC9U1K999Q/gIIYTwCTMrET7uMeHjrs2UsBl3rIZt0rBp0W9YdGtm3YpJ G0P4CAAAAAAAAABiLOi7Y8aeFZN2zazbsOg2Lfpt0rBjNSRsxl0bHT7uSYSP5fNHhI8QQgif MEXCRwcdPqbs5qTdtEsNe2TCR3bY45JBg/ARAAAAAAAAAEpZ0HcvGTTs4Ec2fIxbjbv04Ecm fHRUGz46SQghhPAJMkvpsGQclozDknZY0nbLvt28ZzOnbKakzZSwGuOkcYc0bFn0G2b9mkm3 YtTGDD2Les2CDuEjAAAAAAAAABSzoOte1Gtihp4Vo3bNpNsw67cs+h3SECeNCasxaTOlbKY9 m3nfbk7bLWmmO5Z1WKgOWpkeXEPOYYEQQgifILOUdnPGbs7YzWm7OW0z79tMezZTympMWo0J 0rBjMWyb9Ztm3bpJu2rsWTb0LOk1C7puhI8AAAAAAAAAUArVXVrSa5YNPavGnnWTdtOs2zbr dyyGBGlIWo0pq3HPZtq3mdI2c5rpjmXtZqqDVqYH15BzmCGEEMInyCyl3ZSxmzJ2U9puSttM +zZjympMWg27pCFB6ncsum2zbtOsXTf2rBo1ywbNkq57XntlQXflrH/TAQAAAAAAAODcsaC7 Mq+9sqTrXjZoVo2adWPPplm7bdbtWHQJUr9LGpJWQ8pq3LcZ0zZTmumOZe0mqoNWpgeH8BFC COETZmn4uG8z7vHCxzgbPpq0a8aeFYMmpu9e1F2Z16oRPgIAAAAAAABAKQu6K/Na9aLuSkzf vWLQrBl7Nk10+BjnhY97NuO+zYjwEUII4VMrmzxy4aNNPHzcMus2hOHjHYSPAAAAAAAAACDG gu7KHWH4uGHSbkmFjzZe+Fgpf0T4CCGE8EmyKHxMC8JHQ9JqSJD6uIUKH7VU+Lhs0Czpuxd0 V+Z6ED4CAAAAAAAAgAhsj2lJ373MhY/aHYsubtEnSH3SakhZDWz4mK4ifLSbIIQQwidF+rfN ZszajBmbMW0zpq3Gfathz2pIkfokqU9YdHGzbtus3TJpN4w9qwbNsr57SXdlQaue6+la0KrP +jcdAAAAAAAAAM4dbI9pSXdlWd+9atBsGHu2TNptszZu1iUsuiSpT5H6Path32pIW41pmzFj M1JdM6qbJtWJa8jZjBBCCOGTIv3bZjVkrIaM1ZC2GtKkYZ/U75H6lEWftOgSZt2OSbtt6tk0 atYNmlV997LuypJWPd/TNafpXOjpOuvfdAAAAAAAAAA4dyz0dM1pOud7upa06mXdlVV997pB s2nUbJt6dkzahFmXtOhSFv0eqd8n9WnSkGY6ZVmrgeqmSXXiED5CCCF8kiwfPu6y4aORCh+7 V/XdMd2VRa16vqfrdjfCRwAAAAAAAAAQYaGn63Z353xP16JWHaPDx+5No2bbSIePuwgfIYQQ PgvKCB+1/PBxBeEjAAAAAAAAAFSiKHxcKQ4ftQgfIYQQPhOWCR+TFp1k+NijvqNB+AgAAAAA AAAA4lDh4x1N12KPZPiYtOiOEz5m1W0QQgjhk2KGMd3Vmu5q3e9q3etq3etqTXW27nZeTnRc jndc3m5/cav9xQ3VC2uqF5aVl5baWhZaW+Zam6OXm+Zbm8/6Nx0AAAAAAAAAzh3zrc3Ry01z rc0LrS1LbS3Lyktrqhc2VC9stb+43f5ivONyouPybuflVCfdBdvvaqU6ZWwfTaoT15DP53MA AADAE0KWIZPJZDKZdDq9v7+/v7+/t7eXTCZ3d3cTicTOzs7W1tbm5uba2trKykosFltcXLxz 5040Gl1YWDjr33QAAAAAAAAAOHcsLCxEo9E7d+4sLi7GYrGVlZW1tbXNzc2tra2dnZ1EIrG7 u5tMJvf29qguWDqdpjplbB9NqhPXUAAAAACeHPIMbBbJppB7e3upVCqZTLL548bGxtra2vLy 8tLS0vz8/Nzc3OLi4nF/iz//zh21UqlUmrIPDkULvH8vUHb5GfDouwtqpVKp7HvlP0mWoas9 8eoncrf6xqZSqVRuviH89PCP/+WQRqm2x9/4/NjbOCGffHfZrlZqrn3j3bM6A49/dH9jzKRR UmhMg7H7H552HagTGrj3fm03W6tDq+dJOg/Nf76py313jvd7Eo5f55Pcgoefff+Va5pyKz/+ 8LXC1CB9mWtMg1OF+z+S8517ihx+9sP7v3dnzK5Tc5V87cPHoiW//+oGU1Cts49t3PvDj6S/ GR5/eH/ZrhY9KdTpkkQdf0tGxatv28cfvnkvOTVo0tz5ziMZOyim0umWOqon61YCADxZLC4u zs3Nzc/PLy0tLS8vr62tbWxssMljMplMpVJ7e3v8zJHqlLF9NKlOXMNdAAAA4MmhKIVkx0Jm Mhlq/GMqldrd3Y3H49vb2+zgx6WlpYWFhbm5uaWlpeP/GtMxnXhHgc751He+c576gYff2zOU Tx//0yt9SqVSWU3PSbxTzvaSFr775XG3IYf3v5u/M2ZKiazJnJ+yWWs9efTGpqGox7v5xqnn oHUJHyUOTfpklK/dsU/Sowf/anXKc+MbYgd3Ppq/XA3PHoSP8jn98PHxj16N2tXSPzJHR0ef vxGnSwgwRb51Zv/iUsxf/y9bYlVUqoP3iup4+O43rmlECnqz3yv9FT387K3CkEY6epOI6TQm k0Yp798Eq23bw4++s8ytYMg+kNtCNDJON8JHAIAYv/zyr/78k7/5x98IPvzN4aNPf/yfiz89 DktLS3NzcwsLC0tLS+ywx+3t7Xg8vru7SyWP+/v77FBHNnZk+2hSnbiGlwAAAIAnh6IUkh0C yT6CTT1/zQ5+XF9fX11dZZ+8jsViJ/g5PnyQNSmVYgnj4R9/ra9sH+LMoMNFqZ4RtVi98N0q Rm2Id8ofPTg4lZGPZdZ8/9vRMx35+FZcrVQq+/bf/FRsjM9pUZfwUeLQjnEaT3aSyh3cU9z8 NQPho3xONXxkozXNtWvSK7PD7xfuv/PF46Ojo8efPrgXoX6Ugucm7z58UAhOFu6//eEXj4+O jo4ef/FHr1J1VIa/9VNeMfpHUx382oOPHx0eHR0+eu+1uJc6wPhb/F8kJqZT268FHVWdlMN3 7wXVsgb2V9m2n38v66XHdQ5t3Hvznb96VM33mbzTffRk3jgAgDpz+Dd//icPHz58+Cc/+dk/ /DP92W/+8Ys/f/fhw4cPH/74v/x/vz7hDmKxGPvM9erq6vr6On/YI5U8UsMe2QGPRZmjVCcO 4SMAAIAniWOHjwsLCycOHyWfvf7kW2G1zNEVpw6TPu59T6Ruf/w1h+QySWrRH6pL+HjWnI+q 1SX9kji0Uz/icgf3FDd/zUD4KJ/TCx9//PvzdrVSqdQMpV7/6F3plenv8sDXBcE9E+JVP/Tu 9GBeAMJrTfojw/Lrgn+tYn5i2Zzyy3/3u0MapVKptkfv/eDzKk+K/H9cq6pt6UhTqTRFXv1R 1f/UIfd0Hx09mTcOAKDu/PLvf/o+lT9++Fdf/vLol4//+id/8vDhw4cP3/v00eHJRz5S4ePC wkLtw8eXAQAAgHOPVArJPn9NPXlN5Y/8J6/Z1z4uLi7Oz88vLy+f8CeZzhn5vQX6cU9uPOTj T9++/3urU4NO3uvnxjZe/f5ngojv/XsB+nFn6r1XdGG1zj6Wel3stVdFL9JSKtU6u3PsTv7e //xuua7VJ69OKCU6YA+yBiX3AOzho/fevJe/M+Zk96DWeUTe1SXRH5LucVMv0mK2qtbZB6fG +oq3UXnvEk+g8TYi2VN7/OGb9zaEryC7/8PPitr4jU2l0vG1P2Yq7OFKz9/7QdnhnOyzxEJ4 bVFVBQ4/ej0V1KmVSqVat/NG2YfYqUuHvdA0JufYZNBQdB6kt1u50aUOLSD6sZxecpmT9Jrg PXFOwT1Tpo0rN784Vd+Bx64hu5x689zhR6+z15fGxO7s8LPv35unXzgnWQlZVxJb3cr3XRnk fY/x98W9LG/+nqBYtRnK+W2rw8++/2qSPVK1zi7yOsOqA+jP34gHo/SXjPTKkq/IoL/iZaSP h5/98H6BX/uxjXtvFn/BV31fyIC+Obh3ctDZI/WFK6gi/aoQNn08fPfejSCz46ouJHpTcv5R sKq2ff8bQbVSqTRtyhrlX4q80310dITwEQAgxS+//KsPqfzx/T+jg8j3f/p3vzh58nh0dLS8 vDw/P7+4uMi+8JH/zDWbPGazWfZpa6nMsag3h/ARAADAE8D5CR+5h8WYrJHuVnHdByrSE0HY WXn/XkCpdHztD9nHt/iUPNn9uWixonhDHOZ1lMXpI901Y7LHn34rLL754nd1VRU+SrzWi4K3 DRl7P274KPEqr5JHf9/YVCqVd+7/4Fv0M4IC+r72x9Id2AqxU3UV+OZ349z+Bc8pFiO1Xf6+ y25XRqOfUvh4+K5oq/PumXqFj3LvwBPVkFseuPcDkd2Z4m99zgymEnxeFJvIvZLk33dlkPk9 Jtk06t7ffZspcpzw8Ry2ldS3cNFX5IlGv0quTN+tYpulL73gN35cbstSx1n8rozqfpnkQV1M vAiPvrqk394oPkNMNRcS/Q+FcuZSq6Zt6d/TojGSxwXhIwDguHADHpkhkDWijuHjAQAAAPDk wM8i+fkjNfNMafjIn3OmNuEjN7GFYfONR8xTYvye7+H3CsGpwjcfvPOX1Duvjg4fffzga0G1 UpglcVmFZij12jv0+7E+pUsKJ+RgnkXjlTw6evzFX/7veYeMXm7JWBL+p1zX7JNvRYMb9/7t 2x8yr696/MU79xdMyuIhNVWEj4/eogIvtX35m29/zG32zf1A8TZOuHfJZfQoFaUpco96s9jR 4y/euU9PFCAILNhwU22PMmUPH71HVULOo3viVau+AqbIvQeV31vIbFdz7aU33+GutLf/hzti Ix/Ftyu30Wv52LXoSaJnio+8whzK4aOPH7xyTcPcZsKCNXrsupo7sAY1ZHen9sbpvT3+4o++ Tl8dJpNSc+0V5gphKiG46uRfSVXcd9LI/B5j/jWGV63DRx+/fT8V3ODqfqzw8by1FTPE3Ru/ zxTkNso/4/UJH6l3ZIg3ItW+ZYc+ssfJtih3BSvV4W9xCV0194VM6MefuQmgHn3njlKqjej9 i/7DSxUXUjXvM66ibamhkFW+qkQaWeEjczqkZw0HADyDsIMfHz58+PC9v6zRsMcjJnyUmm2G Ch/ZeWaKkkeqmybViWs4xQ4jAAAAcFLOQ/jIPXsd/taDewGlrNEgVGeLP5qD7mKVzgFKP+jF 63vRz4SVjr6T28ulh5nwx4AcvrGpltE1o3plgiE18sNH5pG1otd6SW/j+HuXWEYnrIK+9dHR ERfn8pqE7ueVPExHb6PyQ41iVau+AoIoSxImUC4df1N6HqrZ7pFoo9c3fKQuRZHL+/P7t0Rv mtqGjzLuwJrUkN5d8d3ARD3FI/eo08A9llrFlXTi+06aku8xumkqDAQ7Zvh4rtrqfYnv+sMf vFx0w9QnfKS/n0Qbscw4Qhr6OEseQWbfasilaVX8MsmD+QblBXYlzwvwKDMMUf6FVMUj10fV tC1VOcfXvs97NYdaZ5d6HUFFqgkfaY79uDcA4OnhN7/4u798jx7z+OMPa/nCxyOEjwAAAADF +Qgf2R7bxMSE3F5mSa+J6nWIjaB49+uDgq3SwzJE+nyye7nM6/TZktSzY5WHhYjsQXb4SHci S1/rJbsPKX/vEsvojmPpq7zYVuUWUWuLPKR3+PqyrNqKVa36Ciy/LqcPK71dqfBR3nZFN1Dn 8JE6FrHLpKQqdQgf5dyBNakhtWTw6++K1rt040XHI/9KOvl9V4biLZSp1gn2ew7bii4ptk3x mPI0w0c6y5Nu4DLHSQ9C5BbJvy/kQf1bnTAJLhc+0kd6ovCxikeuuc3Kadu34molNfi2BLW3 8EDev++UbF1Gkz7+4p03X4lSQ3dLU3UAwLPEbw4ffUonjz/52T/8M2+q63f//It/PHn+iPAR AAAAODg4N+Ej9+y16NgK4Wv9lUqlxkRPZVASPkqnFGxnkM6+Snvi1fRy6UErzCNzVPZY3L8U TtCgVKp1duoYjhc+lnmWTWwbJ9q7+LJyD/fRzcr1uaW3TC2pkK+IbqBGFSihzHalwkfx7cpr 9OrCx9LROmVrQx+LNCcJH0VexMiWkH0H1qaGUkukEh3h8VRxJVVx35U/VTK+x8pVq8x+K+37 HLYVXVKaCuFj+abmqM/Ix3LPFVONyn2/yb4vZPH568sGZcnI2DqPfJR45FryHMhuW+b7pOjZ +9fiXuED/eW+dwRUGVQ//t6eSak83rPvAICnhH/8gnrV43v/+W/YpJHLI9/9v//+1yfcAcJH AAAA4ODgHIWPbJetJBMsN30Bv3DF5zOZzkqZfloVPRfB7KJU71zYgSk3fYlg1Jzs8LFMj65k Gyfdu/gyGeNruOKVwseKzSyygRpVoISqrgnJ7cpu9LqGjxITtXDwhvyeavhYfAeesIZSS6Q+ Fx5PFVdSFfddmVMl73usbLWk91th3+exrSTmu2LhvZahPuEjnR+KjmCu+M5HGUP7hDMjybkv ZCAePbL5sNi/qJ38nY+Sj1xLngPZbUvHry//oLgg/UA/cwrqFT6WRsUAgGeQX/79T3/yF8XP WP/mF3/3l+//5GcY+QgAAADUiHMUPkr0cOkHnHkzUxwdHR09/g+/WzxkR3YX78ffCEp1Vavp udAvZzNkH9BDSwSrMVNi8wZ0HB0dHT76g1hJv0l2+FhxQlNu/NSJ9y6+rFwXt+QRznqEjzWq QAkVZ2eVET5W0eh1feyaPhZZb5Krw2PXMu7A2tTwZIFaFVeS/PuuDDK/x+imEa/WcfZLcQ7b qmS+5uprL4tKs12LjTukfyLKXKDl0jX6apc98lH2eTykZiUvfXnkUdkn46knm8VbWs6FVOUj 10dHVbRtxbapMOO4xGpVXCvH3A8AAMgG4SMAAABwcPAEhI9S4xJK+xjyu3hUh4s3VWjR3mT2 XOjxIINff/etuLqob1byCDCDSGdPdvhIH4dIBkCnA8w2arB3iWVlurj0meI67PUIH2tUAal9 iYUJVMxQOXysptFP452PJ4516hc+1qaGJwvUqriSZN93ZZD9PUYlRZWSntMNH+vSVlUk0PUJ H0tf3FtU1XKPQ5dJ1+gvAu7qrlH4+Pkbmyal5PQozD99lP6qlbwLl4+MC6maWa6LVqrctsx8 M1Jvf5X/al3BalVcK1Tz8Oe4AgCA4i1ZXAAAIABJREFU2oLwEQAAADg4eALCR7ovXtwFoR/K Ol74SP9dMl3x4YOsSVYqxkD1sO7s7zuK+2b08I7iPjgzsc7xwkcmAyiZJJiZLbxobKesvVMN LDd+YiaFLqkC03Ylk03XOHysTQVKocOEkrl3xa4J8e1W0+hSVSt3MqQQOUn0mNzSCYdLoCst 2kZ1DB9rUsMTBmpVXEly77syyP4eY96HWX5a4VMOH+vSVswXftlpvcvWUhZlVmZGo8bf4n93 H7779YBSWek1gPRLf0sn66YPtGS265OFj+UGPVIw6WPwG4L90M9pS2WHFS8kkZm1ZSG3baly Jd8ETMGqT3qV1wqd6FYZrQIAQDUgfAQAAAAODp6A8JEJhbzZ/5V6lJWepFKj0aiPGz4yHUel 5torD6itHj76+MErzCvZ5Hd4Pnl1QqlUq9WlfTO6D26KvPpHXzymdvD2/dSQRqPRFHf2qP6f afP1zwSbEDseukenNEXuPWCb47W4V63WaNSlI5Xk7J1p9lf+w6OS3qVYz/T9bwTVxW333psv UW0nSEzqEj7WpgIi0H13pdobf+0dptEe3IuYlBqNRtZj11U0evnAWfxkSCGyKSbwVNuj9x58 SD/ke/jo47fvFyaXhfO60i9gW/6DTx8fFVHH8LEmNTxhoFbNlST3vpNG/vcYO/UWdyXShW/8 92waJvGdIcm5bCs6eVVqhlKvvfNX9BX/+It33ry3MVngf59StVQHv/6jkov0+IcuqMG1Vx58 +pja+/0Fk1IsDivm0VtxE3UJL99nTtOnb39z2a5WFk2ffOLw8fCj7yyYlEq1N/u9MnXi7qnl ++89OqS+wL5GnTbJhLfSTX6MR65p5LYtXU5tX/7m25/yv3flnIRSZIePj7/48ME9arbrMpEu AACcHISPAAAAwMHBExA+Hh0+KJRO4mHafOOj79w55oQzR+w4kpLNer0GeT0XBjqyEhkX8sm3 IyXTS6iD9979wdccRQOgmCiUhlkmejyPHhS8pRVnmoN7b5X8vR/9u4JJWI7raIr3TKWmVdFc +4agC1en8LEWFRDl/W9HTCXbZBqN/1ie1HaraHSpTZQ5GVKIbqrM7Cb2g7d5BX/67YiwKblL uZ7hYy1qeOJATf6VJPu+k0b299jR0effy4rsTKk0RX+fvb/FvzMkOadtJT1Dkzr6+3/NtR09 8JKm0gsxuQMQQ3iw4jWoEPMx1ZK4hNX2uODJ6JOFj4efvb5JpZw6Oz03utTRSFTIFPmW8AyV mfCpqCrHeuSaQW7bSlwF8k4ChbzTTf8LQPmzBQAAtQbhIwAAAHBw8CSEj0dHR5//4NWNMZOG 6oB5pgqvffj4iO5J8HrdVXbxDj/6w3sbY0xvTmManH/lDz96t+rn+x59d0Et8YDe4UevF6Y8 1A40prGNV7//2eERNUBO2H0+fPdb81Q5tc4+lvnf+G9PK63L4w9fK0wNUs1BbfcHn9PF+ZuV vfejxz96db6X2Zxz7M7vffeDL6klkvHT4w/fFDbeVOH+D4sHYdUtfDx5BSQ4/Oz7r7JbVes8 U4XXPzqkHxLmXWnS25Xd6NItK3kypChzkl4rTA0ybaTW2QenCvffLh4/ePjZW4Ugc8T2wank N/6vzyodpgRVhywnq2ENArUjmVcSV9mK910Z5H2PUcdc9O00tnHvzQ/57SL+nSHJ+W0r6p5z 0mWVGpNzbOPem+8Vjfz9/HsFuuU0psGp//GH5Y/2SH74KFbZoqYux+FnP7zPrazW2cXWPln4 WH5W8JJ/qyv5ChM5Q3LDx+M+cs0ht22Lqm1nvzplIut0f/nGBi+apb9uRK9fAACoJQgfAQAA gIODcxU+ngdO9HIxAAAAAAAAAKBB+AgAAAAcHCB8LIJ6bR/CRwAAAAAAAMDJQPgIAAAAHBwg fBTAvLG/4hvUAAAAAAAAAKAsCB8BAACAg4NnOHz86bfng6lvPqCnKaWmk6XmGznm2/UBAAAA AAAAgAXhIwAAAHBw8OyGj4++c0f8/fSmTUx9CQAAAAAAADgpCB8BAACAg4NnN3w8Ovzs+68m 2Xk4JScqBQAAAAAAAIBjgPARAAAAODh4hsNHAAAAAAAAAKgf5yV8fBmAunHSQAIA8GxAfWMg fAQAAAAAAACAGnL24SO1lXw+n0ql4vH4DgA1Ih6Pp1KpfD6PCBIAIAeEjwAAAAAAAABQc844 fKQ2kclkEolELpd76aWXataJBM88L730Ui6XSyQS6XQa+SMAoCIIHwEAAAAAAACg5px9+JjP 5xOJBGJHUCdefvnlRCJBjX8867oAAM41CB8BAAAAAAAAoOacZfhIrZ9KpXK5XC27jwAIyeVy qVQKgx8BAOVB+AgAAAAAAAAANeeMw8eXXnopHo9j2COoK+xlhvARAFAGhI8AAAAAAAAAUHPO Pnzc2dmpZd8RADF2dnYQPgIAyoPwEQAAAAAAAABqDsJH8EyA8BEAUBGEjwAAAAAAAABQc844 fLx79y7CR3AK7Ozs3L17F+EjAKAMCB8BAAAAAAAAoOYgfATPBAgfAQAVQfgIAAAAAAAAADUH 4SN4JkD4CACoCMJHAAAAAAAAAKg5CB/BMwHCRwBARRA+AgAAAAAAAEDNQfgIngkQPgIAKoLw EQAAAAAAAABqDsJH8EyA8BEAUBGEjwAAAAAAAABQcxA+gmcChI8AgIogfAQAAAAAAACAmoPw ETwTIHwEAFQE4SMAAAAAAAAA1ByEj+CZAOEjAKAiCB8BAAAAAAAAoOYgfATPBAgfAQAVQfgI AAAAAAAAADUH4SN4JkD4CACoCMJHAAAAAAAAAKg5CB/BMwHCRwBARRA+AgAAAAAAAEDNQfgI ngkQPgIAKnLy8PG/AAAAAAAAAAAQgvARPBMgfAQAVAQjHwEAAAAAAACg5iB8BM8ECB8BABVB +AgAAAAAAAAANQfhI3gmQPgIAKgIwkcAAAAAAAAAqDkIH8EzAcJHAEBFED4CAAAAAAAAQM15 ssPHtYCKIAiCUAXWRD61Th97w+BpA+EjAKAiCB8BAAAAAAAAoOYgfATPBAgfAQAVQfgIAAAA AAAAADUH4SN4JkD4CACoCMJHAAAAAAAAAKg5CB/BMwHCRwBARRA+AgAAAAAAAEDNeRbCR+Zv Gn4mOW3lLeC2Qn2sCqwhx3xaQPgIAKgIwkcAAAAAAAAAqDlPf/goyBf58WNRJsnfUPE6wu2D JxCEjwCAiiB8BAAAAAAAAICa89SHj3SOyJVYW1vjF2IGNYqthBGPTw8IHwEAFUH4CAAAAAAA AAA151kJH0tyxNJQklpLFVgTWQiedBA+AgAqgvARAAAAAAAAAGrOUx8+Fj9dTRcVe+aaW47w 8akD4SMAoCIIHwEAAAAAAACg5jz94ePBQfE7HFWBNenwUfxZbfCkc4bhI3WtNVmnk/JL4+qT yek01/aomiCIi65ooX77eOYopFejIZ9Fo3yh6Tnm6/e5phe6DL6Jhe3cWdUK4SMAAAAAAAAA 1JwnO3xkU0XBM9WS0SFTWhVYY/5b/KWOCB+fOs48fJQbPyJ8rIpTaa6Y7zJBEARxwTiZrttO niVy62Fnx/MXxP/9h0ohVc7p7bOoGsJHAAAAAAAAAKg5T3j4KPJKx+LRkGuBQPEISMHQR178 OB2g10H4+NRxDsJHgrjQEVipNHauPmlaYXNuIuA2dF163v50zaF0GuEjkz0SBKEePZNE7Gmi sHndfInJHZ9TkYHwwnoiTd0WhXRiORpyqp47u6YuCR+za7Njgy5dR8vvkNcRPgIAAAAAAADA cXjSw0fJ56eZTFH4xDU/phBZwqyG8PGp41yEj4SM4Y/1SdO4OjxlE7jXP3wsRF0XufN32Rer z26eDQorw2rmGeumntGYxNPVudiQO3Q2MW9J+LjiVyoozAgfAQAAAAAAAOBYPPHh48FBaQDJ y1fW1qZFJ5wRXVEVWFtbWztA+PgUcl7CR4K40F02VkH4WBV1Dx/Tk8YLBEEQzz1HhWaXvAt1 2c+zQGFliLkMLxomNs/lCzQRPgIAAAAAAABAzXkqwkcAKnEOwsdLly9TT5uWffoa4WNV1Dt8 pKaaIYhL3pD3EhWbYdqZY8J7/4DhuqzZl86AMw8fHz/++SeffPzee3/6EAAAAAAAAADOmvfe +9NPPvn45z//EuEjAJU5B+Gjaui6l3l5oPTT1zLStEJiKRxwaJSX2Ck7nmt6QalxBCKr6aJc TPTdAsUjgQvznkv0n4brkjOqMDFcmfCNKVJa90J6NVJS5QrzGlMtcdEdPTg4ODhIzo+SXfS0 yM81veCekdNca8MdF5jxpqMbx8gMmSO6YJ3OTVvp7FjWtDMlR3zh+UtdBl+45BSx5LYXJnyG Lm7u5+ealBrHaFS6hXLr0ZBgjQvPX6rUqoXE0oTP0CX/RFS9gtSOucfXj/3sekkTXXj+kviF z0JfIOyFTR8OuwlqC6NzCXoDbPg4RdL7UJTQ2NjY2Nh4uW+WCx+HNF/96le/2uq6dbLw8f/5 4vMPPnj/0d/+7Fe/+PnRP/8DhBBCCCGEEJ6tvzj88tF//fyDD97//PO/RvgIQAXOQfh4wX6r EHU3MbGJxPDHCuFjcj7Qw2xChAut7ig/1ZQVPvKnVJGc5oMrIhm+xUPdYlXPxUZ1l6RnNn5O 1XcrUaYllEMrB8lpq/CgO4Y3KjZXYSXARI/yJhovc9DdofhB+rqhUiOxew5JH/GFS7rSdx0m o32q5yRWEG2hwuaUvbXMdNFNPSGRy4v/ysXS3bxoDMwnT7iCdJsw2e0xB6kWErfKNJF4qx4c sBfIRXe0/JXI3DknCh+/2uVfXDz2j/Hjn3/5wQfvI3aEEEIIIYQQnjd//cuff/DB+z//+f+L 8BGAcpyD8JEwXE8fpG/Zy8eP5cLH5LSdzk6eUzkn2EmCC+mthQknk8yIbrbSY9fccolgLerm zboiXobNHvmLeQnghVbzaHQ9lSutsng4yNRJ6xvqvvCcyhleTuUODg5y62Gnzr9QVKikubiG ljPHuCjcWD3qiNiBnWXjM94R06ep5JCLBo/yotULl3S+yDJ9XnOp5YiPSsuELc5FglT5OLUH /gpijcpF3009gegWc/EkliM+44vPiZzYqlcoA3cBHeetmbwmaurqC4u0UKUrX+ULD3VcEJ6S g1xqOcxluE3uaOG4j13T4eNzRrv+2D/Gn3zy8aO//dmZ/18FhBBCCCGEEJb66G9/9sknHyN8 BKAc5yF8pCIrXvwoFrpJh4/JKfNF6aiOF3qJTGlT8Z2PXLAm9kwsHcNdaGq6KFmGHRjIC6S4 9Eo0GCokpqzs8uHiPI83UY9qSCo+lGguLqw6/usFmalmqHGPwk8kHxzmzakifpqS816zn78y e1olUtLC5nWzkz/WlN2FRKrKHXuTWxBysvmf2MP1ufUJs7nouql6BWk2hjuYk2meqjYK3g51 lxvCmosNsUNc7beKalo01/xU6SDb9LSVOQHGyfTJwsev/vZv/3fH/jF+770/xbBHCCGEEEII 4fn0F4dfvvfenyJ8BKAc5yd8FI6NKwmQJMNH5hFg6VcOck+2MmlZ6VYlJ5wplz7SodsF69QU vYfSFz+KZY/cNiVHyHHR20XrtPC42DpfsE5XNz9PhbBKHmzSyGtwroUl3nzJxZNy56WR8cS7 xC6k35zINgrzwsyDgwNe/if3seeqVyjDypCSEKmTHLgBqJJtyot8i+sqJ8Jmz8EF+62Tho+X HMf+MX748OGZ//8EhBBCCCGEEEr58OFDhI8AlOM8hY8HgsdIicvehUL50gcHBwcL9GTL5eaE YdOikidbZcx2zb3SsDgeYjJEw/U0W6h4QCG7gJd7cjstU2fuwIpTVVkTWZcW4o0APe7z1gcH vOBUkHhxQZhoBsy1odxni9mjL9tGYrsot4db9gulG2WvDrmDQateoQzcy0erTTK5wLfcEXMt X5TJchF2mXmC2CGeqsDqCcNHzRDCRwghhBBCCOFTKcJHACpwzsJH6aevJSI3iclcimAjnuKI UUb4KDlqjxkX1h2K8+ohDHnYdXlpF1eUnR5GFDYpu2C/JVrnasLHwgIzo/hF89QJEjN2MFzx +MKyIxXZEKvoUCSR20Yiu5A+kVJNxwWdFy7pAmVm0T72CtIcP3yU2abcc93Clqz2KkL4CCGE EEIIIYSiInwEoALnLnyUevpaorRgwpfKHCd8lEgf6T0zA8dEC7Gj0/gj7bgql8vJ+HU7WWy0 dpDbDlMDSiXnPpYJN8Cx9NnmMs+Sc1Gi3IRNbhuJ7EIWUm/CJAiCIC48f1njCIQX6JlkRKh6 BUl4OabMXLbkgCu0KRtvCndQ3VWkHFpG+AghhBBCCCGEYiJ8BKAC5zB8PBCGO/RcGRKluZFj 1WdOBzLDR7GHipmPuKRR5BV8TPYofLKVq3KFYI0tKKx2dbHRheebnqdT0d/RXds69uPWwkMU ew+j9NsxuVaWGz7KbqPSXciieKuFzSlujnGOC5f+f/bebSuO697b7htYiRmvPZzkdbTWF758 WW+y2p31eQVbapCiIExkFlFkC6GyaFlgIwHaYmNLRiy7D3QAl8IRXIiOGNyKDjX0HtRubv6z 5qyu3vP8xnNguqtqbqq6k340N//n4tKWZGtLn+CIsuFM4Pxyq8GePnU84uWeoompm8hHAAAA AAAACeQjIZ4Mp3xU94NO9KNPPgZKKlcdis+37GM6zlHTbPn+HPFB6VnGqnr9lY963pu8+KW9 r3Fg8sGdvhg7oPRTPlbYBGb38drS/Pk//ev7eivf/eATx+48pU8Qko/xLLfjDPIRAAAAAABg KEA+EuLJsMpHffb1r2dae6mPcky7tjayLlcHn+TS5wGn23gYAwDzsX9/XHyaTak1d/QInVLc rdX6NtvGUNIOd7rOW+eP3ua8JaFqMFvvsvS069KbRgvZe/Zo7frF//NB5hR9O8uUPiGPYnRD N+Npt9slpl07lg5FPgIAAAAAAHQF5CMhngyvfGxryuxfLy9e+kA4OvNanUmnYPmYD2ucnN9M /KG9T3Bukj66uZfooXenlvWhhrk2+t2n9wtKzLe77sKGM/pKmp3s0px1QJHmzdumTSLOXeJH N4PGXea6sriPhCI6s9BS9h5e/3PqiYOuWvqEdluzj8aA0eLkDruwT/PtrqsobOQjAAAAAACA A+QjIZ4MtXxUZ1+/+95770pHZ4rO3gIlILma8Y6wy+TbRzdXL3/gUEXZ/OxfzbRiHSYclSsd aelE6yjTcXYmH9vt9nc3P0p9Vb6RT2iy5hcvTZh3qNq23EmG+rVcrRX1kVSwrYQr5P6nv/P3 daUT1I3IJyYmPw2+LdlmRoV9mh9lfD4qy8edax8iHwEAAAAAAJCPBdlcr09E5zIm1zfSd6Kp 6NxENN3RCnqeLK+em4jOTW314NKkwwy5fNRH7IlHZ1bsV1PL5a1TiTUj0/p+8Mc//qtbdqbV +eDf/91lKJUJzL+ecXij3EhZzepYPoob+YQlX/TSty1KPpBP7aC8xe/+cTFEJuYFuvvIVXCF ZR/NZN2oDxvs4gntdrv97MtPOpgUryxE6uzT7z7/s6NTKsvH/7nxX8hHAAAAAAAA5KMry6uG XtyYb2X+MZaP9fntHpWrik4y8Ay9fGzrykw4+vHiH99Nxc1NeTeVvYeff/SRKGiyEXYBC+5p ix46B+TlvsflHrXtdETZlBvXd39/1eycCvLRWEkz2HNlYi9gWGEuAdXGK5OL3/395VWhyds3 P9FuUSaVJyZ+/Z+fP7S7cXf90w8vKt2rjJL9/afr8o7T361e1s6Jq/aX31+Qt6j+7nrdFqnl T/BHmxT/b5+4Nsze2/7q8kzeSfmTL49kzT84tmmuLh+/bL4fy8ffzLSQjwAAAAAAcGZBPorZ Xphk+CFJMgry0ZiZah+t2Ml3P/hwdmltayeRN7s7W9lOIOIIunxa6ru///TrZ3vJ5iEXfv/7 Odse5bOHiyYDK4P23AtRahLwP2aje0mNd3fuRbMffpDZVEEPVpKP7U5mX2fWNWhKs9Kl6uGa Qv71Hy4u3dt+ttdupx0++d7ExMS7H938Mb+OOub13X/76L9bW3Yn/T9zypKQ6hnvTV5YbKVF tPeebd+L5v8SF6KPE0wb9965P128vpYXsbV2/ZN/i6/2q49uflfhhLB8tzr77+9lHfTe5F/m l9a2tPonTVa9pvrk/9sn19ceWV3qusvV5ePzG//1v2L7+L8mL688+e6HH7Yffn3r7//1b/82 s4x8BAAAAACAMwPyUczWNHOfSZrRkI+qVxKP3tv+8uJkrm6kvDc5/aUwnFf1mlqksWvpwoIe CZdNvS4cTbm7/t8ffvCuWHZc34tfiuM4q8pH3QMGrDJYzj1q84G1E/Ye3rxQcJPe+/fZr4wG f7c6X9BF737w0XVziKCnUycmJt794MOF9R+1Mv7zXMGj896/z+vDKEufEJy97a+KLz0x8e4H Hy6u7+6p5xQ++e9+8OF/i7WpLh/3nn916dw7an6Z5H9fWB4K+Xi6X6/VarVarbHfbX158rJR yxIdd/n/uxy2enLZ/lR+8PTwvg9NiV2sSZcq/+qgUas1Xp663koz8C4CAAAA6AXIRzHbC5PR uYnWguMn58Z8y3p3a1pdIFKZsr0x36rPb2srSBbMqt5cr6sTupdXz01t6RdfjbrRQhKeUZGP 7UyZuY/efbx2ffbPf/jtB+9nM1jf/+C3v/vTf80utjaeuRXbd6v//Zc//DoROO/9+re/+9P5 +aV0EJmeePawd9eUWNcFzOTee7YRzZ//0+/yKr/369/+4c+z19ceO/1VdflYavZ1bmetfbud p+RjP60RortbcoO/kSfMt9t7299cn/3zH36b3qCJd9//4Hd/Oj8fOaYm552anzLx3q9/+9s/ /HlmfsnRr7uP15b0UzyllD4hPLuP15bmZ6zn+A9/npmPHI9x+uRblXE/9l2Qj3t7L57c+ftH v//Vu8kAyPd/86//30eXFm7evf9gKOTj2zevY5HXZd9x8rLRU4eSyMH6wUmvLn4GBFAP7vvQ ldjFmlSrfKazBfl42KrVaiuHyZ9HEf4RAAAAxhLko5yN+ZbhEK13Ffm4vKovAakNnEwvlUnD wmGVtnycUDXo9sIkK0L2OwOUj4SQUcnPonx88WJ3d/fHH90bzty//80336yurt67d2985ONR 5DaDgzVQAaUXVb63nO7X+zjQEvnYJ/mYDJxcOTzdr9vy0b7pxyvlxttWfGz6+9QBAADA2QX5 6Ey8q4zu/pLo8tEWgrZ81K4QTbkHMEry0dz3xj0kk/QiyEdCiDfIx4xCnTHs8nGALgb5OMQ1 6bTyJy8btVrr6PXb+P6a8vHVQUMZ9hhzFNXSU0JAPgIAAMBIgHwsjjLfWdGLmgE0dGF2liYf NdVov5JHkI+6arRfIT0O8pEQ4s0IycdsDTtrmbl4LcXslfxPRYVo69MZMuV4pSYkdivaQopa gj1LUdHyMZnWCSi9qPKBFVs5VDtNGEF5FNWkd+Wi8zYetmr1g5P0ymopWieoRQumzH3fu9L5 WunSxTvzd/1pu+OxqVp5qw5mv9mXTWoSUpbvsUlaLV2/fnDiP918buVPHAAAAEAQyMeQpApS HMy4uV43Z2cjH8cqyEdCiDejIh+tSZ2CVUlNTXLY8UquY9T/lsdt9WXk4/GKpEJiw5jXR19N L6z0jgeCne7XaytRK1eKseXJL3W8UlOF4+l+3bCT7qJjs1Y/ONHXu1RG1ZlLVcaHKV0Uct89 HV5w382ej3WV0ZaO5WOP2+5/bLrz3AryUW1F2rGN/UPxY9XhE6uPo7QPDnngjS8EAAAAgA5A PgYm3oImMYbIxzMV5CMhxJvRkI/CgoYO+ahYEnGtuoK3BiUfhRdPXja09vZYPhp9q/a2qZnS CiuOqVg+aqNTk7Oy132zd8Pue7nG5l0t7ePcVfnY07YHPDZVu0vqNPupiM2jo0WeB6/oic3d q7SeKdOuAQAAoD8gH0OjGkOmXZ+pIB8JId6MhHyUnJ1fPhYgmosK8lGf/Vqr1RyTsgMbEr+o XKGafNQmTZsTVIvVkrOjjCuEyUfrv51tj18M6K7QnpeqGijmCg4rKL3XbQ95bDqufNHt1p8Q tcQuy8f0gpHYBOQjAAAA9AfkY2iiqXzZR33XF2v36s31OvJxjIJ8JIR4c2bko7m0X1flYyiu hohRiuvxyEePfBSTl9W5fJSGVaoOK9jVFuC+73Lp3br1vW57yGPTnefWteZj66i0Ii/9xNrz 4kudDgAAAFAZ5KOYrWld8G3Mt9Rdp40tp/V34wnayMfxCfKREOLN2ZCP5nJ4wzTtOuTKg5WP ISvrDWrkYzHF9736yMfAs/o28rFblfc9Icr2L+JjE3pZz6N12KrVao16Q2oC8hEAAAD6A/JR yvJWtLx6LtvneiKS7KFgJ2Oml7cXJpGP4xPkIyHEm5GQj8K6hMZmHdlhony01owrLx/LTSl1 EbrmY/nSeyQfg4yStCTf2zevAwSctOqiqT799z28YkZjA3r+dc/kY9W297Lyviek0x1gwh6b GKV/9M1nwk4HAAAA6A7Ix15ka9pcBZKMcJCPhBBvRkI+pmOg1K1C6g3Lxznlo25tXHvgFtuT +KzcgBxFHbjIsN2uhZ1DvKX3Sj5au12/tTacEe/OwcnrAAHn2LJZH5zove9OvPc92Yda7bdX Bw1pg520Dqf7UZjw6n3bAx6bTivve0Ky6umVESR1vN5owXhk4bHJnjpjar+wl47r9IDSAQAA AIJAPvYiyMexCvKREOLNiMjH1/oid/WDE9UlyevfaSpE2XSlsf8q/TOxFccr0vmW4dIXQIyO T16FSQ1hZw/LiRhNqB+cvDoVtvcVSg+svAuvfLSKrtVWDt+abdfq39g/PA2Uj8K5wkxkpVuc 7lim8L6Ld6d19Pr46LCgDo1mDfHFAAAgAElEQVT9kL7tT9v9j01HlTe7zvFcaV3n3Kym6GaJ j400pzsty95Oxzo9vHQAAAAAP8jHbmRzvZ7uRdOOt6ZhZvQYBflICPFmdOQjAAAAAABAX0E+ diOb25Gy5qNzPUcymkE+EkK8QT4CAAAAAACIIB8J8QT5SAjxBvkIAAAAAAAggnwkxBPkIyHE G+QjAAAAAACACPKREE+Qj4QQb5CPAAAAAAAAIshHQjxBPhJCvEE+AgAAAAAAiCAfCfEE+UgI 8Qb5CAAAAAAAIIJ8JMQT5CMhxBvkIwAAAAAAgAjykRBPkI+EEG+Qj6EcRbU80XH4iScvGzU7 9YOT8NIPW9q5ZUoHAAAAAIBOQT4S4slwycetpSvNZvPK0lbXrrjzzdJns5dmms1ms9mcuXj5 06WN9rO1pf+e/9v8zdBStpY/nWk2Zz5dLl+trZXrV+cuXbsTWLO+paBeg8qdxWaz2VzsX5X6 XmCH6fRD0el5e9tff/HpjNkxuXzcffDV9auXL06fP3/+/Pnm9N+ufn7nwQ7y8c3rt29en+7X FV346qBRxQAetmq12sph+CnHK7XGftZXFUsHAAAAAIBQkI+EeDLm8nHt2qWmlqu3n5UuJZWP Nzf3ypbvFlxizfqWIRRvyEdH+ikf97bvXr8SC3FZPr7YuHFl+sKFCxcuXDh//vz58+c/+eST Tz658Ndra98hH98ctmqq/ksGM2qvBHO8Ulkdnrxs1Gqto4F3CwAAAADAmIN8lLMx3zo3EWlM dW+o2WCyNT0OrRhAxls+Prw512w2Ly1+9UzVht0fX+mMU3DJNetbhlC8IR8d6Zd8TMXjpatX 51zy8d7nf71w4cL0Xz9b3th5vrf34ocHrX/87cInn3z88aVra2dePh5F1izpVweNWq3x8rTk pU7367UueMPDFvIRAAAAAKD3IB/lbMy3zk2sRtnfm+v1iUh7ZfSCfOwwA5WPuw9b1+fTqccz Fy/Pzc9dMnzJncVmc3Zps72zen3u4kyz2Zz57PZ38blfLf1jfvZyPnH5b58tfb29p55o5cqV K9KrPj/j0FRW9ReX8wrE6sfM4h1XzYrrkHZDXObfLs40m83mzKXZz5a+2bEO3tv+enlx7vLF pGKXZuevtx7ueuuVvbvQ2mvvbX+99FlczszFucXbm3tpgy/PZN3tK9vsk8I6zl0OdoF72/ej L67OXU5Pb85cmruWN9FRSHPm0uXZq7eyye3l5KN6B67NxTd95vL8F6s7WUHpXZm71npkN1l/ WvSb4j5O/FDYbZOuV0o+7qxem51pNmcuX402V69dsjvm559//vnF3X9cvHDhwuwX93eVNR+f 3Jqf/vjjjy9cvT1w+Rg7O32kYTz7uH5wkqzGaI1DzPzgYatWPzhJl01cOcyXUAyzh6f7dXOs YrL+Y8kBjBXGS9rXseRj3CFISQAAAACAroF8lGPKx3biH+vz2z0qsfcZtHwc2Q4cmHzc24z+ bkw8lkTcncVms/nptWtziUBqXv78Xrvd3ls1Zy3HubR495lyonXl7snHnTuLl2fsa11avBMb ue7Lx+bVpcguc2Y+eqz3681PhXrNzC3Fk8YD5OPl69GSeY1L11Y3luaMF2c+W9Gmij+794V5 SLMpTFhPTJeUEBf4ePlT6dSZOW0Vz71Nq756jcvLR+kOzMxHG3cWzYfx8hf3tbOfrHwmPK8z l9OnJatz0IfCe5Pb7XZJ+bi3uTQ/d/3u9p6rY37++eefV/9x8cKFC5/eemJsOHN3cebjjz++ eO3uoOXj2zeJ78vMmiEEj1csk5gbulg11g9Osr1f8v8OUXXmxY+iWi06FoZDFtPhYEl/fRIS o9oFuQkAAAAAAG9ev0U+uiLIx1jeTa73ccuL7gb52GEGJR+3bs7NNJvNmU+vf7XxfTxga/f7 jeiqNPKx2WzOzH2+9kQd1/Xs9sKVxaXW+sP45L1nW1GsdxZaiueS/Uvpeay2jXl2Z/FSszkz 90+19q3Fy81m89L1r4vO7KwOmbC89PeluCP2nt1bnr9kaan4upc+u7X+OJ7Qvffs8drS/KVm c+bv0bZxPbtemZq89Fm09Wyv3d57di92eDMzM9mL7d2HSW+rC1XuxctYzswutuJO2Xv2eO2L WJKpMu7Z3cVLzWZz5vKCVsnrV4Jd4L0vPp2/fmtt49v47N0na5/PzTSTkYl6Sy79fWntsTy1 vQP5qD6Ju09asXOcmZnJXtzb/jquSuzIkzyO5me0uux+vxEtXI4H8ir+NvRDEXaTO15dwCUf n9769MKFC3+9/o252/X3tz79+OOPP56/OQzyUV0t0RZ/uppMX4ntpLpio7rZi7WSY0G5mezL LltWPmp7XldY85EFHwEAAAAA+gXyUY5TPsbyLpmFLS4HuTWdv9VayH7pa6fEV7Zt5vbCpHS1 9JVoqqDQ1sLm9sJkdE69plFPt3yMpqL6/Ha60mVebWeJQnPSLK+es97SrjNqE9gHJB/vfX65 2WxeuraqayHbl8QixBxIVnBNQcV1Xz5uR/PNZvPT5cf6cc9uX202m3M3H7rP7LAOifq6srRp L16pXn7t2iWhW+OumVm8661XcsXLn9/bM842L7u5NKs7trjx5kDMVEleuramHWd3XqUlGJOL 5menpZo90XGB8dEzV28rQxWTUvW27LUWDC2bPuxrel0SJTmf6cLQD0XgTe66fNy8MXvhwoXZ GxumfEyGPv71H2tDIR+TwYMrkSQN47fyLaSPV0TJ6PrvIjL5eLpf1y1kqZGPelU7PLf0TtkA AAAAANAxyEc5gnxcXj2XDNyLTV/6ujagb3th0nB/imfM5N3yanzMxnxLEpTGWpPxAfaVVRsY G0/lUlqFlWPc8vGcOSyxoES5OW2zRbEMTZvDyMdSibdb0UaHtdttt3wMMkSCbOmVfLy76Jg1 bI5E7K58tDbEjuuRXyXuV1eUahTLR3UEYX5V42jzEnFdhD27Y02ZXdN1XLX9X4yzXQ9Y5wXG R2vjau3+b7fb9q111iXRlOk1Qz8UoTe5j/Lxm2uXPv7440uLd4dEPqbjByX7pk/EVrdkqSof Y+d4rJpHcSHIEoQWrdO1idsAAAAAABAC8lGOvOGMPOdaHa64NS36tc31+kQ0vWydqvu4jfnW uanVaeXIjflWUujyquQWs1fscj2DKI1EU1brrBLzPnE1x66GeiTysVRcXqSEfNzbvh9lW680 m82ZS/EeHeq4wzLy0VqJsUjVics2pulYPlrLMeZvO65jXkVe0DGkRYUdJh5tvuh2efo7ruPk 68nV33341dLi3KXs3l+8FG+Nkw37CxFvQkXK3gGxGPmmSHXR3wn9UITeZKeMF9tX3DEjNvLx sFWr1Rp1x7YtitE7ednIhxZWlY/J9jK68XQsvBiIOU4z9BTMIwAAAABAH0E+ykknIOdIri2O pvmiKWsEYnaMMNdYHV0Ym7st5ZXthcnE1kVT1umay5Otn276yslH+xVFyDqaYxtS5GPHiQfD VZCPj8UNPBwyqevyMRmyFjBors/y0dWvwfXqXD4W9Il2pPO4YPm4d+8Lx3Y15TqiX/LRXRf9 yNAPRehN7rp8jNd8vPiPu5Z8jP4+RGs+KvbNXuHxzeu3rvnR1eWjcGRnQxdTSq/bGG8mU2Gl SAAAAAAAKA/yUY605qMadWFHcz3EbH1D3VemCzIKwwlbC5uxuVuN2orCy+dcSyMTNeFYOORQ rXMp+ThhY0yp1pujrfaYk1QM+VgqsQSxZ5jaXkUUIc9WPptpNpuXPovSfTna7fauYLV6O+16 PvLe7+5Ou/bKx3hGbr6+Yul6VRj56OwTYyq3YwZ5sNC9/8XlZrzvS76RzN7GF/qDk2zJUtgR nUy77kQ+Om/K3p3FmWY+7Tr0QxF6k7s+7TrZ7Tod+mjudv3Xf64NgXzMd5t58/ptMuvZWjYx GfD46qChmsHq8tEszjHsMV7M0WcVnTPHXacHmsew0gEAAAAAIBjko5wi+WhOwbYnOLfb7dTE Wa/HYypzB5cquWjKnLudz7l2y0fndO+uyMeArb215tgjH9UgH0sl0S76vibtvWRnE698FLWK ZK+K5GOAonNWIt5wxtz/xXmm08h1Wz6m+6wstHbahXHVq4J8TIyw2Sd7m0lvp/ujxEXoO7e0 2zu3r86EuUCxMpa1DugIcRXHcsUGycdEl1p12WktXGoqu9UEfygCb7K4fmdInPLxReu/py9c uHBx8e6uIh9/aC1Mf/zxx9OLX+0MWD6KO7SIri15UT+4C/Lx7Zt08nUcefpzbAmta2r7XBf4 wdDTHXVwnA4AAAAAAJ2CfJRTIB+ttxzyse2UcfoV4tPXFyZzVxiLv4WpXNUNZtp12J7UeXOW V4vmpyMfyyUxVfngxb1nW1E6k9orH+OxXzNzn6892W232+3d7zda167EU3ED5GOySfHl69/s toNiVyKr/9+X1h7Goy/3nj1ej67NX7ujDumLzdHM1WjbUFw9ko+J6GrOzC62Nr6NRwbufr/x 1RdXr95Ui3LVq4J8TPe1bl76+1J6X56s34pvqrpdeVrFbOzi7pO1z+eSidR++RiPsLz0WbT1 bK/dbu89e7y2dPXyjPHgpJWZubygDo+1G+AXtQV9ECYf032tZ2YXW2mlt77659xMs9mc+Wwl e16CPxRhNzmZY+035EFN/fnnn3/++cX69b9euHDhwsX5L+4+/GFv78UPD1rX56Y/+eTj83/7 /N4Pg5aP5ai2FQwAAAAAAEAC8lFOgXy0rJxb6gXJx2x9SeWayfxlc0az5vU8G85YtTI3yLYa JWw4U7DSpdicIr+JfCydrZtz1sJ9lxZb0eJMwJqP6Tg5JTOfLi0vXjJGsjkUn7n0nbBFsxap Ejt3FsVVJy/9Y/V5flQymi1LNqm2V/Kxvbe5ZHdss9mcmVtWduJx1auKfGy3n937Qip75tOb mv96dtfuupm5pdbSlRD5mA4FVE++vLj8xafGKL+dO4uX7cooFlTfNdo3ArKKfGy3n4hrlM5c Xryjmc/AD0XgTdb2ZPeOgHTvY7N4p53Ix59/erFx48r0hQsXLly4cP78+fPnz3/yySeffDL9 91sPf/hhxOTj8UrZvVwAAAAAAAAEkI9yiqZdL68q86a3FyZbdW236/ys3OhtrtcLpmkLVs7e 0cV4xdB8wi7bsdNM7aFRTzPSJOu4RE2A5qs3OppjTipvb03nRxaqySHOwORju733aPWLz2bj LYtnLs4tLn+9vRePSgzYlnnvUetast3xzKXk3L07izO6ZHEpvr3N6LPLScGX5xaX1oo/a45K 7D5sXZ9PGpBc6KuH5iC7ndXrcxeTes7OX7+9+aywZuVqIF9lb/vr5cW5y8lG4DOXZuevR/fN oZdyvarJR7PsmYuXk1tjZmcjupYddXn+euvhbjwcM6hHdr5Z+ize53zm4t+Sk7eWrlgGUbtB zZmLly/PXf3iq+zzqzwFl2YXW8X/clBNPpqVmbk0m9TbSNCHot0Ou8nZPZ65eHlu6X67MGHy 8aefftp9svrF1csXp8+fP3++OX3xb1c//+rxs2fPRkw+avtcAwAAAAAAdA7yUU7xhjPKXtjG XjFbC9o22ckVNpa3FtT9WwTNZw6Q3Jhv2Z5O3QTGHudoDyo06qkuIilcWXpL33ZmdWF5a8Pb HH3bmen5rShtmrqH+AgNgRygfCSEjEpy+fjTT9Zu1z+OjHxUFkZkxxUAAAAAAOgKyEdCPEE+ EkK8GRP5CAAAAAAA0G2Qj4R4gnwkhHiDfAQAAAAAABBBPhLiCfKREOIN8hEAAAAAAEAE+UiI J8hHQog3yEcAAAAAAAAR5CMhniAfCSHeIB8BAAAAAABEkI+EeIJ8JIR4Myry8XilJmTlcOD/ d6SLnO7Xa7VaY38wTvZ0v16r1Q9OXAcctmq1Wi067lEFlP3Ke1gK9Iv4Ye74eQ48fVAfmax6 zkoeRTXv83wU1Wq11lFBQa8OGjXfMYXnNl6eui9b5Qa5Kx9/UYz0Z/mwNXb/4wIAAFVAPhLi CfKREOLNKMlH+Yf0+JAI1gH96D3drxeZgkQOFtjJCpy8bAzOukLPOGxVuq3+0wfzkTl52VA/ KUeRofB0jx+bPvOTlf1rikssJn5z5fDtm9enJyX7MFP5wnembtasyodQUPnjFfVqctuHnorP LQAAjBvIR0I8QT4SQrw5M/JxsL8nR+DX7Ol+vTd6N6DtR1GvtCa48ejmLtBz+Tgkbde/naxq m249HhtYPzg5bDnko28YsrdptdrKofiJtht+vFLKD/orr3HystHhyM0BEtY0AAA4MyAfCfEE +UgI8Qb52BdGRD72ZASZv+29t2AwkG4fafmozU0u/mhomk8w6doMaOWrzCG5Tl42OnbxiuyT 5OOrg4bVFv/s7xx/5aWbOGoi77DFv4UAAIAC8pEQT5CPhBBvxkI+SssRxmuurRzqiwlqSX8S 54uUNfZfqX8qv5l1E+GazKgeEksTf+nG8nD6D/XkrfrBib7MnKVCrDUxS/94dshHb8OtY7KL BLS9C0t5FvRe1i4thnJy3Dj5+navGqebB5ill9S7pSqf19z32MjdXsvvr3JWdKz+qT0AjtL1 A3oiH303vaDnvW3PHl2jPwsaon47CVozqa3tOmUxd7zSnYnkkny0uzT58Ja/TV0f+eiYo224 Udet7+ZXJfIRAAA0kI+EeIJ8JIR4Mxby8bW1u4L9Gztw/F3+61dVALoOsEYPxZZNfeUo0n9F h1kY+Yf6YatWb63U3cu0HbYkddL10UbyLTDbbu/V0MuRj8YYMWvQ2fGKIRdeHTSUyvhunHG6 NRnWbJqhe6x2lRsFFlJ5sy3aR6D4sQnp9kQvKiY9rY+n9NBbX0jA6Y5H3dvzhW23b5M0YNBR B/NjEj9R8sIC4vMQmy9V7FaYf23cEbO74ifqsKh1hXfH+zCXG7Eu3U3tCp7P+7B8VQIAwJiB fCTEE+QjIcSbUZKPZvTf5LkNEU1BmAIzzJHjZ7P+lrSrbJflo9EcrYHCkm19lI/Ci+ak0X5O u9aFiDCfVPV3vhvnUiGa2igQQ4XGyktI5Yvmz3oem7BuNwRT9mfg7N1ByUd/zxe0PfQ5d7yl /Zk9TuHy0R4mWWZatNnGIvmYPU6dPagB8rH0F5H9kdSFu6cOw/JVCQAAYwbykRBPkI+EEG9G ST56R9AcRbV45ItjhmMp+eg5Mi8ixLBUlY/u0UCSOOiffBTbJRiBzuWjPsvSnB5b2M8+ueap mHi6/pCkw9Mc4iYdS+sSlPp0dX0aaUeVV18sfmxCipAvEla6t4eL2h7+5BSOfCwaM+huu3sq tPTg2TvDZEf6FoKUyxIrppce0nXppZzyUS1a/w4J/cR55aOtAgMwOsqz/KXxhAzLVyUAAIwZ yEdCPEE+EkK8GSv5KMxUzagoH82VAYvHx3VQuvtSxb+opV/4/ZWPYgwj0LuRj9aqiHlZnmfG 10v2lc1bLxwmW2+pWzrobW/lVb3SS/kYOt5wYNOuvT3vbLtiu8zR1vbtkMYkxl8jx54J+M7u DdyiOgTXmo+to9L/PFDi2VAfhk62CLP+/UC/SMHnfXi+KgEAYMxAPsrZmG+dm4g0pra6dcH6 /Ha36kn6EOQjIcSbcZKP8SikhrhrQSX5aP5qtYe/MfKxSts7lo/iIozVBg9WqZW08ZF5wVDL M+4jH0P7s4J8LOp5Z9vTidLGFF3h4XfNhs62unL3fEH3OsfbdraFlLjbtbRgRfmviwL52LF5 NHvA2Hun+PM+PF+VAAAwZiAf5WzMt85NrEbZ35vr9YlIe6VUNtfrE9H0cpcqR/ob5CMhxJvx kY+5CxB/+oYtAycWYU2ZNI4MEKNhq6p1Ih+F0mPVMrA1H8u3vVP5KA+1yxvuMwsVh0Y6TimS RCU2MvaULj3k2il++ehbs1K+SFjp+enDIB+Fnne1PZGP5qMleVtX3cIlrNS9Qos6dHmBgyg7 /fQVielKS7jKc8Nf+z/vQ/NVCQAAYwbyUY4pH9uJQOxw0OLy6rmJ1sJmd+pG+hzkIyHEmzGR j8beu9IMO/N35lEkHCAWoV/c2BQ7O0D/vf3qoGHvrltUenadsvLR3LI5qcygdrsWBFxQz3dk K/ThafrWzPkBuvc5isyuc984exa/teGM1s/C2nwVttYNqryxz7g+INcjH81TXh00DB/nHt3m KV0o8XQ/Kjt2z396wQRwT8872p4+vdqjFQ9mzGviGcFqDNBzf3e515c0Tu9ow2vHF5r+3dj5 0D/XVt0h5jFZttJVbvIpM7ft8n7eh+WrEgAAxgzkoxxBPra3pieic5PrGx1cDvk4ykE+EkK8 GSX5aCf+VSnNczR8QYy5PN/Jq3wtMCvaL1JlE4bG/qv0T9UImLtAtI5eHx8J9tMqXdrhQatA gEVKf0WnV+7iXEJhdwurY40OrB+cvDrVXYmr7fJtLbFJhVq9dMBazR7jptf85PA4+MaZa8yt HL7NKn90KLyb35TD4xO7Z0r2v6fyBcsahshH+wqH8Y2T17v0nOscBpg1v7HfyZbKwunFH5nQ nhfbru/ond1W5SMvP7TubwzH3Gcjeg21Bpb08mLn2HtAi9Uu94mzKq99EamdKz85ToGbNcH8 Kij+vA/2qxIAAMYW5KMcp3yc2mq3txcmo+nldjQVr+GYHba9MBlZCztqL6prR6anmwtKRlNR fX47XSMyV5YFx08vx37TtTzl1nReAdWBqq/rs8LVq3XmW8coA5SPe3t7Ozs7T58+fTKOefr0 6c7Ozt7entj2Fy9e7OzsbG9vPyWk79ne3t7Z2Xnx4kX4w5k92I8fP378+PGjR48ePnz48OHD Bw8ebG1tbW5ubmxs3Lt375tvvllbW1tdXb1z587KysqXX365vLy8tLT05Zdf9kc+Qgn4RQ3Q KYF7W0GPqThnPwy+KgEAIADkoxxBPi6vpkox8Yn6Go6ZmjQOzv5Urd/2wqQi9eIFJXUpqc/v 9h9vvJufrh/cXl5NjtQPi11n0iL7rWqb7Yx6ngxIPj5//nx7e3t3d/enn37qc9H9yU8//bS7 u7u9vf38+XPjrefPn3/77bfPnz+PvzsI6XNevHgRP4TPnj0LfDhfpNnd3Y1HOz5//vz58+c/ /PDD999/v7Oz8913321vbz958uTRo0cPHjzY3NyMXWQsIr/++mvk49DhX8sPABy4hNTJywMs VV/vQu+/xPiqBACAAJCPcuQNZxLBt70waY4utGVlNKUIQUM+WrOw1dO1EwOP14rWTKVwNfl1 pVFMEtczEPm4t7e3vb09rtpRzc8//7y9vb2njH988eLFt99+i3Ykw5D4UQx5OJGPY8Dxirnr QpmZywCgY63kkMxDZ0RkvyixNVPJy/JVCQAAZUE+yklnPYuzkm35KOjIAvloC8Fi+VjheH08 Zp6taXFwZXJkhdUtxzEDkY87Ozu7u7v9LHGA2d3d3dnZyf7c2dl5/vx53y0TIUKeP38e+HAi H0eek5ethrZCX8/nKgKMP8bihhW2b4Zg8vU0e+F5+aoEAICOQD7KkdZ8zOKQjxM26RVs+Sgc nBwgy8SyxyvyUdqhW1vtUVreMTvA1QlnKAORj0+fPj0Lwx7j/PTTT0+fPs3+3N7eZtgjGZK8 ePFie3s75OFEPgIAAAAAAIggH+V0Ih8LFkb0jXxUEzLyMfj4IvkovS5d3Fzd8sxlIPKxd8/2 cEZt79OnT/vrlwgpimrGCx5O5CMAAAAAAIAI8lFOJ/KxYJ6yMPLROaLQMfKx5PEB064Dt5Ep Vp9nIcjHPgT5SIY2yEcAAAAAAIAqIB/llJSP8fHuTVqEDWecwwkdG86UOF59xSUui4Wmpz5n LMjHPgT5SIY2yEcAAAAAAIAqIB/llJWP6SKJ+Skb861cF5r7R8drRGo6MpsELcm+csdrr2j7 dLfbm+v1uObG6+12NJVef3lVaV3oBO0xDvKxD0E+kqHNmMnHfCMCNeO1UWm8o+6g9kA43a/X avWDE9cBh62ebrtx8lLZ3mMINvfI6jMEz5j68NuPR6ePTXxDg3o72eu5qw9ndk3nleMtp4sr eRTVaur+xTbJvjGFxxSeK+98om1H02G3OCuf3Zqh+TiUho2kAQBgfEA+yikvH9vmtjOT6wvL 6TGmfGy3zW1kVheWt/KxitJIw/DjzVdiz5htUzO/lbZL33Zmaj1a3m6329HyutaQsNnZYxzk Yx+CfCRDmzGUj73Y/3SYSBzTgH6xn+7XizRHIuMK7GQFTl42hnLn2eOVwQuU4xWPfqry2Hhu usZhq4v36ORlQy33KDIUnq7CY9Nn1jNzsi6xmPjNlcO3b16fnpSseWafha8d3axZlQ++rXLl j1fUq8ltH3q6+rQAAAAMFOQjIZ4gH/sQ5CMZ2iAfdQb7Y3gEfoqf7td7o3cD2n4U9UprVqOy fKx+318dNHooQAcmH8Wuzh8/qyxTT8djA+sHJ4cth3z0jeT1dkuttnIofijsTvMKYrsniyuv cfKy0eHIzQES1jQAAIBRAPlIiCfIxz4E+UiGNshHHeSjh9P9em8kl7/tZRRYXxkC+djbJ6fH 8lGbm1zck5rmE2S0NgNa+TZwSK6Tl42OdbYi+yT5KOlg/+zvHH/lpZ4fNZF32BrKf04AAADo AOQjIZ4gH/sQ5CMZ2pwl+SgtRxgvGLdyqC8mqCX9PZ+vsNbYf6X+qfzg1zWKayamekisafyl G2vb6ZYheat+cKKvkWd5HGtNzNK//B3y0dtw65jsIgFtr7CUZ1royqHe+ZK0Kqq/48Zl1VMr k7RIfdI6b7sH+QpK6woeG/P5EXsmvelu+Wgsy1gz5aPRdfr1jbGKvrnJ6gdcqFXSELuqspjr 1nx5ST7aEjZ5BjpbdrOrIx8dc7QNN+p6crr5bYN8BACA8QH5SIgnyMc+BPlIhjZnST6+traG sAVB4Pi7/Ke76i90l9ydTQkAACAASURBVGENfYo9kfrKUaQrgLBRY7JlOGzV6q2VunuNucNW Te+c3szTlG+B2XZ7o4kejnxMb1muOY5XrD8r3Dj9dHkucMW2+wi4guN2G10hTkMu6HlrKrFR E7NiuqeztVrh/HG9CeaTFt8UeW6+6O9i81WgpMs8YMYzb/b2q4NGrbF/2NHs+CD5WG7Qt/Qw aFcwxoSavTos3zYAAADDA/KREE+Qj30I8pEMbcZQPhaMAnujjrQSNUeYAlN+VBesgai/JW2J 22X5aDRHa6Cw3lwf5aPwojnjtdfy0fBKRdvslr1xinwULtuVtvvoVD66JJTeBGfPC6ZPr0nh Mp2hj4rjLe3P7I6Ey0d7mGSZadHuB8bu2Ng8ur5zgm6up1alP8v2U51VMqQOw/JtAwAAMDwg HwnxBPnYhyAfydBmDOWjd/jPUVSLh+04pmeWko+eI/MiQgRTVfnoHsokWY/+yUexXYLO6Fw+ 6lNEa/qoK/HEgkel7I1LbZ2kKbvQdn3KtjEHNvzJkW632DP2E+7q+YB7nY4rFIybeyq0dF9s g5wd6VsIUi4r4KkI6Xm5x5TeVovWP4aFD623o4wDSjtNo6M8y18Kt3UYvm0AAACGB+QjIZ4g H/sQ5CMZ2pxF+WhNNVWoKB/NlQFzuxH027t38lHSE/2Vj2IK5ufKPd/5yMdizVTpxinjbWWd Xb3tPqrIRzFaQyrIR7sUtWOTz6A5YNn+fEljEuNP4rE9EjlszcfALapDHzCpH1pHpQ276+a6 n0BReZd+ZhzGueiJHYZvGwAAgOEB+UiIJ8jHPgT5SIY2Z1A+xkOoGuKWC5Xko/mT217ejpGP VdreVfmodkjVG6eNfDQL6t59r3iF4JGP4T1f/l4rmz6lE6WNKbrCNV2zobPdojxVeh0+8lFc 8jLoARN3u5bWfCj/iSuQjx2bR7MHjLn2Vj8IFnUYvm0AAACGB+QjIZ4gH/sQ5CMZ2pw5+ZiL DPF3u39RNqd8tOZ7GkcGiNGwJeE6kY9C6fHIpoGt+Vi+7d2Uj2ofVr5xirgRHqqu3fciurnm Y3jPC6rO2L1arkb94CSTj2bbje6Kn1LHBcM3jJL8ndD2Dl1e4CDKTh9gl3xUTG5nyHPDX0sP ZCn52L9vGwAAgOEB+UiIJ8jHPgT5aGfjxmyz2Ww2m7M3NgZdl7FI1qELrVLnnS35aJoRYXqg +SP5KBIOEIvQL25sip0doMuCVwcN7Qe5t/TsOmXlo7nnclKZQe12LawxF9Tz3ZGP+la8lW+c sFm2tc9vxbb76Npu11Zz7HMPW8bO3doiifWGtayhWmj+eKSdoI18jAczphcsNI/ZAfqu5WWW TRQ2Pe9ow2vHd4L+9dL50D/XVt0h5jFZttJVbnKvzZ2vjOGoydIBwdOu+/dtAwAAMDwgHwnx ZFTk4+3ZP2r5+NpmL2rWm3QsHzOhlHu61kLTFc06GadKTso6pI8icKPVStrS0zLj3joLfjPv 0D7Jx4fzv7v523du/vadpQ/eufHBO8tX7nzX+uvS//7lP3/zy3/85peLv/7Fwq9/cfVXv/j7 +/8y9/6/XPl/P4n6Jx/txD+JpUmahuyIMZeoO3mVL2RmRfs5rewg0dh/lf6p6gxzC4vW0evj I8F+WqVL21NoFfDpgDe5Akiv3MWJkMLWHFbHGh1YPzh5daqLHlfb5dsarOcKV6/rwo2zbJ1t fDpvuwftnqrXF5pm1N/ZPyuHb63S1WMajciYkKuWq9rb46ND4eLKifkY5OxdpfPl++7+0Dnm Prs7x+yfkmpb7FvpSRCq3eFnKq28fN+dy606BW7WBPPTpJaeDlCtaSsVDO7bBgAAYBhBPhLi ySjIx81rH//xj3+cva39PUr2sdrIx9gRakrJtnYbN2aVQ8z3bSmVOEz1tdZCvzVdz+VjqldL +riRTT/l44/Pnz9/vnb3T+8sffD/rykjH7/+67/+4ze//OKqMvLxb//eP/kIJTgzOqDjIZPQ UwK3h4IeU33J0QDOzLcNAACcWZCPhHgyAvLx9qymHtuxfcxeKK0i++8u+yAf9zZuLKR/b9yY Nd9tLVgu0rZ++kF9SFflo9DqM5chlY93Ll9tXOnTtGsogbXW4biCfBxSXELq5OUBlqqvd6H3 3wNn5tsGAADOLMhHORvzrXNTW/LrE6tRj0olQ5nhl4/muMd2u92+PZvLQ+SjGVFNzmYXiK8n nd1a6O8QQeRjlzOs8rGPaz5CAccr1kTgSpucjAzIx+HFWgwhmabNiMh+ISzx2aXLns1vGwAA OLMgH+VszLfOTUTTy+LryMezleGXj8lyj6ItNFeCzCVlrCytFSLlE9JX9dGURqH6qaXkZZ/l YzLZ2CGh3O4xqB7q6pDqK+kF89fiV/Q1KvU6ac1IDzQkqV5Vx9XshTAXWs4tWPSlLq0BofHh yhVdMk+rX3y8XCHzAkZt8xq4+qqoJHvhTuQjiJy8bDW01fd6PtFyaEA+DjfG4obcqX6Qr6fZ C897hr9tAADgzIJ8lBPLR9szIh/TbE1PROLg0PHLCMjHXCSKxk8ayHh7Vjnau2Tk7du39bnd m7dvb+pHqdfYvPaxORLTk17Lx40bs9Ysa6eIMuRVYPQSlb+Ey+XV0atuKVP1hVarpQ/c22i1 NvTRjMVXs0Y+ZhdQa6efpWnavAYLC+kpRaZ2YyOt3420uxUlmzVDr4HQhvgP4zhtZryrJKvz h3Hk45X/M1e/jHwEAAAAAICxBfkoZ2O+dW5ydXrS9GvIxzTIx54XWvIMddih4f3EWdS3Z922 0XWCfmXtKMNfqrO+Q9Ib+egYPqeeJLzX0cBHW+zlL1jVU1WorkVNN+bdF8cot/Bq4rRrSf0J nla3qtY2PL7Bj9oVrRPchlFpkV2M5DCFkorLDkhv5KO22zXyEQAAAAAAxhjko5xEMi6vnpuI 6vPb5uvmkVHC5PpGu52IueS/42wvmB7TLe821+vZBe1jtHfVmmxN56+3FjbF17WJ5NGUUUn9 leXVc1Nb+ulJcVqTzeLGMCMiH9vttmYgFU3oX8LRUIfSCfZr0sjHcuMd8/R95KN2pi4gZflY NDlaqoH6ii34XGpTlI1aMyRTGni1APkoHmLP/bYdoKsKXplpvOKUg9IbWt2DShoi+cjIRwAA AAAAOCsgH+VkkjGa0uSaIR+jKdUA5s5xY76lKbnEGCqucHO9Lju7rWnrxNx+6jI03xUnvn6m KZdXE4eon24sZOmXj5pY3F6YVI9n5GPPC+34XGs5Rpd8NJd3rCQf1UUkyxvIPq/5aMRYTNE9 7drp2ex1BXVJqVZH3dpGPLmafHRfLUA+it2mndcl+WhHmJDtrKZ2qZGXj6z5CAAAAAAA4w3y UY4iGbVhjJp83FyvG5vSLK8mts62flOr08rBG/MtQ/w5og6ZtIdPJrE1out19ZUQ+ai2Tjeq yMeeF1rl9NgDalOidZdojFMMmHbtl4/qhctulj1Y+binC0f3vGunZ/MWlx+gu0dt5ULvtGuf fCy+WiX5qJnZKvLR6RcL3yyQj+rqmd6SkI/KLgpqxmuX1Xg74EFt4HC6X6/V6gcng++HMhy2 2MxkuFE/ufaz7Xrmk62xB7yfCVs5AwAAAPLREU0yKuMN1deF9R8z+aiNE9yanojq81vKK9sL k9psbncU4WiMgszj8oDC66pADJCP+thM7RXkY88LLXH05rWPpWUeU7fo8Ibl1nwMlI/tdjsd Ullm/GO/5WNroWhusXMzbM/IxyKplZ4quMfwNR898tFztdBp12Y7ej7tOuRN6Y0xmXY9APnY i81bh4lE0wxIdozuztGjW/Ox53jF44ULn/nD1hDIR3ZzBgAAOOMgH+VI06tbC5u2fIxs4tGC ueZbXk1O0cZFFqyTqK3SmC/7aA+0VI53SUnzdUUgIh8DMwLy8fasOLDRMa6xbex1bf8dtOGM PrqycAMbf/oiH3Pvt3FjVhoRlx+fTA0Wl3YsWDyyaOxjfO7CwoK5K42pB8tsOKMV67tayIYz wpRzYcOZSvKxeDdxl30UOti7XKV9jl8SC+mLfLzW+OCfIyIfB+sRRsBinO7XR1TvDrF8HOr7 3vt+e3XQqCLTi3qvLzf9sFWrtY4Gf6cAAABggCAf5VijGpPJ11HxyEc16UDFaCqTdIkNLJpz Ha/emL9rjnzshnxMLoJ8DMzwy0dT9cUDD91usW2MTbw9Ozs76znBfHHz2uy1a7PG1O7UPoqn F6Yf8rG14Jo7LI10zJZOdKk+uRL6Ls4t+4oFemzjxsLCwmyhfNRf2LixcOPGgvp3yatJfSdN 3S7ab7u8fLTK2Nvb22i1tP1+1DeT94wODlKrekEbNxZmh1M+/uMv879CPo5A6UGc7tdHdIYp 8nFY+61i84dBPo7cQgQAAADQZZCPcgSxGLu/qVVdPhYMYIy94frCpLnHy8KUc861VS7Trgef 4ZeP6l4v8oKL2vvxm8pLs7ezvWc0l2hdTdmh5uNrm9pJxuY1Zbec6Vg+GturzN7YcG1okr2v WKk8so+y9pHxaCvjqgs3Nswhf7aky8+JJ2VnBWkXywtWXlZbm1zYeTW7PbM3Wvqfue3Tmi0W bZfndIzyu+aNW2htOE5U33NdsaAkvb8kp+xLp/Lx4fzvbv72nZu/fWfpg3dufPDO8pU737X+ uvS/f/nP3/zyH7/55eKvf7Hw619c/dUv/v7+v8y9/y9XfvWLxSGQj/HCf7qJOIqS6ZwnLxvS cpG1fExTtm5gbDryP5VBT68O1KsINcnP0taq85eeVlUoNHurfnCSr4InTlO11sQsLU2K5KNW Q/XKhT3v67q4xLRdWhtbRyXa7vFQzsqH0VnbQ+6793YkiY7VP7VnT3vqck+Xlu56RV5B1bx4 ha6Tm69coeCZ11tny8fKlQ/5vGdHIh8BAADOOshHOeKoxnSetbbhTMHSjebxbXsLaTP69tlt 3fEZ+00XnOV8XdWLrtGdyEcjoyAfRz7VRj4S0sNUGvn4/PkPP/zw/fffKyMfnzx69OjBgweb Q7rm46uDhnqArS38g7BSv5PopOOV3HOp/y1MJo1Vi/rKUaRrqbAhYCcvGw4D0lpRzOBRpHml 2J6onSNfp0OOVzR3Y+1L4+n5gq5LOnzl8K2+9p9yr1MxlF3B7upC+eirfG/b3o2Rj0kPKC47 rcDJy4atF8tUpljaVuy60OYXPaudj3wMqXzB5x0AAAAgA/koxzGlenthMrLWglSmQm+u11Uf J9hJ8wpmlM1t2u3thclWXd3hOnaXyp/JkcZk7awa8ev66XlttT+3Fyaj6anVYPnoNKHjF+Rj H4J8JEObMZSPBQOp3qguRlxpLkw+GuPyHLpTf8swUK/fvum6fDSaozVQ2NOji/JRupSpaTw9 7+w61R+pekh5Xdhu2BZJTg8VUvnetr078lGpQ/anVNxRVNPH83YuHyt2XXjzeyEfwyof/nkH AACAswzyUY5zPcfN9br+ur7tTGthfkufNG0OctyYbxUPGFQuqO9XEycZOxmzurC8lQtHuRrq 9jVSZdR9ctTWeeSjXpOxHgKJfOxDkI9kaDOG8tGrBo6iWjxIULASpeWj58i8iBDBVFU+CiYl qaokobonH0XFI3RUUc87Lxjw31K/Wa1zeaiAyutTwvW5t91oe/F9Lyq94O67r6y+WEk+Vuy6 sOZ7n9UO5WPgjcM2AgAAQAjIR0I8QT72IchHMrQ5i/LRmm6pUFE+mks65nYjyPT1Tj4KYwO7 LR/FmHKnuOfFc/siH4Mq39O2d3XkY/EtVk10dfnYedeVaH6v5KO/8shHAAAACAH5SIgnyMc+ BPlIhjZnUD7GE3IbDVGRVJGPpuDTjzxzIx/L9HxR13UoH4+iwGnXFTdErtz24Pvue3KGZORj Z5UfkpGP8mHIRwAAAPCBfCTEE+RjH4J8JEObMycf8wXvpEUYSy5HaF3Zsl3KkQFi1F/62zed yUeh9HjkV+/WfCzR84Vd15l8dLQ3dM3H/rU9/L4X4ZKPUnFahV8dNPSuM/cpEu5O17pOqXyP 5GP1yiMfAQAAIATkIyGeIB/7EOQjGdqcLflo7Pzr3KhEURJHUfEGFK6LG5vkZgfo/uvVQcOe GlxUenadsvLR3AA6qUyvdrt+a+zdUdzzhV3XgXyUvarWb4ctpWM9le9p28PvexEu+Whv/G1u eq7tRHTyslGLWivCWEh9Gce8sRW7Lrt+BfmoPeen+5GuGqtWHvkIAAAAISAfCfEE+diHIB/J 0GYM5aOd2B0cRTVL+iQvSkMC8wXgTl7lyyZa0YRIfLW4zP1X6Z+q3TD332gdvT4+EjyUVbp2 cakCPvn4JheO6ZW7t9u1UPNabeXwbVz5kJ53d12gfNTjX+av0YisSdlS5fvQ9uL7XqrcpG2G LNP6x9J86jMZHWcfIu0ixhUOT7vSddoDmUX5vHieebF69ca+sJl4+coHfN4BAAAAUpCPhHiC fOxDkI9kaDNm8hFK0G35ODiqr5kIAAAAANA5yEdCPEE+9iHIRzK0QT6eXQqWwxsxkI8AAAAA MEiQj4R4gnzsQ5CPZGiDfDw7HK+o4xyFlQdHFuQjAAAAAAwS5CMhniAf+xDkIxnaIB/PCicv Ww1tebsxsnXIRwAAAAAYJMhHQjxBPvYhyEcytEE+AgAAAAAAVAH5SIgnyMc+BPlIhjbIRwAA AAAAgCogHwnxBPnYhyAfydAG+QgAAAAAAFAF5CMhniAf+xDkIxnaIB8BAAAAAACqgHwkxBPk Yx+CfCRDmzGTj8crNSFjsqdzwul+fYDbxZzu12u1+sHJ4PuhDIet5FGIjgdfmbEifhq9D+Ro PjYAAAAAoSAfCfEE+diHIB/J0GYM5WPj5emg/89HT0kE64CM6ul+fUQV3ujWfOjx7zZO5wMA AMB4g3wkxBPkYx/yRAnykQxVnj59GvJwnhn56NcovWSwpQdxul8fUb2L/+oZYfJxNB8bAAAA gBCqyMcoim7cuLG8vBxF0e3bt+/cuXP37t21tbWvv/56fX39/v37Gxsbm5ubW1tbDx48ePjw 4cOHDx89evTo0aPHaZ44UvOqCuQj6VsGIh+fP3/ez+IGnh9++CH776eEDFlCHs7sf8Di/3l7 9OhR/D97Dx482Nra2tzc3NjYiG3j2tpaLBxXVla+/PLL5eXlpaWlL7/8Evk49KUHcbpfH9Fp 7MjHnhEmH0fzsQEAAAAIgZGPhHgyEPlICBmtxP+rFv8vXPy/dvFwyHgU5LNnz3744YednZ1v v/326dOnjx8/fvjw4ebm5v379+PBj/fu3RsC+Rgv/Kfrp6MomcJ88rIhLRdZq9VaR+rp2fJ2 +Z/pAa/fvnl1oF5FqEl+lrZSnr/0tKpCodlb9YOTfA0+cWq2tSZm6WX4iiySVkP1yoU97+u6 uMS0XVobW0cl2u6Rj87KFxJaut669N2CKulvOR4b7eAsZQVrpw+tfgDyEQAAAM4yyEdCPEE+ EkK8GQv5+DrxLPkBtjQJXL0uVzzHK7lLUv87KUsVLrFhVF85inRVFDby8eRlw5CPybn11oqi eI4i3RMdtgy1JF+nQ45XNGdnbTDi6fmCrks6fOXwrb7epXKvUzuWXcHu6kLT56t8Mb6eNytz 2Mr+PHnZcBSUd4jvsTleqVl/lritlR/a4OcWAAAAYHxBPhLiCfKREOLNKMlHM7rcOXnZSESJ 5VnevO5g9bqCxez0twz79vrtm67LR6M5WgMNReW+TkdIl9KtlrfnnV2nSkNVCyqv220XBKJT PoZUvoiAnjfue+4cD1vG0NrkrFcHDaWvCh6bo8jypNIpwZR/aF8jHwEAAACQj4R4gnwkhHgz SvLRq12Oolo8VE1QUd3cOsOeOesTNFXlo2DQkqpKvq978lH0ekJHFfW884IB/y31m9U6l3wM qLw+MblmDC0s7nnxnmanKPflKKo16g2lRa0j/yPhrHz+YnHlqz+04YcBAAAAjC3IR0I8QT4S QrwZK/loTbNVqCgfzdXxco8TZPp6Jx+FsYHdlo9iTC9W3PPiuX2Rj0GVL7hrnp6XElc4e5yO V2qN/cODRq11pAyN9N0j+YEXhkN66l/hoQ1+bgEAAADGF+QjIZ4gHwkh3oyTfIwn5DYaol2q Ih9NwacfeeZGPpbp+aKu61A+WgKu1MjHMnQw8tGoZ3T85rCV7Vqzcvj2KAo8PWDko7/y1R7a 8MMAAAAAxhbkIyGeIB8JId6Mj3w8imrqjFfz4HLLEVpXtmyXcmSAGPWX/vZNZ/JRKD0e8de7 NR9L9Hxh13UmHx3tDV3zsQyle14ofSW1jScvG7XoQNkb2nN63qtFbS+8KRUfWrn/AQAAAM4U yMd2e3N+ckLP5PxmF65LxiTIR0KIN2MiH/M9T+JXXBuVKDbnKBIOEIvQL25sip0doPuvV8k0 2+DSs+uUlY/mtsVJZXq12/VbY8+W4p4v7LoO5KPsVbV+O2wpHeupvIeSPf/G2OQ6mfWc1j9Z otHcLNv92EhbdQff1m48tEZ7T/ej4BnfAAAAAGPCWZePy1MTdnCPRA3ykRDizSjJR2F1vZen b5IxYqZRil+UhgTm69+dvCpYvE+zMPHVMpeU/KlaLXP3j9bR6+MjwX5apWsXlyrgU2BvcuGY Xrl7u10LNa/VVg7fxpUP6Xl31wXKRz3ypGO1ho1GZE3KlirvJ6DnzRrWD05enZ4oB3vsoeex MZ+ZUjeuGw+t3sB6Yz/Q2wIAAACMCWdaPuZDHtGNxB3kIyHEm1GRj1CCbsvHwcG0XwAAAAAY JGdYPmbqEfNICoN8JIR4g3wcQ8rtiTzMIB8BAAAAYJCcXfmYucepZdch8ZzsyfnN9Nj0UG2y tuIuzeOMF+LTppa1VSbV4vVJ4EjRIQnykRDiDfJxDDheUcc5CutdjizIRwAAAAAYJGdXPqai r0DxmQtCTs5vStvT5AYxSD66zhYujH4ciiAfCSHeIB9HnpOXrYa2rOEY2TrkIwAAAAAMEuSj e+BjLgvzY8zxkvrfofJROtk6t725iXociiAfCSHeIB8BAAAAAABEzqx8NC2iMSpxajl/TR1/ aL+kSsww+WifPDm/yRKUwxvkIyHEG+QjAAAAAACAyJmVj+a06zD5aA9P1F7qVD5qxWlVIEMQ 5CMhxBvkIwAAAAAAgMjZlY+ODWeSlwchH9vWuo/4x6EI8pEQ4g3yEQAAAAAAQOTsykfHPOdi +djladfp2+ZM64CduEn/gnwkhHiDfAQAAAAAABA5w/JRneds7Sjjko/FG84YIxnzcYyyfDRn fs9bVhL5OAxBPhJCvEE+AgAAAAAAiJxp+WhNczYmPAvy0XGKY9r0xMTk5GR+CWNRx/SQ+PLS dXGPQxHkIyHEG+QjAAAAAACAyBmXj+1223aCmfIT5aN1hvG28p5iMKUdZXS9uLk5z4Yzwxnk IyHEG+QjAAAAAACACPKxj3HKTDLUQT4SQrxBPgIAAAAAAIggH/sY5ONoBvlICPEG+QgAAAAA ACCCfOxjkI+jGeQjIcQb5CMAAAAAAIAI8rGPQT6OZpCPhBBvkI8AAAAAAAAiyEdCPEE+EkK8 QT4CAAAAAACIIB8J8WSA8nFvb29nZ+fp06dPCCHDncdpHj169OjRo4cPHz58+PDBgwdbW1ub m5sbGxv3799fX1//+uuv19bW7t69e+fOndu3b0dRtLy8fOPGjSiKkI8AAAAAADCWIB8J8eTJ gOTj8+fPt7e3d3d3f/rppz4X3Yf088Pb5y8KmjZyZXWluPCRj2tra4x8BAAAAACAswPykRBP BiIf9/b2tre3x1I7xkFjjVxZfS5u5JqGfAQAAAAAABBBPhLiyUDk487Ozu7ubj9L7HPQWCNX Vp+LG7mmIR8BAAAAAABEkI+EeDIQ+fj06dMxHvbYRmONYFl9Lm7kmoZ8BAAAAAAAEEE+EuLJ QOTj2D/baKyRK6vPxY1c05CPAAAAAAAAIshHQjxBPvYiaKyRK6vPxY1c05CPAAAAAAAAIshH QjxBPvYiaKyRK6vPxY1c05CPAAAAAAAAIshHXzbX6xOrUaVLbE1PROeqXsS64OT6hv5qNBVN L+svLa+em9BfXF49NxFl1Oe3u1ap8Q3ysRdBY41cWX0ubuSahnwEAAAAAAAQQT56sjHfMv1d 6cTysbWw2a1KtaMp22ZuTU9E56a21Jc25lvKYdsLk0Y1thcmu1mrcQ3ysRdBY41cWX0ubuSa hnwEAAAAAAAQQT4WJxZ2ptQrij3YsBdxDmlUjeT2wmRec8lXkqCcFfl4Z7HZbDavLAU/65WC xhq5svpc3Mg1DfkIAAAAAAAggnwszOZ6faI1PdUqoe36Ix831+v6pOloKqpPrda1gY1b09kx /anVmGYI5WPsCTVRuLV0pZo7TC7QXLzT4QXKJejDq6wS4Fo9IOSpDvuiSP+lQVrTYGO+Zb9Y qThHE+Kh1ueCx0pXaVo0FZVdhKHSXVMq07WyXHdtc73e96bd/3Tl3MSt//j0KfIRAAAAAABA BflYlGTa8uZ6XfwVra6fOLm+of4M1n4Mby9Mpv8dn2KMo1xeVX8ea0bAOeJSuWa7HXvG6WXF NiaXTfxFyLBHxXqUGel5BjKE8tEephirw34NW+xC/B/ezfVcpisPs/P1KmXFn5HksdeGDOd6 q4vysaBpaSn6mgkVyipqWpJwtdp509TKdM8GOptWfq3eak2LH5K7txj5CAAAAAAAYIF8LEi2 iqKwwYuxFmQ0VTDGUBOFtgeMpiRN2U4H7zg8oOYm0l/FyqXUAwxTKUWvdt4cMqTy0bCPqntM hzBqdvLOYrN5ZelO/NbiHe2gZLBj/FI+8DEZXqkPh9xautJsLt7J39RKsIqt0MCN+Zb68GfP pOv1KmW121vTqkvK1dX2wmQ0vdxuL692UT4GNWF5tUvy0dU09ZXQtV8rNi1+N/DrpVLTeiAf C5oWf/HeZ9o1zdlnFQAAIABJREFUAAAAAACABPLRHcXHbcy3zrlmNLvPSqO7P32cozU5WrMA RaOfjOrlIyuV0Y7JT2V5d2w1gcOszmaGUz6m+nDxTlv1hppUVLyhYRLVP+2LGMfbhtJ1cgn7 6G2g6K0KXq9SluWqdKvV7rJ8DGlC4GjEyk1zf5V1VFxR09I+7Jp8LGiaMu06sHWdNy21t6z5 CAAAAAAAIIJ8dEYbomissViwhKJXPup/qlpTHbfYzt91OcFsYKayhlo+QzyeiK0caVTA+GVe OMryjGdI5aNiH033qI2HjP+IZWI6gFGcpK3KR/1w5S/tTOUP/YQuNNBcGTCVca7Xq5RlDzNU Pz7pAV2TjyFNsCrQYVmepimLPAT920PnTVOq0TX56L1rbfUrsWJxhU2bbNUnonMTt85N3Dr3 l03kIwAAAAAAgAry0ZVM7cWxRy86Jir65aMqHO0NqW2cMyITWanNmkwvaL8oqBP953Q2VihY spyRDKt8zIzfkukYtShvKLaxeNq1KSfzs/W52epVuz3t+iyPfFSGLVcty9+0rMRuDLSUm6Zv /xK4o043mxbQmR3fteyfiH7++eeff95sTtz6j0+fIB8BAAAAAAAykI+OqJvJ2L+Wq8nH3Gzq o3ICf/9nSX706sN/4hcX9LFUjg1nxG1n43GRoWvAnYUMr3xM5N+VK8ZYRGEAoikfhTfskY/p 8dbIR0k+pnFWoWQDh2PNxzR9XPOx2ztr+5oWp0tLTIbcnX6s+agX1xX56H0g4/9Vu/WXW+f+ soF8BAAAAAAAyEA+ypF+rxqLM3Y87Tq9fqgidGdzvT7Rmp7Sh01trtcnWnVjT1u5wqJ8bLu2 xD2zGWL5mA1g1DeEsZdqNDVhxTUfbfnY/TUfNTWvjuR1vV6lLF39Cx//rsrHoiaEScASZXmb 1m6Hf+QrNU2pTzd3uy5uWvB2OtUeyGzNx83mxK3mTaZdAwAAAAAA5CAfxcgLrily0JiUrSRM PmaKUPsRXuA03fWUimvVJ6U6mFID+RiUYZaP0jhDzRsuLt7JhzJmSlBXhcnZ4btdC/JRKzRg 1nVYA5UByOYKjOLrVcpS10JVP63GIOiuGLq23ISN+ZYx2trbuipN09Z56NYs77b/7nRRPjqa pi5r27WNvNttd9OSeeW3zk3c+o9Pn7LmIwAAAAAAgAryUYhzmxdz/+v8J/TGfEsZEWP8tBaX XHTawHP6MKjiX+niYMloSvrJnfw8Vl/P5ePGfMtY/LGMAx3zDLV8HNn0s4F97kyaNnJldaU4 drsGAAAAAAAQQT7acY9q1LeN1oYpTa4vLAv7xkwvt537vSyviqXo286sLixvFU32FGeDuqeI mnvaJBXYjpbXp5XXQ8YlnZ0gH3sRNNbIldXn4kauachHAAAAAAAAEeQjIZ4gH3sRNNbIldXn 4kauachHAAAAAAAAEeQjIZ4gH3sRNNbIldXn4kauachHAAAAAAAAEeQjIZ4gH3sRNNbIldXn 4kauachHAAAAAAAAEeQjIZ4gH3sRNNbIldXn4kauachHAAAAAAAAEeQjIZ4MRD4+ffr0p59+ 6meJfQ4aa+TK6nNxI9c05CMAAAAAAIAI8pEQTwYiH3d2dnZ3d/tZYp+Dxhq5svpc3Mg1DfkI AAAAAAAggnwkxJOByMe9vb3t7e0+F9rPoLFGrqw+FzdyTUM+AgAAAAAAiCAfCfFkIPKx3W4/ f/58e3t7d3d3LOdfo7FGrqw+FzdyTUM+AgAAAAAAiCAfCfFkUPKx3W7v7e3t7Ow8ffr0CSFk uPM4zaNHjx49evTw4cOHDx8+ePBga2trc3NzY2Pj/v376+vrX3/99dra2t27d+/cuXP79u0o ipaXl2/cuBFFEfIRAAAAAADGEuQjIZ48GZx8JISMSsJHPj59+pSRjwAAAAAAcHZAPhLiCfKR EOIN8hEAAAAAAEAE+UiIJ8hHQog3yEcAAAAAAAAR5CMhniAfCSHejJp8PGzVarVadNyj/3tx 8rJRy9KzUqBfnO7X43vZ2O/EdAeeHh/WWRFdaZ2zkkdRzfs8H0W1Wq11VFDQq4NGzXdM4bmN l6fuy1a5Qe7Kx18UfJYBAACgKshHQjxBPhJCvBkx+ZjIwfrBSQ/+v8XJy8YgFBL0mMNWpdvq P/14pVar1Worh31t18nLhurUjiJD4Z3u15VPSmz6TAeX1NwtFhO/uXL49s3r05OSfZipfEE+ HrbUHrMqH0JB5Y9X1KvJbQcAAAAIAfnoy+Z6fWI1qnSJremJ6FzVi5jZmG+dm4hUppel4zbX 6+phU1tdrcWZCPKREOLNiMnHzgkwUEdRr7QmuDndr/dYDPVcPg5J249XVM1nVdt06/HYwPrB yWHLIR91fdlB02q1lcPT/botH+2GH6+U8oP+ymucvGx0OHITAAAAzjrIR09ixyd7vdDE8rG1 sNmtSrXbScVyoRnXsz6/rR4TTZlSMpqq2JazGOQjIcQb5GNG7y0YDKTbR1o+anOTiwdXappP MOnaDGjFVDr83cnLRscuXpF9knx8ddCw2uKf/Z3jr7x0E5GPAAAA0AHIx+JsL0yWHDC4vFpZ VgbFkI/tRDUaOrLLxvNsBvlICPFmROSjrmAClpDL1Ya2jKOWTEZk8ze1lJpFqy2uJ2gOY3k+ SzkZS9RZtku7vq2EjNPNA8zSS04QLlX5vOZJnesHJ/oV0tLlbq/l91c5KzpW/9QeAEfp+gE9 kY++m17Q8962Z4+u0Z8FDVFHPgpaM6mt7TplMXe80p2J5JJ8tLs0+fCWv01dH/nomKNtuFHX rfc981r3arE+1PGl5O86AAAA6B/Ix8JsrtcnWtNTpuYryuDko2YbN9fr1kBI0lmQj4QQb0ZE Puboc0tTYsOY/8LXV5RLX+nVyEdjjJg16Ox4xZALrw4aSmXMysdXyGtinG5NhjWbZugeq13l RoGFVN5sizb5t95aqRes7hfQ7YleTM5Se9tTeuitLyTgdIfb8vZ8Ydvt2yQNGHTUwfyYxE+U vLCA+DwcttJJzU47FoYgH83uip+ow6LWFd4d78Msf2mUuZvaFTyfd+8zf9iSLLNRYuouGYsN AAAwYJCPRUkE3+Z6XfSJy6v5WoqT6xvZMEntxXYyfDL+7/gUYxzl8qo6YzqeK+1dorFYPgYN ezTrT+QgHwkh3oyHfBReNCeN9nPatS5EhPmkqr+TtgNW5aNLhWhqo0AMFRorLyGVL5o/a1tg 85RA+ajUIfszcPbuoOSjv+cL2h76nDve0v7MHqdw+WgPkywzLdpsY5F8zB6nzh7UAPlYesFH +yOpC3dPHTzPvLC6JUtSAgAADDHIx4JsTSf6b2va0nPGWpDRVGoPhZGPiny0Jkcnr9iasp3u FePwj5Z89JRiRh8auTHfYi8aV5CPhBBvxkI+inpIMAKdy0d9lqVvOqRWlk+ueSomnq4LnXR4 mkPcpEOoXIJSn66uTyPtqPLqi4IbMu5gefkYXrq3h4vaHv7kFI58LBoz6G67eyq09ODZO8Nk R/oWgpTLEiumlx7SdemlnPJRLVqXj6GfOK98tFVgAEZHeZa/NJ6Q4mdecqzIRwAAgCEG+eiO ohGtgYRb065JzT75aIxz1C61vGoMV7SHN7re0veWicdgFspHqyziCvKREOLN2MhHMYYR6N3I R2tVxLwsz5RPn3ewr5xGq6p+mLyun9QtHfS2t/KqXumlfAwdbziwadfenne2XbFd5uKA9u2Q xiTGyu/YMwHf2b2BW1SH4FrzsXVU+p8HSjwb6sPQybKJ1r8f6Bcp+Lz7nnlJhiIfAQAAhhjk ozPa4EFjCcWChR298lH/U9WayhDIJD75qM7ytkZBWmpSn8otDOckYpCPhBBvxkY++rRFD+Wj uAhjtcGDVWoV2y7nKbE3CbQ84z7yMbQ/K8jHop53tj2dKG1M0RUeftds6HjkoC65HCo5dOSj Pb4y9BESd7s2LtWhgCuQjx2bR7MHjL13ij/vjHwEAAAYM5CPrmRzruPYoxcdwwb98lEVjtsL k3kpmiLMkQtSvGSsGrXDXNOuoym1UVvTgrgkZpCPhIxclr/Ympm67WXxq8vT9ye6w72J6XsT zXsTzfWEC9+8c+Hrd86vvXN+9Z1P7r7zyVfvfHznl1Mrv/zLl7/8r+iXHy3/4j+XfvHnL37R +Oe/fPiPf/nz578YAvkYsqFEpQX4CpGH2uUqwWcWKg6NdJxSJIlKbGTsKV3yO9opfvnoW7NS vkhY6fnpwyAfhZ53tT2Rj+ajJXlbV93CJazUvUKLOnR5gYMoO/30FYnpSku4ynPDX/s/775n 3v68x/cR+QgAADCcIB8dUTdjsT1gNfmYm019Kxt75GNBtEGR1uqQrg1ndPmovNiXHbpHNMhH QkYuyEcvYbtdCwLO/IV/FBkCruORj/rwNH1r5vwA3fscRfrmuYYoeXXQ0Hcutlf001fHU82F sDafb2tdX+t8lTf2GdfXo/TIR/OUVwcNw8e5R7d5ShdKPN2Pyo7d859eMAHc0/OOtqdPr/Zo xYMZ85p4RrAaA/Tcjtu9vqRxekcbXovy0Zx93PnQP9dW3SHmMVm20lVu8inTt55/6/+8+555 46FNPv6OPX86HbkJAAAA3QL5KEeSdMbijB1Pu06vP7G6MN9SX/fvEqOkcM1Ha554UbvS15mC 7QjykZCRC/LRgbC7hfXL3Fj5sX5w8upUdyXmwognr/KxSHZKbFKhVi8dsFazx7jpNT85PD5x NrB19Pr46NBR81pt5fBtVvmjQ+HdrNyTw+MTu2dK/r8uT+ULljUMkY/2FQ7jGyevd+k51zkM MGt+Y7+TLZWF0+1NUdJ7V6bnxbbrO3pntzUpMfOS7tLtGspzn43oNdQaWNLLi51j7wEtVrvc J86qfKrzzDieHKfAzZpgfhUUf94DnnmthtGx5F7Th7/C4E0AAADoBshHMVvTkltU5KAxKVtJ mHxsb67XJ1r1Sd0PFjhNK9ZykOYajtGUMGUb+dhBkI+EjFyQjwDwNmglAegDFefsh8GajwAA AEMM8lGIc5sXc//rXB1uzLcSaSgMOZTko7whtbV64/KqvKe2WElpH23DZubycXnVWPzRVRBB PhIyckE+AsDbN24hdfLyAEvV17vQyWTzcviXPQUAAICBgXy04x7VqI8u1PabnlxfWBb2jZle bjvko6H/8ujbzqwuLG+JAxIlQxq7S802mptip9WIltfjg/UtsIkQ5CMhIxfkIwAkWDtWJ1Nx GRHZL0pszVTyssYGNb0oBQAAALoC8pEQT4ZCPm7NvV+r1Wq1D291dv6tD7NlkfyXSAp7f64n SjqpSo+u7k7cqk47cPhS9ZHoxxVDEvY8lK4b8hEAFIzFDVkBsB/k62n2wvOevGw1tMVMez6t GwAAACqAfCTEk+GQj1tbW3Pvd+iF8jO35t4PcI+3bm3d+rBXenBra6vdu6sXJJZcfS+2Z6n0 SPTpimGFhjwPpeuGfAQAAAAAABgSkI+EeDIU8rGtKsSyufWhdmLIhXqrBwciH/ucfrSx+6qw //Kx3Q7tq8rysfVj9u6Pm/ed8vGxctyLBUsyfvTgf75/8Bj5CAAAAAAAEArykRBPRl4+mici H/sR5GN4+iEfWz+223sPFnML+V1Lko+PWz+229/t5P/94/OP0ncXvkuujXwEAAAAAAAoAfKR EE8GKh/Tpe70BRvzRRnj/4rFjXZsKmmUxR5rtffnbonXs5PooPyS2oHqRTVppFUhLS05VauJ ep5Yb7OJ9pRp4bS8CKPMrOHaJYy+keVXctCHt+yr25dJLiI0NW9P9ub7c1tqK7SLin1S9Eg4 47xXYvO9gi/rDqPieqsCSnc/D1KPBtVNiy4f7z/4sd3+9kn2yt1v2+0fv78+dXvx3rwqEL96 0W7/T+t6+uf159+32w++SrzkR9cTI4l8BAAAAAAAKAHykRBPBicft+beV+yL4l62tuJFGd9/ 31B4ipsU3xH/lqJf/taHiga69WHNcJvqO1mx2mHCX+mBjnpbTRQ6Q7uEeg2lcbc+TFa73DLW sVRrZMxLV5OuNfj++++rQtPXFGs0X94etZ4ffqh4Y3/jCh4JR5RauG+I0nzfFfPu+DC/6vsf fvi+Yn/lm649KQWd6O7RCvJx8fsf06GOMdc39+KBkF88/kwRiAvfaUMdJ6Z3HrSzgZD5K8jH gfPqoFF6C4tkg2M7JbbHPWxpZ7JpybCTbXii7Ik8nsSPd+92XMm3jhnGfV3UD2b94ETrE2+F 7a7rwmNz8lLZ36jSF4X2xdWTvbyz3guvZ+Ep3Ws7AACMGchHQjwZmHzUBY3hXow329pmMvqh ncpHw+EpI/XUk/MjDd2m/GnYUP1IZ70L2m/O01ULMEyWrhtFq6UfZqWg9sZliqpotsd9jwoa V/hIiFFa5q53flDAFY3usJWuaxBlXvnOerSb8jGbhe2Rj+osbOTjkJD9sq2+f+7Jy0YZv3C8 ohqKePdkfloPPSXv8oiS+LKeyKn44kP7qL86aBQ0/LDlk49y13XvsTleqfBldRSpOrV3nO7X y97ikFMqtR0AAMYO5CMhngxKPhY7w8Jl8krJR30ar0OAZeJIdmq5GhPHtklXkypf2ERziKQ9 TdkuTZOK6vUcNRAnYguDKR3zq4t60HzFeY8KGld4J72TyI16i0+PoH893eGUjwUdUPA8FPRo BfmoLPJoyMflpwuGakQ+DjPJIKCVw9P9evXftFV/GJ8NqzXycJsKCVBIxXZv0Hjur18+dnTZ MlQQiH2Tdz2Sj32TpwAAMBIgHwnxZGTko24RuzDtuqx8bOvuyCWoRA0n1LtT+djemns/XWfR HHnnkY9ifPJR7sq+y0dHdJvnNKPhV+yDfJQrwMjHMy8fFR3QDfl42KoqF6pfAXoP8rGQAIXU qb/rDycvG0V6awjko6eGRRyv9En79ko+Vmg7AACMH8hHQjwZ6LRr534bTjuYHtpV+ZifYs6Y tbSff0SjWzbp9S5ov6WoJLE3p7tHe9p1oH0sqH3BZTqWj0WNK3wkHDXXxLA6iDDkTrkuGiAf C56Uznq0qnz8cfO+vubjj3enBPnYfrFQpBpHWj4eRbVaLR6HIq8jdhTVhB/qxgKL8XTjNPbr K4euJdgStBXB9AoEU10+dvBj20TWE0k/lNEW3q5zTPE+irSCkvubxHrdfd9T1HX95HvXAxyL FVrLemqtUyuW91hj/5X6Z9IDyW3Snlvr7miredquylww1Ow6/UPRz0GCrpvuPCbvOut2Z+1P u93+qHbtqQj+uvDSsXws7rryj42z8t2Wj6f79WT0d1po9nyqNdQfWvu7zqi8dYzzE6dev4p8 7OCrEgAARhvkIyGeDEw+aluNJMMDg+SjvreHLB894s1clVEpWru6sABgTauncE58kCAfjXoX mTahSpZolLZXNqua27+t4jUfZVVmXSa/jlynEPlY0LjCR8JRc9XqmTOqreZ3UT4WPSnu56Gg RyvIx67sdj0G8vHN6/wHZ/aDNvYL6Z/CLD9dsek/hs35mKf79dpK1HJbs/j3sPprs7N5hZXl YxcGczlqnvRw2YurKiG/fvanJDq1Chg/8s3ZjoetWr21UneL5sNWTW9O/wYMStsH6c3RuiLp K9NopB2YPGz5g5oatKwtpu48edmw/lTrY0kWfcSr/glKerL/k5Qd98vbdQMc+eh55gPxTOwN qLzYdd7Hxrqy80upc/koT3jPVp94qy9YqX4hGMt0xocZD61ZefP4kE9cFfnY4VclAACMLshH QjwZ3G7X6ozk9+e2ErP34S11Kq0g/mof3soPVec0S5OjXRJSn60raDzprWTgo1Zr+5wPbyUH KJuoWPXOXzWP0mxWfqrdc1ql7fONZnx4S+wIpZR80J5epr4yYnYdtX5Zy5LyjauoXWCfLMzB Ti+U95cj6tG31F6Xmi+0zdMdrlbJZdjb7yQX2iqoWdKjAXXTo8vHfHtrYwnIxa+uTJtuMZ1n bS8BOTbyUf81q/2wNAbTJa84f2Eav7eF36iqGrB+8b4dkHzs2bDHzpF+3qs3yzZ0rw4aBb/b jSnh9n3XvIawo0g/ZytbT53lVSXxaj/GxqMY/2nKQeP6kt/R6uNZ8dDh6/s+1dRt0Iq7btDy seCZD79IQf2ryUfnY1NqNcOOO1A+UW2y2of560Ld1C8Q4ZHWujH8E+f/Fh3uOfsAANBfkI+E eDJI+ThKsQamlRupRkg3Y8jH1D8mydZ/XPzqsukQdx5kh+nm8aMH/6MUoAyQHDn5aP4U1H5q mr9LixcdM35/Ck5Qvbj0c30Q8rH6BhrdH90m/pIvkh3lZpsKy1N6BFw5+ajPO67VJIWtxxKp xuBBfcSZ2TP2A1A47sxqSN6ZohzRXrQH6Ln72dnbPeu6omaGdF1v5WNh5f3PfNj1C7u6knx0 PzavhVHklerpeDCkrrDko/nfzvsev+h7VEp84kL+CaeTtgMAwHiCfCzM5np9IjqXMeVfIW5j vnVuYjXqbbVIX4N8DIsxrzdZwdExoJCQ3saWjyKCfOyYMZGPxk9KW6MUrRRWLB/FuXsDkI9V N2B1SoEqBIgYy4gJLkD3PKHyUXKp/d2nRWu+PtjWbpf94BU9EsUWqWDhTq1DXItC2h8H+5i+ 4DRKnq4b9MjHzuVj2JG9k492D3dv0/DCT59XPso9U/jMW9cJ+8SFjh8f7g3TAQCgXyAfndmY b52biOrz2+kLW9MT0bmJ1sKm9yzk41gF+Rgcfd/q4O2kCel6kI8OpJ/iwvqA6THm8DrTUjnn umYM3cjHij+De2Ie38q/5KUlNe01DfO3zDtlTLvu5cjH6uRP3fFK0Wp0RR3YyZBA/8hH6U5l 7w7NrNLgkY9Sc4ZHPpb7eNpryHZS+WD5WNhXsYZ2vNvJ6D9rGVapGn0b+djRk9Nx2wEAYDxB PjqyuV7XzGOcremJ6Nzk+kb6dzQVGaoR+Ths+f777yteAflIyMgF+ehA+Clu67/sFVPoiAN/ wuWj8KPX+QO7mM7lY6Vhj4V+oRrCL3m7u/JXDJkoj9QLlo/CMxCgdbpMUgd7OnmYBi0jH631 7wo3WZKrWrBH00AIH75n4P9E9FE+llfevv7vonz0/cODcyWETjvQ0Rte+Sj6vuKRztqqr+Gf ONZ8BACAMiAf5dhWMU48HHJ62XkY8nHYcu/evYr+EflIyMgF+ehA2qFV/uFdPzixtjTRd4wx 9hd+65WP1iaqyVatXZaPySJ64o/nAFXkOj3QPBaV7mmRtaWyXdVEe1m7AOk7xtjbyHrko7m9 hrXVbz84edkwtuTWWqdpHe+GM/plrd1szNUzre2q80tZysm4oL0zyfBsOBPUdXZ7hU1g+iIf O/qnCJ88VZ/z0/1IODJMPpo9WbxLUsCtCaBgt+tC+ShvV23u3J1X6SiqNeoF+8tLj43RrsOW OF61qO0dflUCAMDognwUs70wqY1wzJONiDSWg0yHSabyMZ6jHWO6yGhKXkcymorq89ux3/TO 7yaBuXfv3r1797777ruOr4B8JGTkgnx0ULRio0K2CYb1q17ZQaKx/yr9U9lu1TeILBGO6RU6 2F/CjPmj11ZvCWGj+Rynpz7OjFl5Z+nFFK7YKPWA2Wp135LoOPszOcwnH80GRsf9nnb9ulhG mP2zcvj25FU+jMuK65GTbpl5EV24Hx6fGEXYqss+4NVpf+Sj+InQm+/uOlfzD0+V7emtdM2r hj7zxfhVr9q6emM//eD4uq74sTk+OhQ6tsMaOhH3+wqRj1b3irOw1ZqbX1wBj412TKPhEruu tnf4VQkAAKML8lHM1rRzexntLcfIR/VF41K61owNpnY1e643qZR7aTr2j8hHQkYuyEcHJQYx ldlPoHOGZdbqoCnT232ZyTgA+Qhni+58wwxknGm/aijKx1Fi+O8OAAD0EeSjFN0J6tGWfXTI R23QojYRe3m14N1oyjHcklTIPSWd+UfkIyEjF+SjgxLeqi+/e9kFNaGEiOnP7/mqe4IDeOie fBxuS17hozTy/zbD1wgAACggH6VUlY/OV2y9iHzsde7p6cA/Ih8JGbls3vvu9vJDL3c3V25/ O9sVvtz+W8LTv0VP/xY9uXzr8eVbjy8vP/rrzYeXlrYu3di6+MXGzPV70//8pnlt7cLi3U8W 7nx8dWVqPvqvueWPrt6eGi752CPD9X/Ze7/utq07Xx9rvLJmVs5yJP16Jj6T1qpTTiaZSWk2 acKcnFEmp0kdtpEnbv7YNGrRsRKLFlk3iRwrnjjqHF7oQnopupJeiK60/FZymeXfBUBw//lu bBAgSFB6Puu5KEFgY2MDlIsn+8/JbsNYoIZX01FTZBIxJUnhozVzgRqkMJTKhPpWV/1Z1edj zdFEc/wXssi1AwDA6aOIfPxoNfzwD59d/WP7o6vhn/7z1ifXbn/28Z3rn37R/uzLmzc2/ty+ d+vm5lrYW/tz//atv9y+df/ztfufr/31885f73S+ili//bVI4H2xrPaw61T5uGQT94VEPpYR 5CMhZAqJ/pNa9J/Xov/UtrOz88MPPzx+/Pj7779/9OjRd9999/DhwwcPHnzzzTdfffXV/fv3 e73evXv37t69u76+3u12KyEflVneyuhMdLRX12eR4700xitiRjPQldET6mS309CmeGMiNiib iU3soM1NWQ1VN7kqaVNPVtixVvp2AABANSgiH1979Y+X//XKb/6t9dqrf3z916u/vfyfbzau NRt/eus3H7/12qf/+/XP3n79+v/57Y3/89v2v79x89/fuLnyZrjyZrjy5p9X3vzzO80IeSRc kOU1b8YLzgwGg0n0fFSDfCwjDLsmhEwhcyIfAQAAAAAApg3yUU7YdKw33V5fXgpX2upu4/Z8 NBe/1k6KfJx0WHCGEDKFIB8BAAAAAABEkI+OyNM+mj0ix5WPhrs0gnwsIwXN4wD5SAjJEOQj AAAAAAD/Hde3AAAgAElEQVSACPLRmc1WZ1nzj1urNbM7pGdta2GLVUh7XRvEjXycdLrd7vb2 dpESkI+EEG+QjwAAAAAAACLIx9RE/R8ThCVo+iujHdZDv3wcDMxlZ9ZX2/3R2tnIx0mnoHkc IB8JIRmCfAQAAAAAABBBPhLiSSXkY//KhSAIguDyzXzH37ycrD2YrYibl4MguHBFXPLdm2Ft CxQxi8SNNMEqT77EDMn4rMykbqc5cyEfn+zV7bWSxY0z4qCTaRXsaLcs+5SxoHaWswMAAAAA wAjkIyGeVEM+9vv9KxdyysfRkf0rF7KVEAusXKe7eXmotG5enie11e/3lbpXs8SMZ83wrMym bqc5cyMfg6Cxd2xurIp8TCqZqvZOdhtBEAT1/ZPCReUg89kBAAAAACAC+UiIJ5WQjwNVIY6b m5e1A/MXlKlS/SsXSjFak6y2M5PXcTMRfBnbCvk4ycyNfGzUG7o4mz/5WFpRpchKAAAAAIAz D/KREE/mXj6aB5YsH8syWsjH7EE+ziDzIx9399eCYO3A2Ih8nOypAQAAAAAgoYh8/E/kIzkL mal8VGZPVObxi7deuBKNr40Fkrbv0Dwpkz0GwYUrN8XyrMRHqd+qpWu1ULfqm+TCzcrbEw9m OtWojqMvL99Ur1gvVG0IQ7hpbeTVce6CjLbuJxvTShw1h15x46qkthG6nJqN5GzRTHUj42Ru 5GMQHp3sNoKgc6hs1ORjMltiEFhjtH2F2/sf7zcCpfzj/YZauiA93QbQf6xR+SAI9KKcJRyt mYdZ+4x99lFTHIZBEEQjtaNWiqMo4EzE5QRJafZ5G3vH6sfoLisnDY/Uj9nue47DGZYOAAAA ACpF5OPah8hHcgYyO/nYv3JBkUNKb7Z+v3/zchBcuHBhpI7Ur7XjcvR8tGYN1D6pyipHz0er 8s7LTD3VsI4XLlyOdrh5OQguXL4cT2p583Kg7K190tfSsXdM1XHKDu5TqOPcszeHcvMuX76s CGW9bbT2SE6T0ojOFkU+TjTzJB91wafJx5PdhiqeovkNs/aLNDxjUsLIQx1pnS6P9xuCgMvS /fBoTaqVUXmrKO/ZM/Z8zHR2s+kOOkG9s1YfnfEwDMZxu0drmtF7sle3Bd9QC8aXoF/vj4kf jE+q3ppM9919+E8HHbvlq9SdFgAAAABmSxH5uP7ZJ8hHcvozM/moyy1DvhlfDrTFZFLMofBZ jNtYaR/zDbtOubJxTmVIVv3QtCNH5zeKyFB5ZREd9ynknbI1h/vmmUUplc/VosjHiWa+5KOq 3hRPJNnAwzBQukl6sHaWPZ1aH3H17TzycWyZaJ+9gHz0Nt1Bx+zqKLtXGb2z6qga9vUqFRP7 tCqFJB8z3nfX4dHOdHUEAAAAACdF5GP3Voh8JKc/s5KP6c4w1RuNJR/lodLqTuZ43iDILB/F kchm5c1Om1lPZRk/h3y02yrZYn5ldbW0Gka+UvftGLs5nDcvpQFSbnFKiyIfJ5p5k48ju6Qo KrP/2lPnRheGxjJ0VWp9UjcaCPpP0nN++ah/W0A+eptOaIp0M5upoWx5mlag63ZkvO8pd3M4 5nrcgeQAAAAAcDag5yMhnsyNfNQ1U5Fh1wNBPsqSKn/PxxT5mPVUJcvHlMpbTjKjfHSXWK58 dFQA+TjJzJ98HMqvo8RYSf5uvA56gt80lFn6nIxCJUXyykfP2fPLR3/TFZePYqz655CPWe97 FpXsvK0AAAAAcJYpIh9v/AdzPpIzkJkOu5YVnf2lPu62f+XCJOWjMMY7paxC8nGsU2WVj5Z/ Gx1oFuqpvF6SMrWjW/FNTj7abTM6MFeLIh8nmnmUj7F1Wgsn1/NR2/9oTeg6511ouzT56D/7 fPV8lHebTc9HoUD8IwAAAAAkFJGPv2O1a3IWMjP5qK0oEndrzCQf9RVVZPnoc06CAtPsVl8Z muzoVehOmlYd41RZ5aPRIlpB2jdRp8aM8lFf8CU+dtRi/fHmfMwiH41Tqrc87VlxtijycaKZ S/mY9FZT53zM1Kcvjdip6UvNPP1JmBlwonM+2pMqRou0qN0wfWfPNnehc87HtKYrJB8z3oW8 8jHjfc8uH82FhgAAAADgjFNEPr6GfCRnIbNb7VodSX3hSj8e73v5pjryV7dtw6HAo13VsdjS 1IOie1IOMvxj2mmVOuqH6hntoqyVohWa6VQ39TrqpWjtZh0s2NJhQfGBbiOnlnzT2Fk7xeWb fenaPM3Rd12VbhKlFnY8K84WzVA3Mk7mVD7Gzk5f7dqYtHHsZYtPdhvGys5K4UlnOmNpZmO3 kbOTRnyL2i4qcGTHDsOgUXct6Ow4u3G9x/sNwaClrHbtbrpi8tFa7fpphgVnLNz2MNN9dx8+ 5kJDAAAAAHDWQD4S4sks5SMhZE4yt/IxknTmmshJxhlwnXC83wgCUVQdhlrJ8UdT8KmzBzYa 4fDbuFgzxvrOSdYOkmuJryLT2Y3LP3iS+eypTVdUPppXF13gyfET67xJktPJU0aKXUelynsP Pzo8EOo26/+DCwAAAADVAflIiCfIR0KIN3MhHwEAAAAAAKYP8pEQT5CPhBBvkI8AAAAAAAAi yEdCPEE+EkK8QT4CAAAAAACIIB8J8QT5SAjxBvkIAAAAAAAggnwkxBPkIyHEG+QjAAAAAACA CPKREE+Qj4QQb5CPAAAAAAAAIshHQjxBPhIyX/mv//qvz6ee20o6nU6n01lbW1tbW7t169af //znMAxv3rx548aN69evf/rpp5988smf/vSnjz766OrVqx9++OEf/vCHq1evIh8BAAAAAOBU UkQ+vnSpWVt+459/+eZLl976lxf/98u/evuV2r+/Ulv5139+59/++T9efendV19699V/+b+/ /pff/frl9+ox79dffr/+yvuXY34vEnjfLZGPZGpBPhIyX7l+/Xowh0E+AgAAAADAqaSIfCzx Hcz7bol8JFML8pGQ+cq1a9eCINje3p7mSRl2DQAAAAAAIFJEPna73fX19bt37967d6/X692/ f/+rr7765ptvHjx48PDhw+++++7Ro0fff//948ePf/jhh52dneh1LHo1i17TXC9xQZbXPOQj mU6Qj4TMV5CPAAAAAAAA1QH5SIgnyEdC5ivIRwAAAAAAgOpwhuVju7lkp9nOX+C002vVlmqt 3qyrcfqDfCRkvoJ8BAAAAAAAqA7Ix7kVkHH90Y+lB/lIyHwF+QgAAAAAAFAdkI8jeZfYyLnw eVFtK1bVSlaqcJCPhMxXkI8AAAAAAADVAfmomLJeqzYv8jGuasU6aZ7SzpjIR0LmK9evX/+7 v/u7Kf9mkY8AAAAAAAAiyEdZPg7/p+r3km228jOHcJvdKZUShwdrh6i6zl3WKJp7jA5otkcV 1Ouobta/c1ZOPyTZXzmtUsuogvYo9lPjIJGPhBBvkI8AAAAAAAAiyMdEkSX2TFV6tqoTnJo4 e2S8m6gSLR3o3l88pT662TV5ZVRx6VzWNWrnkcrTyqrVavZxyEdCyFkO8hEAAAAAAEAE+ej0 ZWZHx5Qxxb2esk3vRWg7TKtg/YCUsvSau6ypXb5aonYVQuWSbYbaNKSp3iaGOT011jEO8pEQ 4g3yEQAAAAAAQAT56OrlZ04BOez15xdrkt8TxlWPNqUULRxuTfdo75PmSVWd6S7dLr7ZTvkS +UgIOeNBPgIAAAAAAIggH21nZ3UhrLV6PvcoDG7Wej4KM0taGe7jLEv91u6rKFyIOL9kJjNq B/mIfCSEuIN8BAAAAAAAEEE+aqbMYe1qrZ4x1FmNwyaOLR9VveeUj0I90uWjbBPHlo/asGvk IyGkenn0+cfX7z+e1dmRjwAAAAAAACLIx1T5mOzUbNZcVk0fnT3Qximn+T17zWxfWQPRPTqH cWvrwBhjyZ3yMbWHJ/KREFLhfP3hxeCZ59+YjYFEPgIAAAAAAIggH21nJ41yTpFqpjDUdV/K tIra0OmWOrGkoyxhyLV0Cm0VGLkEt3y0FpwZDAa9VktaGsc+t+VuT0eQj4TMSR59+sqz//AP QfDM829c7z/aiTY+/CL84mH550Y+AgAAAAAAiCAf7ejqbGQfXR36HAU55aPjCHUJGLks2T2m Dqx2jeN2y0f5CG3RHad8NA49LQ4S+UjIvGSn8+alf7925aXz54Lg3PmXrtx58PDWaz+7fPNR +adGPgIAAAAAAIggHyVjp8UaCm1HkW7K4jSuBaXNQ+Lvez1T4BlluaadFC5E037K90YxzmHS RpHNdlQ5n3w0Luu0DL9GPhIyP+m++8KbnZ2dB3diA3nu3P/3zt2dwWAw2NnZKfPEyEcAAAAA AACRMywfMydlrZkpxj0Z4ymdabE6QT4SMkf5+sOLFz+M/ml4fLv5P4IgCM79/T+9ceXdl15q 9Us8L/IRAAAAAABABPnoTaXcozSSGflYcpCPhMxTHn36yv98tzsYDB5+/PL5tz5/dP/6G88/ EwRLcQfIsoJ8BAAAAAAAEEE+pmU0+njW0xf22u1W01EN5GPJQT4SMl/pvvvC5ZsPP3/rZ6/e iFaaufvOhdLnfUQ+AgAAAAAAiCAfUyIs/FzFIB9LDvKRkIrGNY3j1x9evHjx0qWr8b8Q37av 3Sx9vWvkIwAAAAAAgAjykRBPkI+EVDQ3X/v7f3rj+v3H1hePPn3lf5Y8zNoM8jELT/bqQRAE QdDYS6tztFv6PuVwvN8IkuSswGEYBEHn0P7qoBOoCY9y17Cx+6SkyleSyj82VeRoLX4SpEfx bJE8P0EQBGsHuVtyrKcr90Ob5cblq1IlWz75q5jv7+GZvXHqvyb1/ZMS792kmm5eHloAKBXk IyGeIB8JqWhuXg6CIAieed42kCWvbW0H+ZiZg47v3SN+SxlfExSv2Oikh2GOd6SU98+jNbW0 SBSO+b59shvbRUE+HnTU7dGe027A0u9OJR+bCnOy20A+HoZF7MzRWhEvlvehzX7jqnyLM7f8 k736xOXjqb5xx/uN6fyh87dDnkOq/NACQMkgHwnxBPlISDWzdbV2+cY3d668dP5cZCD7j6Zs HJUgHzOT430mK0VeYu1jx3x9jbqi1PdPDjpZ3qzGfAGLO5WsHTzZqwvy8TA0q2pvmW8q+thU Gl7yo1+x3FM4CwUtT96HdowbNzUPVWLLl/ADTGuWDKer9o2b3u+6HPlY4YcWAMoG+UiIJ8hH QqqZ+9c/jYZW7zyIDeS58y9dufNgJgYS+ZiZalok6XXIOYBaQHnTziYfs+7249OftLdNUT4K F458zAzy8RRztDYLe1jw8HFuXLELrETLl/ADTGv5asjHAjfuZLdRzlDrSbRDpkMq+9ACQNkg HwnxBPlIyDxk51H/+hvPPzM0kI97V1965Y/3p3b6eZCPjqG+hmI7DAMl1vb6/olnJi91aidp Rir3y4nr1BnObp00mVwqY6cnu1bxFIrjv4KW0vMxQe75aI6zdnQtiZpxvI5gPDZl4Zik0prW U7tAtVlG87419o7Vj3EjxM+YNhmo9chpU5HaLay1m3DjtMInJhQyPzZeHJojU9NZEZ5J7akx Wy/XQ5v1xqVfYGVbXm665C+MctLwSP3o/EXoLZN64zL/3qt942T5eNAZ9rsf3q/h/9aubszf u+OfxWB0FuHOFpKPef6RAoC5AflIiCfIR0LmJ4/vxwby3LmlqS45Mw/yURZe2uA4463GnLTr oBPUO2t198SI+syD8hlzzwnlPXuBHjTmGY/3G0Fj7yDX6LBM8jH3aFBZPv6kWgPnojTDF8s8 c03y2JSAdKf0xjxaC9TGfLJXt+fRM27r6MV+KGKSNjF158luw/qo1sdqGf3ZNpW3PmtqUVSN Ip4ucwu7D3E2nVIH+amzKyP0Nc770HpvnEIJnchKbnnjqZN/gHEd4t3UH4Xnr42/5SfT83GG N859yfH2uBqj/60q9ZTfuzXTiN4OmX7vReVjzn+kAGBOQD4S4gnykZBK5fH9z69fu3bt+p+/ /Moxx+Pj283/8exbn7PatY0tOyLL5irB8Gj2y4b2hilMkjhhi5R29qcTk49Jm+SbmiqDfCww HtYpH/V+PRMdbMtjUxrW0H7L6kraV38mjUdi9FFyRkr53qkGPM+/INAnOSBUUBuie/UWkvLY OJvOc7hkjScuH503zrqEEsYsl9bywkPlko/G3xDH3zTxq5nKx5JvnONAtc7qHUy2+37vgtPU 2iHb7z2TfDy1M10AgA/kIyGeIB8JqUx2eq2Lzz67sLBw/u/PBUEQPLP4ypXb3xgrXQ8effzK yx8/nG7N5kQ+Wi8YHllgvEgIr3kelzFpi5TW/24y8lE9S0nysVAHMYd81GzI5Nd95rFxoo9D tM2vPk7TGlFoXL5WW7Fi9gPg9NFig4xupdik2sZhLyTxXjsPzyy+05tOKn88a+/sAuxvOs9T l3EuvEIOy33jxr7MCrW8VE4G+ThuI89SPpZ541JmIjblo/W/PQ0lSVJXmSm3KeNPI9e1A8D8 g3wkxBPkIyFVyddXX7l8I7aKO4/6199ePn8uCIJnLr6rLTOz8+DBlNXjHMlHWy7YIsNQJVkt kuTU5sYiRYUL3W0mPedj0ZeujAvOjN9TyX9RPDZloJ1d7z1nt+ow1r3OIR/l5rJdsGuSOHva PnufiT1yqbc4+8MgNX4O+Zi1GtNxWBm+rU7LT0I++uYl9LR8ZeTj2DcudbIOn3z0/d6zyMcM v/dx/tGc5EMLAPMB8pEQT5CPhFQk91svXL6pb0oWun7mYqs3k2Wu48yPfNRevYwhnJax8o99 Oy1d2KKuQPqLUM7B0SmvzRPo7iHpkowtXwgem9LQOh/lmIxyLPmolJmvy1h6T6hSmmXEeLbC mks0e9N5WmMGPR/dD8PEO5GV2fKF5aPvr42/5acsHyd746LfYGV6PuZqurzXDgCnAOSjL72N +tJ6OPkyw5V28nlrtRYuL3VWe5M9zSBshsvaieYq7fWKVB75SEhFsnX10j+8esPu1Ljz4NZb PzsXPHv55tQ7PCaZI/noGGL8o6vTU2aLJLy9SG9KJVqkIj0pHJ0Hczgp12tz1HOkqOQSdYkw f/8kZ98zbgqPzYSJ62PfsoLd94TD1Xd+13I3aWdUn7TciyZlQ7jjY5/Rdzl55WPGmkzQYaWv IjX5OR9La3mhp7Mw66vzr6j3r02Glvf/3it94xz3wisfPb93obO8vkDNxJ752f/3HgCYGchH TzZbnckrMFk+Tl60RfKx3tqacLnTCfKREGLk66uXzp372Vu3Hth9HHd6V144d+FKfwa1GgwG 8yUfE4NgrZCgvwTGw6wyj5+1ptu3lv60D3myFwovgbktktnj5ni/MWZvHb3ywttvNIWfT1jI y574X7fiudjG1iXmArKOaSX9leexGfexmQQnuw1jSW6tbbXKeBecSWkQszRx+VqtHfSGMgq0 l9eY9IIzVj/QcTvzZljtOpd8HD6l6g/heL8xoYfWe+Mcp5gQ5ba8WdphGDTq4rol4hl9f218 Ny45KvX3Xukb51/g2/G/Pb93oVkaDesvs+/37m+69Gsv9o8UAFQc5GN6Yi243JzoC60pHyeS /srE6znbIB8JIVYe3rz8bBA88/wb1++by8wM7r7znDkqe3qZL/k4WgTDfDlUFyIIj5KPyrqZ Ho8zNEdxCSkLEMepN/YOzFrpGR6exSIZhQeNvYMnY6gQbR0G96A/USMKaziMXhG1ZlHrJ1de eG0WG8d8D1QvXHgq3JXnsSny2BQnTTqbM9ytHTw9OR5Nl+m88OGVqnF0mJIfm5ODoxPjFLLy 0Hc4nlDT2VeXt5uYoMB8TSf/YI3LN3/yncMfjw4P3CfK/tBmuXHpF1jZlrce6bUD9e+ePM+p vUbTqGL6X5tMN85+7O3fe4VvnKz4M8hH4cIFaas2mvVPRpbfu6Ppxns26BcJcDpBPqamt1Ff 6qw0O8uTHXmNfMwS5CMhRMjOg1tvP/9MEBnI/qNRH8idzpuvXJ1ZR+85k48//Vj+lG0/Pv1p 8jMPwqzhsYHpMJknrQQ3Vy1Kko+0fNlMWj7OEzwbAGcW5GNaNlud5aX1UHKFYTOst7YiQRah jm7ebHWWm/1IMsY7qFrQKjBshqbfVEperm1sansmxNNERmPDHdv1qSTVKulfhc1wpa2fV1OZ /RXHgXqGfUVjlIvqbdRrG5vaDmY51oUgHwkhg4dfXHnlHxcWFn5x+cMv4kkdH9+//sbzzwRB EDyz+OLbq9evX7/2bu351249mlkl508+TucFZtaz6cGE4bGBKTE5BXaah3B6xpXT8lWlwI2b +/82U8ZDCwDzAfIxJUlfwv6KbgAHiQRM9Fx7XfWPsURLDomUX7KzTz4aE03GojNxmvJRQs9H Uz7qfQnDpqb/4ivS6zy8oq3VmvGV3BU0qarjqNCqwKgcoz70fCSEDAaDnbvvLD2z+OKvf/vy P/39uUBbVObxN19ee/flXywsLCws/OMrV+4IM0FOL3MnH0vqenC0Zq40wjvGaYLHBqbFZBSY sIzGacKc7JWWnxMK3bg5/wtZykMLAPMB8tEdRX7ZXQjtvorqFnt/bYtHPvZXMq4S015XzuKV j1urNWMHbYt1Rao6zFwlPXHX0eiDZjOT+g/bwe5einwkhAy+/vDihfd7kVWMFrU+9/LHs1vT 2p15kY+jGanK6JNysttpaDN28YJxOuCxgakzsQH+2jR886tspndFtHxZTKxBtKkt58Pw8jAA wFPkY0o0GWeJs7Bp9oVUTZ8m3aKkijbtXNml21jy0XZ/+nntK1K3mN0Ss8WWj9p1KVuEEeLI R0LIo49f/sf31T8MDz9++dyzb32+MxgMvu/88d3QXnZmRpkX+QgAAAAAADBlkI+uGC5PH0Es qTpVBQryUVVvfvno1Hyu6R0zykfD5an1TJePA2W6yXQhqM9KaQrcVPno1rUzDfKRkJmlf+VC EDx7+YYyovrrq5eeeeXTR4PBYKd35YVz586/dOWLCnSFRD4CAAAAAACIIB8dUdddkRZamYl8 jLze6MDxez5K8jHewSsftZaRl9WOFpMZVX7Mno/IR0KIkZ1HD+59fu3KtfXvR5vuvrN0KVrW +usPLwbnLl0td+mxbEE+AgAAAAAAiCAf5YRN269p8x46hl2rcz7aKi3bnI9O6WZNvDjFYdda XHrUui6GXRNCSsjXH158+eNHg0c3L/9DsPTO3VmuM5ME+QgAAAAAACCCfBTTX5G0V6qq0xZv seWjtn+GBWeEroWWPdSFXbYFZ9x1noB8tHShPW+mSz7axxpLfs8wyEdCqpatq7XLN754Zyl4 9rVbj2ZdmShzIR+f7NXtBUPEjTPioBNPRx8e+XfLso93t9yVnHixAAAAAACnFuSjEKHfYhRF kBlrQxvrsRj9+EyPJi5fo5QW7Z/ssNnqrLQHw0HNSgfJWqee5hat7oTtdaPY9IHkypb+inGx opSMBOjwq81Wp17L2vPRvLreRr3WsceJzyTIR0Iql62rrzz7bKUWvp4b+WgtY1ol+ZhUMlXt xQt9+pf49BeVg8xnBwAAAACACOSjHUfHw+Sr2sZmyrIqg8EgbVmYOMnhkQo05KNZQm1jtd0f VSCi2Y+E3UhiqvNUNvsDcSxzb6PuqHOafGz3V7UrksysVX69taX1IfXIx8HQP8aXvGlc3eyC fCSketm6eim4cEX8Qz2bzI18bNQbujibP/lYWlGlyEoAAAAAgDMP8jFn3L3/BoOUvpNkDoN8 JKSCefjFnV4lJnuMMz/ycXd/LQjWDoyNyMfJnhoAAAAAABKQjzmDfDw7QT4SQryZG/kYhEcn u40g6BwqGzX5mMyWGNhjtH2F2/sf7zcCpfzj/YZauiA93QbQf6xReWvOR2cJR2vmYdY+Y599 1BSHYTAcqR21UhxFAWciLidISrPP29g7Vj9Gd1k5aXikfsx233MczrB0AAAAAFBBPuYM8vHs BPlIyCyy82Djz9evf35v+/Gsa5Ip8yQfdcGnyceT3YYqnqL5DbP2izQ8Y1LCyEMdaZ0uj/cb goDL0v3waE2qlVF5qyjv2TP2fMx0drPpDjpBvbNWH53xMAzGcbtHa5rRe7JXtwXfUAvGl6Bf 74+JH4xPqt6aTPfdffhPBx275avUnRYAAAAAZgvyMWeQj2cnyEdCpp+HNy8/G3ehembxlSt3 HlRpiLWU+ZKPqnpTPJFkAw/DQOkm6cHaWfZ0an3E1bfzyMexZaJ99gLy0dt0Bx2zq6PsXmX0 zqqjatjXq1RM7NOqFJJ8zHjfXYdHO9PVEQAAAACcIB8J8QT5SMjU8/lbz77wzu1vtrfvf3nt jeefCYJz51+KDOTDb76pZFfIeZOPI7ukKCqz/9pT50YXhsYydFVqfVI3Ggj6T9Jzfvmof1tA PnqbTmiKdDObqaFseZpWoOt2ZLzvKXdzOOZ63IHkAAAAAHA2QD4S4gnykZBp5/tPX3n1xqiv 4+P712MD+U/P/+zyzUczrJkz8ycfh/LrKDFWkr8br4Oe4DcNZZY+J6NQSZG88tFz9vzy0d90 xeWjGKv+OeRj1vueRSU7bysAAAAAnGWQj4R4gnwkZKrpX3v7yif/951rW/rmx/evX1469/LH D2dTK1/mUT7G1mktnFzPR23/ozWh65x3oe3S5KP/7PPV81HebTY9H4UC8Y8AAAAAkIB8JMQT 5CMh00z/yoUgCILg2cs3jIkev7/xXqs/o1p5M5fyMemtps75mKlPXxqxU9OXmnn6kzAz4ETn fLQnVYwWaVG7YfrOnm3uQuecj2lNV0g+ZrwLeeVjxvueXT6aCw0BAAAAwBkH+Shns9VZXgpV VtqTKLe9vrzUWe2J3/VX9DNq1DY2h7Wqt7bE40lJQT4SMsV8f+O9K3f7w2HWy29fv1/JKR6t zKl8jJ2dvtq1MWnj2MsWn+w2jJWdlcKTznTG0szGbiNnJ434FrVdVODIjh2GQaPuWtDZcXbj eqKnfnQAACAASURBVI/3G4JBS1nt2t10xeSjtdr10wwLzli47WGm++4+fMyFhgAAAADgrIF8 lGMsVz0x65cmH9VsrdbC5abZxSdWotZ2UmqQj4TMIo/vX397+fy5IHjm+Teu97+6tXr9/qyr lJa5lY+RpDPXRE4yzoDrhOP9RiCvkX0YaiXHH03Bp84e2GiEw2/jYs0Y6zsnWTtIriW+ikxn Ny7/4Enms6c2XVH5aF5ddIEnx0+s8yZJTidPGSl2HZUq7z386PBAqNus/w8uAAAAAFQH5KMc Qz4OBoOwGRpb8qSYfCQ5sr29XbAE5CMh08nXn74brWg9ys6DO1deOn8uCM5dulrtaTbmQj4C AAAAAABMH+SjHFs+brY62bxhapCPU0+32y3oH5GPhEwlW1cvBUFw7vxLV25/ow213rnx6oX3 ezuu46oR5CMAAAAAAIAI8lFOBvm4tVobzcmojcjubdTV6RpVh1hQPrbX1dknN1ud5WZfnSwy qkbYTM5unkv56qzIzW632+12v/3229wlIB8JmUo6//HG9S+jyR6DZ55/YzTZ4/fdu1VXj8hH AAAAAAAAB8hHOZZ83Fqtxau+DAaD2Pcl8q69rvjH/oqq/HobdVVNTlw+Lo0Gg0d6tF5LdjDq rH+MDOkZ8I/dYXL7R+QjIVPN429uR0Otn3n+jev9u1dat2ZdoyxBPgIAAAAAAIggH+UY8jHq MKhbP2tGyJHmU6NrxMnLR7W0/sqSVg2tntap7as4lekqyecfkY+ElJyH33xjLmm98+DG5fPn zgVB8I/vF5zuYjpBPgIAAAAAAIggH+UMOxUmWL0gdTM4O/moVqy/YgwAV05n1/AMysd8/hH5 SEi56V+5oI+zjvLw2r+/f+fOtZvz0UEb+QgAAAAAACCCfJSjiLlobkfnbI+SoBxNwmjOrmjI x/a6ultiFcuSj0KdCy+hU/kgHwmpYB7d+uO1+/H/3rpae+GlZJz1yEDu3Hj1hdZ9RwGVC/IR AAAAAABABPkoR/N65vSIqUtRRzsbMy1WsufjGQnDrgmpXHbuvrP04n8+GH568ODhYLDz4M5w psfLV8J7W/euv/azZ9/sVH6hmWGQjwAAAAAAACLIRzmpcz4aC7mkHVgt+XgGBlnbYcEZQqqW fuuFc+aK1lF2Hty58sriM0EQBEHw7OWbD2dUwxxBPgIAAAAAAIggH+WIXi8RjtZKL6NYjs9e F3s28tE49uykoHkcIB8JmWy+v/HaL1t3+9ffeP6ZIAjOnX/pyp0Hev/GnUcPtra2ts01aKod 5CMAAAAAAIAI8lGOsBhLe315pPaiWR1HO2y2OrHX03bbWq116mbPxywGsAT5aE9e2V7Xdj6l 6Xa729vbRUpAPhJSTh7fv/728vlzsoGctyAfAQAAAAAARJCPcqSVoON1ZrTB18nKLbWN1XZf OVZZzqW9rhQ1OipVQZYhHwcDc9mZ9dV2/9TPAlnQPA6Qj4SUmmSux3Pnl982h2HPUZCPAAAA AAAAIshHQjxBPhJSdhIDGTzz/Bs3/jqPfSCRjwAAAAAAACLIR0I8QT4SMpXsPIongnzmYqs3 d/4R+QgAAAAAACCCfCTEE+QjIVPMwy/evfjMuVc+fTTriowZ5CMAAAAAAIAI8pEQT5CPhEw3 O3ffeeWKNedtxYN8BAAAAAAAEEE+EuIJ8pGQaefhX/9Kz0fkIwAAAAAAnAqQj4R4gnwkhHiD fAQAAAAAABBBPhLiCfKREOIN8hEAAAAAAEAE+UiIJ8hHQog3yEcAAAAAAAAR5CMhniAfCSHe IB8BAAAAAABEkI+EeIJ8JIR4g3wEAAAAAAAQQT4S4gnykRDiDfIRAAAAAABABPlIiCfIR0KI N8hHAAAAAAAAEeQjIZ4gHwkh3iAfAQAAAAAARJCPhHiCfCSEeIN8BAAAAAAAEEE+erLZ6iwv hQkr7bJPOG76K0thvbU162qc5iAfCSHeIB8BAAAAAABEkI8p6a8shctL66G2Rf1YhSAfSw/y kRDiDfIRAAAAAABABPnoytZqLVyubWyWdoIJBfnoyfb2dsESkI+EEG+QjwAAAAAAACLIRzmb rc7yUme1V1LxEwzy0ZNut1vQPyIfCSHeIB8BAAAAAABEkI9isnZ7DJuj6SCXm311+0p7MGiv i9+OTjH8VrGHW6u1cKWdlByN8tZ2tkaCIx/T0u12u93ut99+m7sE5CMhxBvkIwAAAAAAgAjy UUx/RdCFRnRB2duoK4fE6lD/VlGEevntdcU/xp5RXdkmbJp2UhGjyEdPusPk9o/IR0KIN8hH AAAAAAAAEeSjFN0kymmvG+OyN1udpE9i2DT6J2rGUN1zkOwff7u1WvOcWj8c+ehJV0k+/4h8 JIR4g3wEAAAAAAAQQT5KMeVjtOx1TNQnUdGFcUz5qH+brheRj+WlqyeHf0Q+EkK8QT4CAAAA AACIIB/FuIZd91dU+bhkE/eF9MtH4Vhlekfr1NbpkI9Zg3wkhEwhyEcAAAAAAAAR5KMY14Iz unx0r0gzbs9H89Tat5GsHA3xpufjWGHYNSFkCkE+AgAAAAAAiCAf5Wy2OsaUjoPBwOr5qM3b qMYvH53i0pKPvY26vv4M8nGszOmCM18TQuYqXw3z17/+9a9//ev9+/fv37//l7/8pd/v93q9 zc3Ne/fubWxsfPnll1988cWdO3du375969atMAzb7fZnn30WhiHyEQAAAAAATiVF5GMYhp99 9lm73Q7D8NatW7dv375z584XX3zx5Zdfbmxs3Lt3b3Nzs9fr9fv9v/zlL9GLWPRSlryjuV7i Aq+aKVs+xiOvTUU4ko/REtWqE1STKh9dZjOKJR+tE+neE/noSUHzOEA+EkIyBPkIAAAAAAAg gnx0p72uz6440OSjNRp60F5PJGC6fByuYDMqebPV0YrVhl1rGnSz1anXzJ6PnoW5z3a63e72 9naREr5m2DUhxBeGXQMAAAAAAIgw7Do95uIwRh9DfR2Y9dV2fzPZniYfrZJrG6vt/mi7IROj 1bdHFVAdaNSPMlxGQTpS0DwOkI+EkAxBPgIAAAAAAIggHwnxBPlICPEG+QgAAAAAACCCfCTE E+QjIcQb5CMAAAAAAIAI8pEQT5CPhBBvkI8AAAAAAAAiyEdCPEE+EkK8QT4CAAAAAACIIB8J 8QT5SAjxBvkIAAAAAAAggnwkxBPkIyHEG+QjAAAAAACACPKREE+Qj4QQb5CPAAAAAAAAIshH QjxBPhJCvEE+AgAAAAAAiCAfCfFkxvKx3VxypdmeTZUIcafXqjmf2Pl4dNvNXPUz5eP1NxcX Fxd/9fu7yEcAAAAAADjbIB8J8aQCPR8TATlyIsmmWqs3u4oRYiaWj/GjmqjI+HP03Fb6oW03 89lRQz7eu/KrxcXFxcU3PkU+AgAAAADA2Qb5SIgnFZCPiWrUlIigJE9pxMsnFY0m70z5GG2o snyMH7axnrXokm8w7BoAAAAAAEAA+UiIJ5WVj2dGP1oCi1Q5vVZtJBfte9dr1Sp8I3utWq3V btXGe9jmUj4edIIgCMKjkv7vxcluI0hS2lly1GftYMY1+enHo7VR0zT2zHv3ZK8ubvcR3dBM rR2dItdZ/GU6Sz4Mle8dlTwMgyDoHKac6Hi/Efj2ST22sfvEXWyhZnFWPrk1lfk5AAAAAEwd 5CMhnlRYPor20ZhzT+hkZkwj6RggK20ZHllr9ZRS4lMoJ3bW06qSWqJSQLKLNOVllfvNET2y ODbuanRDlY3Ntnag9GCIJRV+MmJx2m46CjMntGy27Skuax/c+++/3fvgV0tLi4uLi2989vjx 409+uxhlYWHhNx9F8nH18nNx/u33d9fX1z97+xdTlY+xjKvvn5Tw/y1OdhsTFVuT4mht9vLx aM2jn2I1maueT/bqmd3WQWeC9+hkt6Ge9zA0FN6TvbrysEWmz6xn4mRdYjH2m2sHT3/68cnJ mDVP7LMgHw86aoNblc98W+XKH62ppcnXDgAAAHDqQT460tuoL4Urle2eQ6aYKsvHxHwY/s/w iXZHtGhL/Cnu6qUJHM2pNNvGllqzWWu21eLacXc3VSZKdVc/mSXWWj3RVtHzcX7jvHfiF+2m KbaXlmo148GwxLT9ZBWorfL4i6JzuFHbw+r5eO/69XvRpI9vfBb1fPzivRcXFxcv/e6O0vPx j79+7tcf3Lt39+7d9/71/HPPTVc+5ieDtDoMy9KaxSgsH4sLu+P9RokCdGbyUWzqkeazzmXq 6ahvYH3/5KDjkI+6vszRLEGwdvBkr27LR7vRvILYbsn0ymuc7DZy9twEAAAAmGOQj44gH8kw 8yMfbddoukCznOiI6JPbVNo9H3XrkmKEbBnp+H60Q5YemGRe4r53tkxM3GPK16MtvicrX2VF tzgq3ui0OzyVOOxal4+PHn38+uLiwqXf3U7k4x8vP/frP9y7d+/uJ2/9/Pz5X7z92amRj+Mo sKlSAflYrvIrWT5qY5PTW1LTfIKM1kZAK6bS4e9Odhu5dbYi+yT5KOlg/+jvEf7KSy2PfAQA AICzBvLRkTHlY9gMl5fWw7Jqk57+ylK43OzP5uSVz/b2dsES5kI+LjXb8gyQmqKxuyUqE/CN Ix9TTKG+i7cIu0r2xSIf5zdp986896p7TO0Bq43Rdz+c46bdNB9+pajUhXIyycdHH7++uLBw 6d3bsXz84+Xnfv2H3r179z556+fnz59/9YPpzPmo+6MM89+NvIw2jaOWxKSosxlmtFTmSdcO 9DnyJGmVVn9jfj3Nr5nyMb4i1dblv3YPcgnK1WlTIjqK1fYRZFy6fDSmZQxM+Wg0nV6+0VfR NzZZ7fko1Cq+ELuqspib1Hh5ST7aEjZ+BvJNuznRno+OMdqGG3U9OfH2+v6JfuutlrR+ttaj FRUl/7kAAAAAyATy0RHk42lJt9st6B/nQj7WWj2hq5hypDZ1nuhQSpGP0pSNWeVjmocic5LU e6d/qblHr3z0PlljJ316Uec0kMmXXvn43fp7lxYWFn7zUTzn4/LKjd5IPj733HNTkY8j9IGx QyJHNtIT+nR4wy0l9XwcKpKR+zhasz6OKmP1WTMrH0mTUU30w+WxwAWv3UeGEhxyymgKcRhy SstbQ4mNmpgV0z2drdVSx4/rl2A+adFNkcfmi/7uoDMc1JwiXrM+YMYzb7b28X4jaOwd5Bod n0k+yr+7cR4GrQSjT6jZqgedoN5Zq7tntDzoGFZROuPwh1nF7swAAAAwLyAfHTHkY2+jXtvY HGyt1sLlpYjOam+057JCvbUVH9VeV7YrarK3UV9aDyNpGHvDrdVaZ7U32Gx1hHIG9onis6v7 a7Uiw3S73W63++233+YuocryUVyuJad8lLtFppnFDLt41+NGPp7ueO6d8mDr7jG7fJzUQ6GM olZPp42sLigfv1v/3aWFhYXfXP3mm69WG8srYbTa9e//7fz58z9/+7Mpr3YtSxBhoznitWz5 aHgl2wDq+49qK61l7JSPQrETuXYfeeWjS0Lpl+BsecH06TVJnaYz66Pi+Er7mNyR7PLR7iY5 zrBo9wNjN2xkHo/zTs2ZQT6OPeGj/VQnlcxSB/s51y5NmN2SKSkBAACgHJCPjtjycSlcVrYY XR3tno+brY6iAiNrOdwhLk3df6g1kw6M7XX1dMbHsKl6Rno+pqU7TG7/WGH5mEH0icOuRWFT inxM953iWZGPpym+e5cskdTU3aN0oPb4ep+sMWO5R8M+6irSPjiTfPzu4bXXFhYWGle/WW0s r4T3e73pD7seIckjUY0JOiO/fNSHiBpjOcUDUySXvr+/YkNbJ2nKCVy7PmTbGAObuZLurmdm y9gqzdXyGe71sF+hYNzcQ6Gl+2Ib5GRP30SQ8rkyPBVZWl5uMaW11VPr8jH1ofU2lLHD2E7T aCjP9JfCbXV3nJQcK/IRAAAAygH56IgkH7WuiIINVGVif8XYXy1QGNO9tVoLl2sbm3oJQ6W4 tVoz9KJaPvIxLV0l+fxjZeWjc8UNof+YuYS1IFHsYde2qxxbPnodEfLxdMd/70ajnbVdvOsO TdQ+KnOfWnXIYB+zy8eH136zsLDQaDQaq/fvx/IxWnDmuV+8XRH5KCZlfK5NsZ6P6ZrJruFw /wzSRJnbTp5tsPi1+ygiH8VoF1JAPtpnURs2tl3m5IC2g5P6JEbK70gXf46qOuRjhiWqsz5g Ujt0Dsc27K6b634CReU99jPjMM5pT6xbPkoyFPkIAAAA5YB8dESSj5ou1LeY8rG9bo6AziIf NYGobBH2Rz5mTVdPDv9YAfko9FiUV9eQlvBYEjszqrZQnn6x3Ww2R7PgOVYYztA5UpJLo25m WeSjVbPWZDq7kdKjzKPotY/SoGdls71b+pM1TmT3KI681urZbmti8kYG+fjwo98sLCwsNFa/ GsnHu3f/1Px5NeZ8zOJcpiwf1c5Zpiux5yUco+ejeaLJXLuPSfZ8zN7y49/rSMUm46PDI2uI rlCmazR01HPQO8h9eN6svT7Hn/nRudq1tLrO+AIuRT7mNo9mCxhj7a12ECwqPR8BAACgCiAf HZmAfAxtYl2YSz4KBcb7Ix/TMvfy0b2wRtoQ0FHsfmEjAWkWo32jrJ/dbIuHZdkiX4TRd02p qbGnaZ7SLpxUK8KTK3dSFPsUGg+H687LT1buarp+DI5HttnqWYp9aWnpzRv3PvjV0tLSYpQX f/+lIh8f3H73lwuN1a80+bi+vt794NUKyMcsq2H4p8ObpHxUVYg1UNdwSd7KK+JGkEETuXYf k5zzMXvLC6rOWL1arkZ9/ySRj+a1G80V9b9zFGhftasdJH8nXHtOl5exE2XeB9glHxWTmw95 bPiP0gM5lnwUnvnoPiIfAQAAYOIgHx2ZeM/HlMIHg/F7PqpBPqbldAy7JuT0pteqpSzkPjeq OfpXbdTz8W9/29nZ+eGHH4yejw8ePPjmm2++suVjtwpzPkoLRltzzJl64jDMuuyJD+tAfSle 3ZcJK/BGlddKON5v6MsuG4tlW+v8Frx2HxNb7dq6HPvYg46xcrc2SWK9YU1rqJ509HgMG0Hr +Rh1ZhwWmGoekx30VcvHmTZRWPQ814LXonw0e9Tm7/rnWqo7i3mMp610nTe+1/oCSk/N7qjx 1AGZh11bz3z8C3Ks+ZO35yYAAADAU+SjM5Po+ejUhbnko7n49SjIx7ScjgVnCDl9aZuj+tUg H0uSj8LSHJZWMGY/rO+fHD/RRY85OeDJ8agjlZ3Mei519rofn/6kLf3R2DseflQ9lHmBncMf jw6VtX3tlX/t1YFzXbuHodYJzPKFSzPq72yftYOn1tnVfRqN0BiQq55XtbdHhwdC4cqBnUO9 bWMRFhcl33fDYakXKI99djeO2T5jqm2xbaUnQah2zt/UsPLyfXdOt+oUuMklmL8m9ezDDqqB NlNBmnw0axgepU05WqDzJgAAAJx5kI+OFJSP6UJwXPkoLEejBvmYloLmcYB8JKScpC4Zg3ws ST5WmtxdJqFUMgxIhylQfMrRDDDnIwAAAJQD8tGRMeXjZqtjjLPebHWWte6K/ZXEHo4tH4eT SI522FqtJa4zXU2e9XS73e3t7SIlIB8JKSW9Vk02j955S6sY5GNxkI8VxSWkTnb3sVRTvQt5 BpuPhzWzKgAAAMBEQD46MqZ8jLsfxgy1oL7szEqrH/YcpXnl4/AoZe2ajXC0wuu6tQoNiVPQ PA6Qj4SQDEE+Fgf5WF2sFavjobj0iJwWwhSfEyrWnHaghLMAAAAAIB8J8QT5SAjxBvlYHORj tTEmN+ROTYPRfJpleN6T3U5Dm+uz9GHdAAAAcFZBPhLiCfKREOIN8hEAAAAAAEAE+UiIJ8hH Qog3yEcAAAAAAAAR5CMhniAfCSHeIB8BAAAAAABEkI+EeIJ8JIR4g3wEAAAAAAAQQT4S4gny kRDiDfJxihzvN8ZefyNendnOGGv7HnS0I1lxpeokq7UoCzqfTqLHu7zlYkbr3lRxURr1h1nf P9HaxFthu+km8Nic7CqLMxX6Q6H94SplIfKk9bLXM/WQyV07AACcMpCPhHiCfCSEeIN8nBLJ m23xxX9Pdhvj+IWjNdVQREs/82pdeca8y3NK7MtKkVNR4ZV91I/3GykXftDxyUe56Sb32Byt FfhjdRiqOrU8nuzVx73FWQ4pdO0AAHDqQD4S4gnykRDiDfJxCsSdgNYOnuzVi7/TFn0xPhtW a+7hNqWSQSGl271Z47m/fvmYq9hxKCAQpybvSpKPU5OnAAAwFyAfCfEE+UgI8Qb5WDqKDpiE fDzoFJULxUuA8kE+ppJBIeX1d9PhZLeRprcqIB89NUzjaG1K2rcs+Vjg2gEA4PSBfCTEE+Qj IcSbOZCPh2EyJ5o8j9hhKM2PZkywGA03TqZ/s7avHbimYIvRZgTLOVa0uHzM8bJtIuuJuB3G 0RbepnMM8T4MtRPF99ears5734eo8/rJ964EHJMVWtN6alenVmzUYo29Y/Vj3ALxbdKeW+vu aLN52q7KnDDUbDr9RzHNToKum+7cZ9R01u1Orn/Y7PZPdWJPReY/F15yy8f0phv/sXFWftLy 8clePe79PTxp8nyqNdQfWvtvnVF5ax/nL04tv4h8zPGnEgAA5hvkIyGeIB8JId7MgXz86cfR C2fyQhv5heFHYZSfrtj0l2FzPOaTvXqwFnbc1ix6H1bfNvONKywsHyfQmctR87iFxy1cVQmj 8pOPkujUKmC85JujHQ86Qb2zVneL5oNOoF/O9DoMSssH6ZejNUXcVqbRGDZg/LCNHtShQUuu xdSdJ7sN66NaH0uy6D1e9V9Q3JLTH6TsuF/eppthz0fPM58Rz8DeDJUXm8772FglO/8o5ZeP 8oD3ZPaJp/qEleofBGOazmg346E1K2/un+UXV0Q+5vxTCQAA8wvykRBPkI+EEG/mST7qb7Pa i6XRmS7e4nzDNN63hXdUVQ1Yb7xPZyQfS+v2mB/p9V69WbahO95vpLy3G0PC7fuueQ1hRZFp jla2njrLq0ri1X6MjUcx+mjKQaN8ye9o9fHMeOjw9VMfauo2aOlNN2v5mPLMZy8kpf7F5KPz sRlrNsPcDSgfqF6y2oaj7ULd1D8gwiOtNWP2X5z/r2i1x+wDAMB0QT4S4gnykRDizRzJR/NV UHvVNN9L0ycdM94/BSeoFi69rs9CPhZfQGPyvdvEN/k02THeaFNhekqPgBtPPurjju0xqvoQ 1yAQRKrReVDvcWa2jP0ApPY7sy5k1JiiHNE22h303O3sbO3Smi7tMrM0XbnyMbXy/mc+W/mp TV1IProfmx+FXuSF6ul4MKSmsOSj+b+d9z3a6HtUxvjFZflPOHmuHQAATifIR0I8QT4SQrw5 LfLReKW0NUraTGHp8lEcuzcD+Vh0AVanFChCBhFjGTHBBeieJ6t8lFzqdNdp0S5f72xrX5f9 4KU9EukWKWXiTq1BXJNC2j8He5+p4DRKnqabdc/H/PIx257lyUe7hSe3aHjqr88rH+WWSX3m rXKy/eKy9h+v9oLpAAAwLZCPqelt1JfC5YRmv9zTDbZWa8Nz1TY2sxzRXl9e6qz2XF/3V5bC emtrcjU8i0E+EkK8mWP5KMwPONzH7F5nWirnWNeEyvV8LPgaXIp5fCq/yUtTatpzGo6+Mu+U Mey6zJ6PxRk9dUdrabPRpTVgni6B/p6P0p1Kvq3MqNLMPR+ly6mOfBzv52nPIZun8pnlY2pb RRra8W2e3n/WNKxSNabW8zHXk5P72gEA4HSCfHRms9VZ1sxdf2UpTDV9RRM2E+eYWRq211Os aNgMl5GPhYN8JGSMtJtLS0tLS0vN9uk/q5r5lY+2/ku2mEJH7PiTXT4KL73OF+x08svHQt0e U/1CMYQ3ebu5RlsMmSj31MssH4VnIIPWmTBxHezh5Nk06Djy0Zr/LnWRJbmqKWs0zYTs3fcM /L+IKcrH8ZW3r/0nKB99/+HBORNC3gZ0tIZXPoq+L72nszbra/ZfHHM+AgDAOCAfHelt1AVt 11/J3idx7Gyt1kYaMWxm62gZycelcMV+4x522yxFPsrtU8Vsb28XLAH5SMpIr1VbMlJrlfaf NqYT7ZqmpgEnclb9dtilqN/L9+n//b8bzaXaB5uqfOz+/leLahbi/PKdW1WRj7Jjit+irSVN 9BVjjPWFn3rlo7WIarxU64TlYzyJnvjynEEVuQ7PaB7Tzu65ImtJZbuqsfayVgHSV4yxl5H1 yEdzeQ1rqd9pcLLbMJbk1q5O0zreBWf0Yq3VbMzZM63lqkdFWcrJKNBemaQ6C85kajr7eoVF YKYiH3P9pwifPFWf8yd7obBnNvlotmT6KkkZbk0GUla7TpWP8nLV5srdoyodhkGjnrK+vPTY GNd10BH7q6Zde84/lQAAML8gH+WEzXB5aT20tkfdIQXTN6mTRmazt1HPeJb2+vLS+kpTUKJh M1xurpc17Hp+5GO32y3oH5GPpKwoRmt2PfYmnfnr+RjdhuGR8U1RC2o3re/Vr5XbaMjHnc/e WFx88fdfqj0fP/rNQuPqjFe7dk/jNSRZBMN6q1dWkGjsHQ8/Ksut+jqRxcJxWEKO9SXMmC+9 tnqLydabz3H40MeZMSvvPHs6qTM2Si1gXrW6bkl4lHyMd/PJR/MCw6NpD7v+MV1GmO2zdvD0 5HjUjcuK65GTbplZiC7cD45OjFPYqsve4fjJdOSj+IvQL9/ddK7LP3iiLE9vZWJeNeszn45f 9apXV2/sDX84vqZLf2yODg+Ehs1ZQyfiel9Z5KPVvOIobLXm5h+uDI+Ntk+j4RK7rmvP+acS AADmF+SjmK3VmqOHoybdtlZr4Uo7NpJCD0RtykhBZYqFr7Q26tnnl4zmfGytmz0co+1tWxFG g8dDu8Kbrc5ys6/uEB0Yjd1eVoacK1syX9rs0u12u93ut99+m7sE5CMpLYm2mrSpGxY8BZ3x 6AAAIABJREFUg86UY2vAidjKQoX0WjW1paLGSzb0WjVBNo7277XbvcFgsPlBzZaPG7//1Yu/ v6sMu77z7i9/+R9r1Rp27WKc9QTyU5VRq7NmnNaeykjGGchHOFtM5i/MTPqZTquGonycJ6p/ dwAAYIogH8X0V5z6T/0qXh8msXt6v0i9kPZ6hvHasfgbo2dlvOBMVJNEAg5HcBv9E9vrwiyW wxoOFWpcyGars7zUqdeSyuhCdq56Phb0j8hHUlpKk49DFzcH8nEybVDMYPZaNaun47DptA/C 98O45ONvP1XmfLz22sIv312r2JyPLqby3ssqqDFjiJjpvM8XXRMcwMPk5GO1LXmBn9Lc/7cZ /owAAIAC8lFKL6XvoTrto91BUtmSfei0etJxl9VOVrtW66xvVPtp6rW15aO6nI45weVmqzPy m3MoH3P7R+QjKS1+8WZODakrL2viyGZbmkzSUb5tKK0tagXV0cW6ePOecliu+Z253Shb/9q0 fdkvdNyow6ztUdbyNlk+6gvOrP/u0sJvPqrcgjMyJRmuk92GsUANr6ajpsgkYkqSwkdr5gI1 SGEolQn1ra76s6rPx5qjieb4L2SRawcAgNMH8lHKWPJR302ZLNLojZjhjEud1Z49rWR/JWWJ 7cQzxqce9oKMaqUqQkEX2vJRra214rZyrjmVj/n8I/KRlJZ0+Tj8Nv7S7Nynf62PFfb2fFS9 XlSAuiU6TNtSq9VaPaXGw5KtSzCrGX+O97fHgzvaQC/Gde3OsxaJNsWj2MtR2uiXj+vvXVp4 7aPqrXatoczyVkZnoqO9uj6LHO+lMV4RM5qBroyeUCe7nYY2xRsTsUHZTGxiB21uymqouslV SZt6ssKOtdK3AwAAqgHyUcw4w6713XSFF4/LXk6xh4PBYOQN1aPij5utznJtPcwgH2MhWOvI ilDoiYl8zBTkIyktnp6PRg87Q7DpVm8waDftXVOHXdvCzt3z0dU70t17Uq+LVaLYudKqmnpx gotMOWv+tJtWwRORj+vvXVp47dqDGctHAAAAAACAaYN8FDPGgjOp8lHdmKLqbNcZTf64Hg76 K+ljt1UhaJ8I+ciwa1Lp+IZd91o1QQ3GXR3bzeGwY1sxTlw+jvbRfKRwHrFUu6Njqny0t2kn ynTWnDEWn5mcfPz49cXF1649RD4CAAAAAMBZA/koR++KqKS9royJdgy7lqylKCWHETtaDled Tl+mRpePg0F/RT0Lw65ZcIZUOuPP+ajtrH+Z2nNQSnH5KHSMFDWgMLdjqnyU5oIcHZb1rDli qsfJycePX19cvPS7OyP5+MfLz0U5f/78+fPnn3v1A+QjAAAAAACcSpCPjsjTPho9Im35aAm7 YVLlo9zRMl5+ejz5KFzFsD6W4tSv8XTLx9zmcYB8JCXGPd+h2q1Qm9XR3FkTkNYo5TT5KJRX gnw0d8lyCvPKXRWftHzUO5qqJyu84MzHry8uXnrvzkN6PgIAAAAAwJkD+ehM7P5Gtk6binG0 xXCR6nrQaZpSj+U6w2a4vBSutEYL0cgZQz4aS9kM56PMJx/TpsWsVrrd7vb2dpESkI+ktLh9 Yq3V9i7toiSxdS7Fl+3kWcygKgb9GtDSiJnko1SuUPHJykd1zsxBr9VU1+7J0BsyVT5+8vri 4uLrHz9EPgIAAAAAwNkD+ZiaeBHqIWJHSHUHpZfiZru/2pS/cmQ4ztrcX11f28o48nGQGNWl cHkpXGlrSnRM+agVVeUukAXN4wD5SEqM6BPjfnUt8ztrtkRtLkV9+Zl8w65tq2dXUN/i+963 ckx6G3jtY3oh46TXqpnjxJ3rXfdaNeFEafLxy/dfXFy89N76zOXjk726vVayuHFGHHQyrYId 7ZZlnzIW1M5ydgAAAAAAGIF8LBJff8aqxzlInKhBPpKyMhoybff6a7ZNjdeqJZ/bzeRreelr 49heqyVIOWunZjNZw8YlF013aI2qTmoZ76Xbx16rWRsq1HbcudDwk+2WttXodGmMQHeddcyI c0waZrPm7gk5GAxS5eOX77+4uLj4+sffVUI+BkFj79jcWBX5mFQyVe2d7DaCIAjq+yeFi8pB 5rMDAAAAAEAE8rFIkI9nIshHUkaklWQs9aVKMcVGLjXb2mrXknST54I0o55AmcPR7vnoPI+x z6iWYhm1Vs8cIW7UIm3dGbFvpOOsxe+EVpR+JzwF/OqDe6p8vPv+i4uLiy++t14N+dioN3Rx Nn/ysbSiSpGVAAAAAABnHuRjkcybfNSmoXSv6E30IB/J2U3h4cxnJ9G/atG/cMJq148effdd ReTj7v5aEKwdGBuRj5M9NQAAAAAAJCAfi2Tu5ONWqEzU6F59m2hBPpKzG+Rj5syNfAzCo5Pd RhB0DpWNmnxMZksM7DHavsLt/Y/3G4FS/vF+Qy1dkJ5uA+g/1qi8Neejs4SjNfMwa5+xzz5q isMwGI7UjlopjqKAMxGXEySl2edt7B2rH6O7rJw0PFI/ZrvvOQ5nWDoAAAAAqCAfCfEE+UjO bpCPmTNP8lEXfJp8PNltqOIpmt8wa79IwzMmJYw81JHW6fJ4vyEIuCzdD4/WpFoZlbeK8p49 Y8/HTGc3m+6gE9Q7a/XRGQ/DYBy3e7SmGb0ne3Vb8A21YHwJ+vX+mPjB+KTqrcl0392H/3TQ sVu+St1pAQAAAGC2IB8J8QT5SM5ojCkXc0yneJYyX/JRVW+KJ5Js4GEYKN0kPVg7y55OrY+4 +nYe+Ti2TLTPXkA+epvuoGN2dZTdq4zeWXVUDft6lYqJfVqVQpKPGe+76/BoZ7o6AgAAAIAT 5CMhniAfCSHezJt8HNklRVGZ/deeOje6MDSWoatS65O60UDQf5Ke88tH/dsC8tHbdEJTpJvZ TA1ly9O0Al23I+N9T7mbwzHX4w4kBwAAAICzAfKREE+Qj4QQb+ZPPg7l11FirCR/N14HPcFv GsosfU5GoZIieeWj5+z55aO/6YrLRzFW/XPIx6z3PYtKdt5WAAAAADjLIB8J8QT5SAjxZh7l Y2yd1sLJ9XzU9j9aE7rOeRfaLk0++s8+Xz0f5d1m0/NRKBD/CAAAAAAJyEdCPEE+EkK8mUv5 mPRWU+d8zNSnL43YqelLzTz9SZgZcKJzPtqTKkaLtKjdMH1nzzZ3oXPOx7SmKyQfM96FvPIx 433PLh/NhYYAAAAA4IyDfCTEE+QjIcSbOZWPsbPTV7s2Jm0ce9nik92GsbKzUnjSmc5YmtnY beTspBHforaLChzZscMwaNRdCzo7zm5c7/F+QzBoKatdu5uumHy0Vrt+mmHBGQu3Pcx0392H j7nQEAAAAACcNZCPhHiCfCSEeDO38jGSdOaayEnGGXCdcLzfCOQ1sg9DreT4oyn41NkDG41w +G1crBljfeckawfJtcRXkensxuUfPMl89tSmKyofzauLLvDk+Il13iTJ6eQpI8Wuo1LlvYcf HR4IdZv1/8EFAAAAgOqAfCTEE+QjIcSbuZCPAAAAAAAA0wf5KGez1VleClVW2iWdajAYbK3W wuWlzmqvvFOQ/EE+EkK8QT4CAAAAAACIIB/lbLY6y0vrofYxrLe2yjlbJB9L9Zskf5CPhBBv kI8AAAAAAAAiyEc5hnwcDAZhMzS25E1/ZSlcbvYnUBLJkO3t7YIlIB8JId4gHwEAAAAAAESQ j3Js+bjZ6kxoZDTycarpdrsF/SPykRDiDfIRAAAAAABABPkoJ4N8jMdKR6gjsh3HrofCVJJx gXq3yq3VWme1p+1sjfjur0xvSsr5Trfb7Xa73377be4SkI+EEG+QjwAAAAAAACLIRzmWQNxa rYXLtY3N+KPee7G9rvrBFPkoHDsYDAT5GC5b5Y/0on46ulKmpztMbv+IfCSEeIN8BAAAAAAA EEE+yjEEYtjUehem68XJyMeR6DQOSf+WmOkqyecfkY+EEG+QjwAAAAAAACLIRznW+OiUXpCD wUDrnDgZ+ajtoGzpbdTNUdjIx7R09eTwj8hHQog3yEcAAAAAAAAR5KMcRRdGg6Ct2R4N2dfb qE9RPuozPCIf04J8JGTaaTeXojTncTLa4Yy6xn9h8kWQj5/dvrh44+Li9V8sfvaL179EPgIA AAAAwNkE+ShH04W9jbpm95zyMeqQiHysVBh2TchgMBgMeq3akpxaq+c/PNdp5lE+tvuh2L3d F1M+Xv/84uKNV3//18eP77deRD4CAAAAAMDZBfkoJ3XOR4Zdz1NYcIaQJCMzGGvBZEM5AnIe 5eNgIP+R98WQj+032xcXb9+Ihl1/svZv7/WQjwAAAAAAcDZBPsqxBGJ/RRmFt9nq6AOx9f3b 68Iw7UnJR/tws2Mm0VLQPA6Qj+Q0xdaCZehH5OPfvv7jrxT5+P33jx71rlz65OeX1jrIRwAA AAAAOGMgH+XYvRejvo3DLoeaizR7I+ofw2ZYb67X0xazHks+xovhaN0wkY/udLvd7e3tIiUg H8npiaAFS5igEfmIfAQAAAAAABiCfJQjyMeh5jOt35K6cZj2evJVvbU1GPRX1L6QyreRNBxL Pg70xbhX2tIclGSYguZxgHwkpymZ5aMxQ6T63fCAWqs3OljbRZSPyq6ymDROqfTETKmMNZNl bt85XGcmYSgfo2k3oj/R0d/e+L8tRb3Okz/1H3wTy8cbn19cal9cal9cvHFx8cbFxbD1/tov Fj/9xeInP1/4+OcLf3ph4aMXGreQjwAAAAAAcEZAPp6C9FfMWSDJJIN8JKcnmYZdDzdFW7RP quur1WpRMZa+tM4S7xGfQi9f3SE+IP7UbKdXJvkUHRV9yjV6PNKIo66Oas/Hrc1e/N+HVpP/ 6tPsS3Nx3Fy5Qc9HAAAAAAAAE+TjKQjysdwgH8npiakFU9SjpRKHu9hdJZ2lJnu0m+o5zBIt G5nsnl4Z3WkOBu1mro6PxrS8A3vYddz50Zqrd9TnvbdRX7pZ/+Ab5CMAAAAAAIAB8nEO09uo m2/F2uo3ZLJBPpLTE2uUstEDcaCPqtaPicWetYPlI+XB3a6ulWm7p1am124Or6bIajnCml2i fDQm4rALubnc7CEfAQAAAAAADJCPc5jeVqjM+eh5JSaFg3wkpye65xM0oqwni8tHe87HUQnu JW+8ldF3yDffYwH5OJwOMmJM+Rhef+m5P/6v5/5w4fyVC+d//7+e+xD5CAAAAAAApxLkIyGe IB/J6YmhBRPtJ4y6dnYmHF8+mmUaJWSQj2k9GzUBmaMLZHt92Zy5IoN8jFebGW5k2DUAAAAA AIAD5CMhniAfyemJUwsa8y2m9SO05aPpCF2K01h/xtrdNofeyth7jq0fc/V8jJa9Zs5HAAAA AAAAL8hHQjxBPpLTE8dSMJq18wk/Wz6aWxzy0fKbpowc2z5qM0may89kTn/FnL9CW8l6IMlH c7Ld9voy8hEAAAAAAEAC+UiIJ8hHcmoidHTUJmOMtkp79Vo1U04616r2LFHTazVrwyParWar N5D0Y69Va7bTKxN/pZ8kz9IzUTfGpPNj2OzUvcOu2+vKIf2V5vqKRz4++uT1T36+cP3928hH AAAAAAA4WyAfCfEE+UhORezFW+wlpIXOi6myMsPXps9cWqq1emJXR/3AtEVwhsO1R6tdL2my M0c2lVW8VtrJSjKd1d7Wak1ZVUYZna0csh4O+itLN5eXbi7X7nbvffnrpfbFpfbFxRsXF29c /O1GJB+/W+/868LHP1/40wsLH72w8Kd3Q+QjAAAAAACcCZCPhHiCfCREjbRGNhlE/6oNez7+ 7W9/+9vOzs4PSs/H77777uHDhw8Ydg0AAAAAAGcM5CMhniAfCVGDfBSDfAQAAAAAABBBPhLi CfKREDXIRzHIRwAAAAAAABHkIyGeIB8JGcacfTH/JIunLshHAAAAAAAAEeQjIZ4gHwkh3iAf AQAAAAAARJCP7vQ26kvKIqe1jc0STyalvW4srkpmEuQjIcQb5GMWnuzVgyAIgqCxl1bnaLf0 fcrheL8RJMlZgcMwCILOof3VQSdQEx7lrmFj90lJla8klX9sqsjRWvwkSI/i2SJ5foIgCNYO crfkWE9X7oc2y43LV6VKtnzyVzHf38Mze+PUf03q+ycl3rtJNd28PLQAUCrIR0fa68tL4Yoy onCz1Zm2f4zk4/SlJ9GDfCSEeIN8zMxBx/fuEb+ljK8JildsdNLDMMc7Usr759GaWlokCsd8 3z7Zje2iIB8POur2aM9pN2Dpd6eSj02FOdltIB8PwyJ25mitiBfL+9Bmv3FVvsWZW/7JXn3i 8vFU37jj/cZ0/tD52yHPIVV+aAGgZJCPYrZWa9XrctjbqC+F9dbWrOsxZ9ne3i5YAvKREOIN 8jEzOd5nslLkJdY+dszX16grSn3/5KCT5c1qzBewuFPJ2sGTvbogHw9Ds6r2lvmmoo9NpeEl P/oVyz2Fs1DQ8uR9aMe4cVPzUCW2fAk/wLRmyXC6at+46f2uy5GPFX5oAaBskI9i+isVHO+M fMyVbrdb0D8iHwkh3iAfM1NNiyS9DjkHUAsob9rZ5GPW3X58+pP2tinKR+HCkY+ZQT6eYo7W ZmEPCx4+zo0rdoGVaPkSfoBpLV8N+Vjgxp3sNsoZaj2Jdsh0SGUfWgAoG+SjmK3VWri81Fnt uXfRZoQ09owOjxmO3e6vmOpQ3bK1WgtX2oOwGR21Hg402zjcnrAeSjNCbrY6nmqfvXS73W63 ++233+YuAflICPFmHuSjY6ivodgOw0CJtb2+f+KZyUud2kmakcr9cuI6dYazWydNJpfK2OnJ rlU8heL4r6Cl9HxMkHs+muOsHV1LomYcryMYj01ZOCaptKb11C5QbZbRvG+NvWP1Y9wI8TOm TQZqPXLaVKR2C2vtJtw4rfCJCYXMj40Xh+bI1HRWhGdSe2rM1sv10Ga9cekXWNmWl5su+Quj nDQ8Uj86fxF6y6TeuMy/92rfOFk+HnSG/e6H92v4v7WrG/P37vhnMRidRbizheRjnn+kAGBu QD7K2Wx1dHWoR58RMmyq/rG/ok7U2NuoRyYxg3w0T2d0dbR6PobNoaaMU8nR4rNOd5jc/hH5 SAjxZh7koyy8tMFxxluNOWnXQSeod9bq7okR9ZkH5TPmnhPKe/YCPWjMMx7vN4LG3kGu0WGZ 5GPu0aCyfPxJtQbORWmGL5Z55prksSkB6U7pjXm0FqiN+WSvbs+jZ9zW0Yv9UMQkbWLqzpPd hvVRrY/VMvqzbSpvfdbUoqgaRTxd5hZ2H+JsOqUO8lNnV0boa5z3ofXeOIUSOpGV3PLGUyf/ AOM6xLupPwrPXxt/y0+m5+MMb5z7kuPtcTVG/1tV6im/d2umEb0dMv3ei8rHnP9IAcCcgHx0 RulsKHVs1BzfSCNutjq6EBT2kbZI3tAnH81VcXobdZctPcPpKsnnH5GPhBBv5kM+CrIjsmyu EgyPZr9saG+YwiSJE7ZIaWd/OjH5mLRJvqmpMsjHAuNhnfJR79cz0cG2PDalYQ3tt6yupH31 Z9J4JEYfJWeklO+dasDz/AsCfZIDQgW1IbpXbyEpj42z6TyHS9Z44vLReeOsSyhhzHJpLS88 VC75aPwNcfxNE7+aqXws+cY5DlTrrN7BZLvv9y44Ta0dsv3eM8nHUzvTBQD4QD6mp7+SjHTW OjMaji/RiFurNdf61CXIR+Oo9jpjru109eTwj8hHQog3cyIfrRcMjywwXiSE1zyPy5i0RUrr fzcZ+aiepST5WKiDmEM+ajZk8us+89g40cch2uZXH6dpjSg0Ll+rrVgx+wFw+mixQUa3UmxS beOwF5J4r52HZxbf6U0nlT+etXd2AfY3neepyzgXXiGH5b5xY19mhVpeKieDfBy3kWcpH8u8 cSkzEZvy0frfnoaSJKmrzJTblPGnkevaAWD+QT5myVBBRppPm+1RodlPHfhchnzUJnkMmy7v eaaDfCSETCFzIx9tuWCLDEOVZLVIklObG4sUFS50t5n0nI9FX7oyLjgzfk8l/0Xx2JSBdna9 95zdqsNY9zqHfJSby3bBrkni7Gn77H0m9sil3uLsD4PU+DnkY9ZqTMdhZfi2Oi0/Cfnom5fQ 0/KVkY9j37jUyTp88tH3e88iHzP83sf5R3OSDy0AzAfIx4yJ5mQcrQPjGN08bfmobLTLJ4MB w64JIVPJ/MhH7dXLGMJpGSv/2LfT0oUt6gqkvwjlHByd8to8ge4eki7J2PKF4LEpDa3zUY7J KMeSj0qZ+bqMpfeEKqVZRoxnK6y5RLM3nac1ZtDz0f0wTLwTWZktX1g++v7a+Ft+yvJxsjcu +g1WpudjrqbLe+0AcApAPmbNaDJHUQLGmfKwa+WMvY06Y66lsOAMIWQKmSP56Bhi/KOr01Nm iyS8vUhvSiVapCI9KRydB3M4Kddrc9RzpKjkEnWJMH//JGffM24Kj82Eietj37KC3feEw9V3 ftdyN2lnVJ+03IsmZUO442Of0Xc5eeVjxppM0GGlryI1+TkfS2t5oaezMOur86+o969Nhpb3 /94rfeMc98IrHz2/d6GzvL5AzcSe+dn/9x4AmBnIx6xRBjWnGEZtHLQeSy+215cnIB+jctZX Wx3GXIspaB4HyEdCSIbMk3xMDIK1QoL+EhgPs8o8ftaabt9a+tM+5MleKLwE5rZIZo+b4/3G mL119MoLb7/RFH4+YSEve+J/3YrnYhtbl5gLyDqmlfRXnsdm3MdmEpzsNowlubW21SrjXXAm pUHM0sTla7V20BvKKNBeXmPSC85Y/UDH7cybYbXrXPJx+JSqP4Tj/caEHlrvjXOcYkKU2/Jm aYdh0KiL65aIZ/T9tfHduOSo1N97pW+cf4Fvx//2/N6FZmk0rL/Mvt+7v+nSr73YP1IAUHGQ j2L6K7pA3Gx1tHWl2+ujKSAHg8Fga7WWrHAdTRCpfBw6wbCpbO9t1JfWV5rjyMeoZGFMdzwl JWOuxXS73e3t7SIlIB8JId7Ml3wcLYJhvhyqCxGER8lHZd1Mj8cZmqO4hJQFiOPUG3sHZq30 DA/PYpGMwoPG3sGTMVSItg6De9CfqBGFNRxGr4has6j1kysvvDaLjWO+B6oXLjwV7srz2BR5 bIqTJp3NGe7WDp6eHI+my3Re+PBK1Tg6TMmPzcnB0YlxCll56DscT6jp7KvL201MUGC+ppN/ sMblmz/5zuGPR4cH7hNlf2iz3Lj0C6xsy1uP9NqB+ndPnufUXqNpVDH9r02mG2c/9vbvvcI3 Tlb8GeSjcOGCtFUbzfonI8vv3dF04z0b9IsEOJ0gH6W0+2GkF0ckMnEYfdmZemsjHM0CqayR vRSutPph7DGjiSNHBW62OkOZmEU+xg502VKNYTNknWtXCprHAfKREJIhcyYff/qx/Cnbfnz6 0+RnHoRZw2MD02EyT1oJbq5alCQfafmymbR8nCd4NgDOLMjH05BNxlyXGeQjIcSb+ZOP03mB mfVsejBheGxgSkxOgZ3mIZyeceW0fFUpcOPm/r/NlPHQAsB8gHw8BdlarTHmusQgH8lZTbu5 ZKTWOn09rHutmnmJxiarBVK+j/Pm9etvLlpZiNK4WgX5WFLXg6M1c6UR3jFOEzw2MC0mo8CE ZTROE+Zkr7T8nFDoxs35X8hSHloAmA+Qj/Of9rowKpxMLshHchYz9GvNtrbhNNrHwWB4dc12 +qZ2U5GPSVPEO96Iez7eeHNp6Vcf3Pvb33Z2ur//1eLi4m8/UXo+fvSbGcvH0YxUZfRJOdnt NLQZu3jBOB3w2MDUmdgAf20avvlVNtO7Ilq+LCbWINrUlvNheHkYAOAp8nHOE08uudL270py B/lIzmDiTo+qa+y1apaLPDU2Mpt8HLSb0eehhVR3HMrH/77xZop8fHD73cZ/rFWh5yMAAAAA AMB0QD4S4gnykZy9JOOKVfemGbfhkOyzJR+HaTeV6zbl43/feDNFPlZnzkcAAAAAAICpgHwk xBPkIzl7USY1tO2bOONhtJsmLQ17ZxxmdimUijO+rLV6yo6x/kut6pgXnFk+SseO5GOy4Azy EQAAAAAAAPlIiC/IR3IGo5tCoXuj0PNRFYjNdvJp5CGHextDtvUh3saXakVqzWZNL63dqtVa vQn0w8wgH9tNh4kcQz5ee+2X795GPgIAAAAAwJkC+UiIJ8hHcjZjdkbUxZ6s++RuiNYgbsk+ Guu3LAlDvJNN1oZkS97Oj075qCWffNRWu56tfHyyV7cXDBE3zoiDTjwdfXjk3y3LPt7dcldy 4sUCAAAAAJxakI+EeIJ8JGc37tHQHvnoHDYt7ias3yLJR+fxxbs+Tqfn453fXZq9fLSWMa2S fEwqmar24oU+/Ut8+ovKQeazAwAAAABABPKREE+Qj+SMR+sCaHY+zCAfxTkiHfJQSdXko+/Y eZjz8clePWjUG7o4mz/5WFpRpchKAAAAAIAzD/KREE+Qj+QMphdPpjjMSA6OOiuOLR9lM2h+ bZeMfJyofNzdXwuCtQNjI/JxsqcGAAAAAIAE5CMhniAfyRlMu+maAXF8+TjQ1p6RzqR9iXws Vz4G4dHJbiMIOofKRk0+JrMlBvYYbV/h9v7H+41AKf94v6GWLkhPtwH0H2tU3prz0VnC0Zp5 mLXP2GcfNcVhGAxHaketFEdRwJmIywmS0uzzNvaO1Y/RXVZOGh6pH7Pd9xyHMywdAAAAAFSQ j4R4gnwkZy+2eDPt3jjyMdU+WgXZa8dUSD62m/YZ5k8+6oJPk48nuw1VPEXzG2btF2l4xqSE kYc60jpdHu83BAGXpfvh0ZpUK6PyVlHes2fs+Zjp7GbTHXSCemetPjrjYRiM43aP1jSj92Sv bgu+oRaML0G/3h8TPxifVL01me67+/CfDjp2y1epOy0AAAAAzBbko52t1Vq4vORiPSzhlKTK QT6Ss5fY5aW4PcP/9Vqttr01yWjaR62EWqtnlt1rNWvDBWfarWarJ519VvKx16oykKuzAAAg AElEQVQJZ5hH+aiqN8UTSTbwMAyUbpIerJ1lT6fWR1x9O498HFsm2mcvIB+9TXfQMbs6yu5V Ru+sOqqGfb1KxcQ+rUohyceM9911eLQzXR0BAAAAwAny0ZOwGS7XNjbLPg2pcJCP5EzGWgLG tG7WOjTmEcYB5rozgsiMtibl1Fo986hmO9OWcWIcLZxUj9QfNPnuRiIfr7+5qOTF976omHwc 2SVFUZn91546N7owNJahq1Lrk7rRQNB/kp7zy0f92wLy0dt0QlOkm9lMDWXL07QCXbcj431P uZvDMdfjDiQHAAAAgLMB8tGT0yIf+ytL4XKzP+tqzCDb29sFS0A+EkK8if5V03s+7vzwww+P Hz/+voo9H398OpRfR4mxkvzdeB30BL9pKLP0ORmFSorklY+es+eXj/6mKy4fxVj1zyEfs973 LCrZeVsBAAAA4CyDfPQE+Tjv6Xa7Bf0j8pEQ4s08ysfYOq2Fk+v5qO1/tCZ0nfMutF2afPSf fb56Psq7zabno1Ag/hEAAAAAEpCPnpjysbdRX1oPI5eX6LzeRl2dF1JxfJutTr21pe2gqUxt fsmV0fIK68u1jc3kLOZRw4pJZ7RruNnq6NNWdlbzTYo2n+l2u91u99tvv81dAvKREOLNXMrH pLeaOudjpj59acROTV9q5ulPwsyAE53z0Z5UMVqkRe2G6Tt7trkLnXM+pjVdIfmY8S7klY8Z 73t2+WguNAQAAAAAZxzkoyeSfDSWnemvqDqvt1FfCuutrejTUPwl+2s9EMOm8dWwnPa6cNSo GlurNeVjVKXEPwo1NM97ptIdJrd/RD4SQryZU/kYOzt9tWtj0saxly0+2W0YKzsrhSed6Yyl mY3dRs5OGvEtaruowJEdOwyDRt21oLPj7Mb1Hu83BIOWstq1u+mKyUdrteunGRacsXDbw0z3 3X34mAsNAQAAAMBZA/noiSgfV9KWM9harY0032arY/Q0VISjtqeW9vqycRZ1S3vd7L2obpFr iHzM7x+Rj4QQb+ZWPkaSzlwTOck4A64TjvcbgbxG9mGolRx/NAWfOntgoxEOv42LNWOs75xk 7SC5lvgqMp3duPyDJ5nPntp0ReWjeXXRBZ4cP7HOmyQ5nTxlpNh1VKq89/CjwwOhbrP+P7gA AAAAUB2Qj55MQj5qnRDVLVG/SKE0Wy8qHSr1/pLmt8hHI109Ofwj8pEQ4s1cyEcAAAAAAIDp g3z0JJt8VCZn1CdhTJePg9G47NFI7cFAko+D/ooqH80pIEffIh+NIB8JIVMI8hEAAAAAAEAE +eiJXz5GcywaEzJmlo9yIbnko7r6DfIxCcOuCSFTCPIRAAAAAABABPnoyf/P3p01x3Hld95H hMMRjqBIooIUSYgk1FJpo7gLVFGgQIriggIIccFaKJBYCkABSBBcQALgTtTFXI3H03b7LYzH Y0+Pezp86fDF43bYYz89LVoOR9jNsD39zNju59HSLbVaS5OSnotTmXm2zKwNQLHw/cT/gsjK PJmVlVVg/XBOnsjw0QgTSwoftZYDhl2LRxl2XRQmnAGwDAgfKYqiKIqiKIqirEX4GCEyfDSi QCXmq1T4qGxln46GCWfsykwec4SPAApA+EhRFEVRFEVRFGUtwscI0cOuUxnpjo2zHfHB3YX2 fJztiPsJY1i8qOwil+9c6TerBov28HG2I24O1l4VJiYm5ufny2mB8BFAJMJHiqIoiqIoiqIo axE+Rihkwhlv0ph898NURp3POiB8dKbTyYw0TY3U1TGVaVRnsDFnxE4n/EeVyWqC5uOW21xN XSDLTB5zhI8ACkD4SFEURVEURVEUZS3Cx6pkmXAGK4bwEUAkwkeKoiiKoiiKoihrET5WJcLH akL4CCAS4SNFURRFURRFUZS1CB+rEuFjNSF8BBCJ8JGiKIqiKIqiKMpahI9VifCxmhA+AohE +EhRFEVRFEVRFGUtwkcgAuEjgEiEjxRFURRFURRFUdYifAQiED4CiET4SFEURVEURVEUZS3C RyAC4SOASISPFEVRFEVRFEVR1iJ8BCIQPgKIRPhIURRFURRFURRlLcJHIALhI1YJJxmPxWKx WDxZ2mxX5W7/ZCN8pCiKoiiKoiiKshbhIxCB8BHlSyViqmoL6OQDLOXYIrc3zoAnkSpoNWNV +8raKsVykvF40nFjVLM96RHteRI+UhRFURRFURRFWYvwEYhA+IiKCA60qsWS93z0wkJ3DW+B fEb8EyUtdZJxpWGjKXdROamuSB71XRivlpOMW15CwkeKoiiKoiiKoihrET4CEQgfURleqFZk 9rhso5mXfti1m+fpiaF6UqyRZC6V8H72zqS6p1SirGA3lVDbSyViiUQioPcj4SNFURRFURRF UVSBRfgIRCB8RGWUGj6aid0SWYnw0ZYj2sNHsxXjcbXnYnFSCb29VCKWSOWPT3mE8JGiKIqi KIqiKKqIInwEIhA+ojJs4aOcxknjst0ITb7DoMffXHtYDsQiGjbWkykrheyjoO2ta5cTPlpH ZZcrlTAPO9/VUuxPftAMH9WT9HzrpBs+9hyor6+vr69v6rxxo/O1+vV5ezvU8PFcYuu6desI HymKoiiKoiiKqskifAzgZHfH0i3+18vplli6Ua54dko8kso0ag9JtTs5m8vlppKDlkcT00t1 8KgowkdUhh4+KnOXJBKi054lobT3fFS7GSo/ldqw0XMxZB8FbW8oddi1NOTadrfHstmyR3+n evyohY+pRCwWiyenRM/HqdbnY7FY7PXee/fu3u3p6bnT3VRfX9/02mv1r3UuzM3NXRt669n1 69c3Hk674eOJV9euXbu1uYeejxRFURRFURRF1WYRPgawhY8iSfR+bIxl0hFb5U0lBy0r4wlB +IjKCOv5aAZ+Ztqmd75T1tKDv+iGzR1pbUTsI3J7C/2pBN7d0bSU4aP9ZpHGTSblkFV90vGk Iw277ns9Fos9f3JSDLvubqqvr69/rdMfdv3O3vXr1+9tF+FjT/PWtWu3Js4x7JqiKIqiKIqi qFotwscAEeFjfgVliWWrPMLHFTQ/P19mC4SPqIyoYdfaotDw0VimNx7ZsOVotPAwfB/R21uE x4rGWraej363zoqFj/pM2uZO1am05fDR31a652M+fZzww8emTumejxeOPLt+fWNLesZxnJ7m bWvXrt1xjHs+UhRFURRFURRVs0X4GCAyfBSdH7Wh04SP1WdiYqLM/JHwEZVRZPgYOLpZbiow yots2NLpMKBno30fkdvbKIcQOAFP+D0fK9/zsZDw0d2vm7u6j+THXKvh42Tr88WFj2vXruWe jxRFURRFURRF1WoRPgYgfKwVExMTExMT169fL7kFwkdUxlKEj4EBXAXDR/s+yg8fA6eOWe4J ZwoLH/34sbDwMfZ6TwHhY+vOdWvXbk2co+cjRVEURVEURVE1W4SPASLDx1Sm0cwZCR+rz4Sr 5PyR8BGVUcHwMSKfK6Th6PCwwA6IpYeP8jBs20zdAU8uJH008sKCFBo+elFjUh8Fnkgx7Jqi KIqiKIqiKCqgCB8DhIePTna3POF14FZ51tmuzdWwFCYkpeWPhI+ojEqGj5HpY3TDwTNPh08H E7wH+7TcodtIY7vNWbgDg8SgTpnWSasLEDnhjPkMtDtyJlLhE84Eho9iwpm1WxM9hI8URVEU RVEURdVoET4GsIWPcnSoTzVj3yqPno8raEJVQv5I+IiKCM3ZwsJHLbR0ksmU0py/rZOM68Fh SMNaxuckE3H/Lo/qXRmt+4jeXmfr6CjfWlKbCickfrQ25d+VsVjW1DKgG6Wxl/xcNK1TInwU 0WPr5L17BYWPk5NdB7euXbt23c5WwkeKoiiKoiiKomqyCB8DhPR8TGUazbs92rfKI3xcQYSP qAbGNM/xpKPN6BJPOsZ6+YhLWTNk3pn8Q4U3LC+NJx2jW1/wPsynFbB94Bkwp/OOxWKJRPBq hbRZ6iw0WvqoPS91XScZ149KPUmv94nfdnfv9hyo9zx3LLMwNzd3Zt96Yd26ddsP9U1OTo6P j2eO7WDCGYqiKIqiKIqiarUIHwOEDrtOJ9KNscEO8zsu4WP1Ydg1gEiWRLFI0j0f77vh4907 d+7cvn371q1bN6Sej1evXr18+fLMTL7n4/j4eCbDPR8piqIoiqIoiqrZInwMUPl7PhI+rgwm nAFQACcZL7XfZC6XI3ykKIqiKIqiKIoKKMLHAFGzXYs5ZJjtuvqVmTzmCB+B1SKVKCN+JHyk KIqiKIqiKIqyFuFjgKjwMZeb7Yin9UiR8LH6TExMzM/Pl9MC4SOwakhz9hSJ8JGiKIqiKIqi KMpahI8BosNHd+YZefA14WP1KTN5zBE+AigA4SNFURRFURRFUZS1CB+BCISPACKtYPj44MG7 j778ZMX/P0FRFEVRFEVRFGXWl198/ODBu4SPQBjCRwCRVjB8fPjwHz768Kcr/l8KiqIoiqIo iqIosz784N8ePvwHwkcgDOEjgEgrGD5+8snP//Zv3/vq0S9W/H8VFEVRFEVRFEVRcn316Bd/ +7fvffLJzwgfgTCEjwAirWD4+M033/zrv/6f9977m48+/CnjrymKoiiKoiiKqob68ouPP/zg 3/72b9/7l3/53+V82SF8xKpA+Agg0sqGj998880nn3z88OE/PHjw7g8BAAAAYKU9ePDuw4f/ 8MknH5f5TYfwEasC4SOASCsePgIAAABA7SF8xKpA+AggEuEjAAAAAFQc4SNWBcJHAJEIHwEA AACg4ggfsSoQPgKIRPgIAAAAABVH+IhVgfARKFwqEYvFYrFYIlXERk4yHovFYrF40lmyA1tq hI8AAAAAUHGEj1gVCB+BgrkxYnHho5tYEj4CAAAAACSEj1gVCB8BgxsXuuJJx1imxIleKqk9 oC+XkkszkjSXGJsXFXpWEuEjAAAAAFQc4SNWBcJHQJXPAPMRoPgpH/pZez66C/PLzJHZwTGj GUVK66ntip9WrPMk4SMAAAAAVBzhI1YFwkdAoWWJOScZNzs4Kj0QxVJvkZE+2oddR4aUagia y6USK9fxkfARAAAAACqP8BGrAuEjoJCGOhtZX8A9H51k3JIhlhk+OqmEeyBVcLNIwkcAAAAA qDjCR6wKhI+ATrm9o5z8BU44Y7u3Y7k9H/VWV67bY47wEQAAAACWAOEjVgXCR8BGCSClIdhm EOitKd+cMTJ8tDQVvt7KdoEkfAQAAACAiiN8xKpA+AgE8pO/oGDRX2RMcF2Z8FF9aMXiR8JH AAAAAKg4wkesCoSPgEq5g6Ntyml7+Kj3jjTnto4Ydm3EmKmE2QjhIwAAAADUDMJHrAqEj4BC pHz5kE+f+lqfkDqZdLT0MZWMez+nEolUzsgnnWTSujSRSPgjrBOp/OP5Pa9w9kj4CAAAAACV R/iIVYHwEZA5TlK+22Ngh8WYmQyqqaG1U6O9S2R+qdpnUprtWm9uBRA+AgAAAEDFET5iVSB8 BBCJ8BEAAAAAKo7wEasC4SOASISPAAAAAFBxT3j4qNy2TF+8cvcNK51+6zVUCOEjgEiEjwAA AABQcTURPhoxI+EjNISPACIRPgIAAABAxdVI+KgFjYSP0BA+AohE+AgAAAAAFVcz4aMSNRI+ QkP4CCAS4SMAAAAAVFxNhI/xeFwNGy3hoxxT5h9wgz4p6dPvIZlfxdat0lxLb8ZdYNm1tjc/ ctTCR+8Qn8ActboQPgKIRPgIAAAAABVXE+FjLJFMKvGjFj56EZ4eAuohpZ4rGqmi0py72Agx pQjTtmttPeWY1LbdFegHWTbCRwCRCB8BAAAAoOJqI3yMJ1NKF0ElVNSzQSnfc6yZpb7AiP7U TFDKF+UF8aQTuGstW5T2IIePDMGuIMJHAJEIHwEAAACg4molfHSUEcpK+GiMwZbGUivpYyoR i8USiYS6wDbiWU4fnWQ8FosnEnEtM0ykbMO/ldzSMjpcChyf3BtXViPCRwCRCB8BAAAAoOJq J3yU+xUmpVs1Wgc+G4+6YZ/Xh9IbAm0N//z9ipUSKf82j353SUvXRWVRSPjootdjhRA+AohE +AgAAAAAFVdL4aMf3eVnoAkPH9VB0yKwlHpD5vPEgI6H3o6TCaWXoxteJlK5ioSPxI8VQvgI IBLhIwAAAABUXG2Fj1p4pwy7Dgrx3KwxkVB7UIqR1IGDnvNZYyIRV+/gKIZtq/NclzXsmnHX FUH4CCAS4SMAAAAAVFythY9K/GifcCaXy+VSSX8LfwPL7NjB/Q792WnMyauNhkInnAkIH83J t1E6wkcAkQgfAQAAAKDiai98zClTz8hrBQ1nNjM+W16ps6xjCQutg761tDIwfCzoOFAQwkcA kQgfAQAAAKDiajF8VOazVpdIXRMdRxsLbckAQzM/yzr26bGV7FN+MDJ8tASpKA3hI4BIhI8A AAAAUHFPePgIFIbwEahtd+7cuXTp0tTU1EQZsq5x19jY2OjoaCaTGRkZGR4eHhoaGhwcPH/+ /MDAQH9/f19fX09PT1dX17lz586cOdPV1fUvAAAAAAAV4SNWBcJHoIbduXPHcZz5+fn79++X 0w49HwEAAACg4ggfsSoQPgK1anFx8dKlS/Pz84ulum+Qk8c7d+7cunXr5s2bZvh48eJFx3Em JibGxsYIHwEAAADAivARqwLhI1Cr7t+/PzU15f1mKsc91927d70+j7dv3/aSx/n5+evXr8/O zl65cuXSpUvT09NTU1PZbHZ0dHRkZCSbza7073QAAAAAqDqEj1gVCB+BWnX//v2JiYnyk0fC RwAAAABYCoSPWBUIH1GDUolYiERqpY9vmYjw8V4l3HWJ0dbiVo/e3R7n5+eDbvg4Ojo6PDw8 Pj6+0r/TAQAAAKDqED5iVSB8RG1yknEza3SS8VgsnnRW8LiWU2D4mGpuCLSjzbYF4SMAAAAA VBzhI1YFwkfUKK/3o9LRMZWoyo6PblRa2WBUhI93DX3NDa+2W3aUPpQPIJv79E3uuMRoazHP zM2bN73kUR5z7c02I6a6HhoaGhsbW+nf6QAAAABQdQgfsSoQPqJG2cPHKuUe7FKEj3cMqeaG V9uDljsig2zuVR667RIdHsWtHm/cuDE/Pz83N3zspc2bN2/efOC06Pbo3fBxbGxsZGRkaGho dHR0pX+nAwAAAEDVIXzEqkD4iBpVSPjoj822RH/eg4mU+4NoSk4K/btL5jeWmlR3rO3L25m+ XN7UeKy4ILWk8HHizr1FM38MDR9HRjKjJ17evPnAWcJHAAAAACgc4SNWBcJH1CgzfFSHXLvB npbz5TNBecqaRMpvKynFgfFEIu4Hk7FYPJlKxuNJx+zIqO3Lfdg/GlvPR3Uj8VNxPSNF+Hjb kGpueLU9G7Y8nz++0atmjt5oa3Grx4WFhbm5uevX5+fmhkT46I25lm/4ODg4SPgIAAAAACbC R6wKhI+oUdYZr724z3KTxaDE0Ohw6LXsrmksMOJFueOk5WFr+JhfJrdZ5AjyEsJHVXOqoPDx +rVrhI8AAAAAUDTCR6wKhI+oUaE9H61jsrUEUBl2bWvZiwXNNa2rmB0dw8JHJ5Vww89S7wQp wsdbhr7mhlfbs+byu/eljZ32Vxua+6TMsftgQ0NDQ0OiO3PylS3CKyeGrl+/du3a7KwIH8+4 Y65734w//fTTT2/cuHHjxo2vHr2QyWRW+nc6AAAAAFQdwkesCoSPqFFh93z00kIl1tO2qGj4 aL+3Y2jPR32T4ifOEeHjTYMIH2/evHlzrPWVBsPB7ps3b97Mtr/a0NznbnLjxmh2YqptR0PD K6+80TZx7969uxPJHVu2bDlwdnZ29urVfPgouj32tsSffnp/u+NMTvY0P7dxw7Ovnx0ZWenf 6QAAAABQdVZF+JhOpBtjXmXS+cWzHfF0Y2J6qfdehFSmMVZlh1QrCB9Ro6opfIxsOXi2ayWA LLILZEj4uKN9/ObNmzdv37O88+/fvXnz5s3x9h1K+Hjr1q2xth0NDa+0Ze/cnJ+fn1u41fPG li1bEmdmZ69eHTzxkh8+Oum34vvbJ8bGRkZGzzU/t2HDzhOEjwAAAABgqPXw0cnujqUb49kp eUn+x2oNH+WjRYUQPqJGhc52vazDro2os5jwUTveouJHET7eMIjw8caNGzdGT5o9H185OXrj xo0bInx0N1lYWFhYGGvb0dDwRt/N+Xlxq8dM644tW14+Pnj1ypV8+Dg9Pe04zqQzc3HaGR0d HRkZOdP8rQ0bdp4cHl7p3+kAAAAAUHVqO3ycbgnL8iodPqYyjbF0S9FDBrEcCB9Ro0LDx7Bx 0cERYdC2hYaP6vQz8s6t4WMqYa5RQvi4YOhtbtjRNr6wsLAw3rbDHHbd3Os+JP61sLCwMD8/ Pz8/ltzR0PBGjzvJzLWRk69s2ZLounb18uXB4y9t3nzg9PT09NTU1MREz6Hn/Xs+bvjWG51D Qyv9Ox0AAAAAqk4th49TycHG2GBH4HdYwsdVhPARtUkerlxQ/Gike5Ubdq09nkrGvZ9TiUTK XMNJJlP5RfkmS8kew8PHsYWFhYVb1mHXd9xujlr4OKqGj0MnXtmy5ZXW4atXL1++IIWPbXs3 bXp6X4eY87qr+bkNzx48S/gIAAAAAIYaDh9nO+LhQ5jd8FEMdhalZJHTLTHpZpFyU6lMYzw7 JcZ0x9K7k9Mdcfm2kvLKs/JDu5Oz8t5bUt79KDPpXH6QuL9OKtOYmFYPw7thZd5UcjBgvzby M1Vam26JDXY47qF6jbhPsDGW1mLcdELfl7xkKjnYmJhWNldOrHJOlieuJXxEDfJ6PYbnj/p6 UrSnt2B0h/SaLWSJ2l4i5a/hHZdxb0dptuvQ5xBChI/zBhE+zs/Pz49Yhl03HOyan5+fF+Gj u8nc3NzcXD58FN0eB4+/smXLloPdN65duXLpUj58dBxncrJj/6ZNT+9rGxkZGRo6tnPjRsJH AAAAALCq4fBxuiVi8hY3AvPWUbou5sNBe2vWmzNaej5atnKzxfzelfXN8FFJ/bQ4VbTgx5Hh PT3TCTVAVI5W5JvqturT0TaPDh/NENM9D+mEmXvaj7mCCB+BWhUdPt68a+35GBY+NjQ0NDRs 2bJly5Ytb/TduTl/5cqV80df3Cxs2t82OTlz6fRrTz8thl3vOXFy94YNGzZu3LXSv9MBAAAA oOrUbvioBl42ZtfIsIHYStyWylhiPiN8nEoOan0VpUZs+7KFj0aD7n7DH9VoLeubT7doj1oO T1lSQPioHIm0ZGXm+SF8BGqVCB/nDL3NDTvaRs3litG2HQ3Nve5P169fv349k9zR0NDcL37b 3b1799bC1StXrly+fHXuxo2FhYW5ublrVy9NTEyMOzMzMzOO40xOjg8Pj2YymYmJ8ZX+nQ4A AABgxXzyyScPHz588ODBD2vFgwcPHj58+Mknn5R5ZlZ9+Bicr2mKDx8trRUfPpq9EfNL1P6D uVxo+Gh5KDx8NMNKdY8FhI/qCHFpd6Jf5DLfHJPwEahVIny8buhtNsdaWzX3uptcu3bt2rVM 646Ghjd6Zmdnr169euXKlStXrly+fPnSpUsXL17Mz3M9OZnNZsfGxjKZzPDw8IULFwYGBlKp 1IULFyryXxYAAAAAT5yf/vSn77333ocffvjo0aOVPpaK+fLLLz/88MP33nvvX//1X8tpp3bD xwKHXYeFj7OBd3IsPHyMmSVSuUqEj2r8FxU+BqaBQeGjlg/KjRQdPqoNereq1PLNpUP4CNSq oPDx9r0CG7h32w8fh455t4d8/SzhIwAAAIBCfPLJJ++9996vfvWrr2vRo0eP3nvvvY8//rjk 81PD4WPBE87Yl4jbIPoJWkV6Pobu/YkIHwP3XlT4KC+MmCSnQggfgVolwsdrlTA7O3/n3qL4 DXfvzg0RO4rkcWZmZnp6enp6empqamJiYnx8fHR0dGRkZGho6MKFC+l0OpVKnT9/voL/fQEA AADwRPj6668fPnz4wQcffFW7Pvjgg4cPH3799delnaIaDh8jh/eGho9G8Fdi+BiYrK3CYde2 Y7OGkkuA8BGoVffv35+cnJydna1E+Jh39epV0e2R8BEAAABAuMePHz948OCLL754XLs+//zz Bw8ePH78uLRTVMvhY773YhHxn7/ESOvUJLGICWeCpnIuN3w0G9fns44+tqgJZ4Jn4zHiReVU h860oyJ8BFCe+/fvT09Pz8zMzJbtqksebS2Sx4sXLzqOY465HhwcPH/+fH9/f19f38DAQGX/ EwMAAACg+j1+/PiHP/zhSseDS048x9JOUW2Hj+7AXi0mC5zyRVqizleTTqR3xwcjwkdLb0F9 7PZUctAN2soNH/VoNZVpjAWHj/kbULpHkj8tIeFjvkFvoZ51KmnmbEc83ZLIBM12rQadsx1x 7SG1j+TSIHwEatX9+/cXFhYmJycvXbp0tTxXXHKHR5E8irs9yt0eM5mM6PYobvjY29tL+AgA AACsQo8ePfrhD3/4qNaJ51jaKar18DGXMyd+aUnORoePOS/Oc0M6J7vbC9QCBhGnE2llE3Pv 8WxHatqyL6G48DHnhpvuZDhBQ5st5yGTVroc2sLHnJ9RNuoBbi4nTRojnZ/8OvJDeiTqTKeT GftDS4nwEahV4lfJjRs3Ll26JMLBkmVd466xsTGRM46MjAwPDw8NDYmujgMDA6K3Y09PT1dX 17lz586cOdPV1VXZ/8QAAAAAqH4imPtVrSN8RC5XbC/CiKRyGY9kWRA+AjVM/Da5ffv2rVu3 bpbhhmthYWFhYWF+fn5ubm5ubk7cDlJ0jRTTXotekGL8tbjz4/nz50dGRir7nxgAAAAA1Y/w MRLhY+0gfAxB+AjUtsXF/CzV5bjnunv37t27d+/cuXP79u3bt2+LXFLEkdevX5+dnRUppJh/ JpvNislnstlsZf8TAwAAAKD6ifDxy1pH+LhKpRPSVC3qTSpNU8lBaWB1+Bykr6QAACAASURB VFQ85SJ8BPAkEr/V5CDSiyBv3bol8kfREfLq1auXL1+emZkRU9CMj49nMpmJiYnK/icGAAAA QPUT4eMXtY7wcXWanXKkez5ab9oomXKmlbtPBseU5SN8BPAkInwEAAAAUCwRPn5e6wgfgQiE jwAiET4CAAAAKBbhYyTCR6wKhI8AIhE+AgAAACiWCB8/q3WEj0AEwkcAkQgfAQAAABRLhI+/ rLS/+o9dTU1NTU1NXf/xryreeAkIH4EIhI8AIhE+AgAAACiWCB8/LdUfXm3SXP3DTz/99H98 93sPvvn+XFNTU893/rrkxiuI8BGIQPgIIBLhIwAAAIBilR4+5nPHnt/9G6+x7881NTVd+8NP P/38V7/6/NM/uk74SPiIJwbhI4BIhI8AAAAAiiXCx18U6y9/q6upqalp7vvffP3oc2/pl9+b a+r5jtvaf7ve1NTU8zt/XXTjS4DwEYhA+AggEuEjAAAAgGKJ8PGTIv3BrIgev/pSXf7l9+Z6 fuev8z+44WOxjS8FwkcgAuEjgEiEjwAAAACKJcLHj4vzX641NTU1zX3vC+ORLx5//eiX+X9/ V4SPf6VseUW+P+SV/yI/9hf/oSvoQWUzdavCED4CEQgfAUQifAQAAABQrFLCx7/47e6mpqae 7/zf4avp4aMIF+e+n9/z9+eampqauv7DX4hH/8sV/waS35+Tmlc3+5vf7SklfyR8BCIQPqLG pRIxIZEqfCMnGY/FYrFYPOks3ZE9SQgfAQAAABRLhI8/L8ofXmtqamq6/ke/DF/NDR/zP/7+ bFNT09z3H3+R//mLxyJInP39n//85z///WtNTU09v/s/f/nzn//851/86Hd73Oa1zX75q/8+ 19TUdO33iztkwke7qeRgYyytVDw7Za7nZHfL6ySmtcfTibTeTiy9Ozm7RIeNpUD4CC9pk+RD N/WRZU3ivMzQ56aH2vGGhIrKmv567mL7lvKey33K4Xt6ghA+AgAAACiWCB9/VpTvXm9qamq6 /t1CVuv+nf8hfhIh4vc+l1b49H9+R6SPP/vZzz7/nugI+Zt//rOf/exnn/7qq8ef+5v1fOev 9Wa//edFHTLho91UcrAxlkn7C6ZbYml1ST6glJJEsc5gh/RVPJ0ISC3x5CB8RC6XU2M6NSnL Z3ErEJ8FH5P3WAHhoNeK14SfLgY+qQr1fCxgTyvi7sLVa5nzM/3nZzJTNxZuF7AF4SMAAACA YpUSPv71d3oKyf+U8PHPv91tBpaf/tF1b+Hnj8U47Kamps7f/HO1EZOXaRaI8NHOCB9zuVRG iRqd7G5LH8bpFrWPJOFjDSB8hMtLypTEzUnGV270sR8/6kcgHikk0jPDxwL6IxYdPgZsUG09 H+/dGO0cj702VLd36NdfH6k/OPIb+4fq9g7H3ppIzdwN25DwEQAAAECxRPj4UVF+8UfXm5qa mq79Qfhq+fDxLz/66KOPPvrL3xHho22Vb//go48++uijzx9/494Jsqmp6fJ//uijjz76wbe7 5ftEer761S+KOmTCRztL+KimjemE3hFS2jDd4n6NJnysAYSP8PhRn5+VpRIrGp0FpY+FZ4+2 8LHwjQoOH93ktopvEnnv0sU9ieFfS4wePn9N6u14/+bly6dPZn5973Dj2avzQRsTPgIAAAAo lggfPyxOfoz07H82HvnBb3ZedpeKZPG3//LDDz/88MNf/Ld8zqisLbpD/rdfSE0/dieV6f7N HwRsVgLCRzszfJxKDkpDqmc74mF3gVQyyuDwUb4jJDeCrFqEj5B4QZ18z0cpT9NvxKjkeXL+ Jo2YDugLKD8stoy4A6PcjnZcoYdlCR/tSaHlLpPmTi2PWW6Z6e0sIJPUdmUd5x5xHot1cfrF 14fWHL945Z798fnxyW37h7d1XrM/7oaPV0893789ltoeS22vH2jLEj4CAAAACFRS+Pjh5z/6 3R7RPVFd/oPf6vaTQiV8/DA/Vvu3fqCu3dQ0973PP/zwwx/8Zmfnb+Yf+8WX35tramq69gcf ejnnVTPnLArho50WPtpv72hML2M+FBI+mmlmS5UMO4SK8BEKZW7oVELKvPKPaFPRWGamiScS 8XjSscR+en9CdVCy41jTNUv6KGePoYelHFp+L/KRGvGlfmT2I/VWD80z7XvSDlhrqrDzWLzr pw4P/8bJmcCOjblcLpebH8yu2Tv8+rDtHpCLi4uLi86bsf7G16fEb7vsyYHt9X3N3YSPAAAA AOxE+PhBsT758it3gPTl3/OW/tlvdTc1df/2X4qf/ms+fHS3eDcfWObX/7N/39XU1DT3/Uef ffDBBx/8wbWmpu7f+jP5kT/67IMPPvjgs0diR53//s/8/fze7/k/FITw0c4y27UcNYpJrkPC RzdwtM12nQ8cGZH9pCB8hMYP++JxJe9KJeQUzYz5zJQwIPfTUsSoXn3GrC1qv8eowyqg56O5 itGMNs7bSB8jujjqEa7lBpTeosjzWLSbA+O/tn+8Z+7+zekr/ednMlO37thXvJ/pGK57c2rG fGRxcXGy9UJjbKTfH3Z9qe35vu3PjYwSPgIAAACwEeHj+yX47NE30i0aPXPf+/Lj99//T5ek RZf+0/vvv//++x9/+ZW6fvfv/s03jz57//3333////p2d5P9kfff/+xRfiC2p2v2v/5FcQdL +GgXMNu121GxqPAxKGHUZrBBtSJ8hC5wqG8qEZobWvI3e7e+IsNH/V6UlrHgYS1Gh48hU9Ko zZgtFBk+6sParQcYeR6Ldbvn+NBvtDun3x6u2zsk6tcPT47P2da97Dy7N3N80li+uOi0xPob 4+MT0j0f+w70ba9PJ8cIHwEAAABYiPDx/yvVL41A79EvjeVikbn+V19+7C7/+MuvvrE/Yn34 0S/VxyMRPtoFTTjjBo4VGHady+XzR71bJaoM4SMM1ogsl8tZb4tYUPgYMCi60LmglfTRMv12 6GFFh4/KUHN1o7B7PpYQPlr2ZJ7u6PNYpEuv7x/a1Jyp2ztUt3946+HR39g/VLd36DeSl266 a9y5cs25Ima7vnayeSjed0NvY3FqfHesv/F1R55wZvzEwPb63uYue/jYvqt9y7q2zWtPbl57 YsvO3tJ+EwMAAAB4cpUZPj4pCB/tLOGjMslMZSaccYlulZa5s1ENCB9hCO+fFxiRFRaaBU3b UtgRxRJJNXuMPqyKhI/aKmabVRw+3ri4Y+/wr+0fqts79FLqVi6XuzeY/bW9Q3V7x86Kj/LJ yQ17h+r2j3XO5nK5++mTQw2d1/VGFvtGGmP9u1qvKrNd9wxtr+/defyiET5m3mrsaFh3rk30 fDx3+oV1ycr+JwYAAABA9RPh4/9b6wgf7aLCR3EzR2+6GEkq0xjzp44p+MaO0y0Mwa5WhI8w 2MJHIzYrNXxUJrEpnNeSeiPKAg6rAuGjcUJKDR/LHXZdUvh4b2aPO9pahI/z6fFf2ztUt3do R/p2LpfLXXS27ffCx9s9x8sPHzt6GtZ17G/zh10ndxI+AgAAAKuOCB9/WusIH+2Chl37+aD9 to96j0jCxxpA+AhDWPgYMnNKIaFZ6SmaNLRanwQn/LAKmHAmKkiNnLa74AlnbFPH6Idc8WHX Vw41Dbl3exxec3D4190ssu7Nqel7uVwud2f+xvWb93O5XG7u4o791mHXxYSPp/eeblh35kgf 4SMAAACwqonw8d9qHeGjnX3CGTVGzM+I7eePsx1xvTtkSPiYTvgdJHOpjL0fJaoA4SMMxvTS 8kI3jkvE3fwtlUwkHWMNy0a5nO3GiYUGavYpn6MPq4Dw0RxV7TaTX0trI5WMez+nEv4sOHIL yVTECZCn7g4/unLDx9t9x/2pZrRac3z60m1vxWsnDw/X7R1NXjTaKD587GhYJ93zkWHXAAAA wOojwsd/rXWEj3b5YFEqe7dE0f/RK2PemODwcTqdVLZtSVlWQjUgfITCmLvFnhvGk463Zjzp 6JliPOkYTSX8NE7euvBULb8PfXaasMPSj0HOEZXDUteUmjHGVYuF2gTc+nHYzomtM2bUI8Hn sSj3RiZ+IyB8rNs7VPfacP3BkfqDI2Iiml97a/qq2UQxE86Mvd14umFdVzuzXQMAAACrG+Fj pFoOHwEP4SOWjTkkOmRibVTSrZ7gzo9qZY5m71saWFx0WmL9jfHxCSl87DvQt70+nRzTZ7s2 h10TPgIAAACrkAgf/6XWET4CEQgfsVxCx00TPi6xuUv7X49MHocbu6/ds26+uLjYn+hvjF04 NemFj5fanu/b3pS9dUsPH8WEMw27UoSPAAAAwGomwsf/U+sIH4EIhI9YNpZujvlFRI/LYe7y 4TeD+z/uH9mTnrcnj7lcbnFxcXFqfFesv/H5sYl79+7du9d3oG97/UBy/LYlfLx8uWNPR8O6 9heazxM+AgAAAKsW4WMkwkesCoSPWFbGPSVLuYchSnb30vmJ+EE1gnxtePtJZ/SabbS1R/xW u3/feTPWvz2W2h5Lba8f6rtz5/Zte/g4MzPTd+g0E84AAAAAq9mjR49+9KMf/eQnP/nftet/ /a//9aMf/YjwEQhD+AisPvdu3rh2VdStO4Vs4IaP95XZrkPDR4cJZwAAAIDV7fHjx3/3d3/3 8OHD/6d2/fjHP/67v/u7x48fl3aKCB+xKhA+AohE+AgAAACgWI8fP/7pT3/67rvv/uQnP1np kHBJ/OQnP3n33Xf/7d/+jfARCEP4CCAS4SMAAACAYn399ddffPHFP/7jP7777rs//vGP//mf //knteKf//mff/zjH7/77rv/+I//+MUXX3z99delnSLCR6wKhI8AIhE+AgAAACjB48ePP/vs sw8++ODhw4cPHjz4Ya148ODBw4cPP/jgg88++6zkbo/fED5ilSB8BBCJ8BEAAABAab766qsv vvji008//fjjj39eKz7++ONPP/30iy+++Oqrr8o5OYSPWBUIHwFEInwEAAAAULKvv/768ePH j2rL48ePSx5t7SF8xKpA+AggUnj4ePPmTcJHAAAAAChWZPh48+ZNwkc88QgfAUQifAQAAACA iiN8xKpA+AggUjnh4+joKOEjAAAAAJgmJiZGR0cJH1HjCB8BRCo8fJydnRXh4/T0NOEjAAAA AISQw8fp6WkRPs7OzhI+oqYQPgKIVGD4eP369dnZ2StXrnjhYzabJXwEAAAAACsRPmazWS98 vHLlyuzs7PXr1wkfUTsIHwFEKiR8nJ+fJ3wEAAAAgMKFhI/z8/OEj6gRhI8AIpUWPk5NTRE+ AgAAAEAQL3ycmpoifETNInwEECkyfLxx44YcPl66dMkLH8fGxggfAQAAAMA0MTExNjbmhY+X Ll2Sw8cbN24QPqIWED4CiGQNH+/evRsSPl68eHFqakr8KiV8BAAAAACT941pamrq4sWLIeGj +ApG+IgnEuEjgEiFh4/Xrl27evWqCB8dx5mYmBATtz1+/Hilf60DAAAAQBV5/Pjx5OTk+Pj4 xMSE4zgifLx69eq1a9cIH1FTCB8BRJLDR5E/it98d+7ckcPHubk5ET5evnxZhI/iV2k2m/37 v//7lf7NDgAAAABV5O///u+z2azoriHCx8uXL4vwcW5uTg4fxZhrET5638sIH/HEIHwEECkk fLx9+7YIHxcWFuTwUZ7wemJi4k/+5E9W+jc7AAAAAFSRP/mTP5mYmJCnupbDx4WFBRE+ejd8 JHzEk4rwEUAhwuec8cJHcdtHL3wUc85ks9lvf/vbv/jFL1b6lzsAAAAAVIVPP/3029/+tggf vamuL1++LG746IWPpc02k1vm8DGViMkSqQI3iCed8neOJwDhI4BCRE54LYeP2pwzYijBd7/7 3ZX+/Q4AAAAAVeH73/++uEWVdbYZET6WPNV1bhnDRy14LCyAJHxcZQgfARSikPDRnPDau+3j 2NiY4zjf/e53mXkGAAAAwGr2+PHjP/7jP56amhobG5Nv+KhNdf1EhI9OMq6HjV4Y6SeLYpGc NBI+rjKEjwAKERk+mnPOyCOvx8bGxMzXi4uLf/qnf/pP//RPpJAAAAAAVo/Hjx//0z/905/+ 6Z/+u3/378QM12NjY9qYa+tsM1UcPrpBoxoieolkPpC0JI2Ej6sM4SNqVkDn74JuQFE492O1 km1WzHRLLN3oVyZtWT7YIX3apxPpFvOJONndsXRjrL8x1t/S5+ePd+/ezZ4c2F7ft72+d1t9 z6vHHGXkdUfPM+veaVh3qmFd+5Z1bVvWtm5+tXNkZGR0dPTkqyc3r23dsi6p1QvNAxNBWs8o K+/sLXTN/Mq9+4zdqXWqpcdvI7lTeXRfq7yDgZZttha2dXYbx9LdfEpd7UyykAMu5GmGSrb2 TvR0vlBKCwEnqtQj0eRPSIVaizLQsk15WUPXdF+d1jPaxRBBnGfzGpCX69dJ7z7rlRBKuybD rqhy9SZbxStVzHkonnhGwe/6gWTrgHh3hH0ySLS3W4FbAQAALCdxQ6qxsTHxzSio26P1ho/y bDOLrpBvg3WR3xfLDx/dr8N6higtN7+Xx5OOHD76fSf1r9XKppZulBFfxo0955sI3F4+EqVV IylVFojN4klH3qN8RtR2qzM7WHKEj6hpRodvb0GF3vD+p0vVfoKI6DCenVIXpxPp3clZddl0 SyzdmJi2NtOf6G+M9TfGRvq1zo/ZzM76wR5l5PXEsWfPPrP+zMuHM17nx+7mU5vXvnNidHRk ZGRoaOjChXd2PvXW0y+d6u/v7+vr6+3tPbn38MY1hzasadl3oqurq6uzs7Ozs/PcuXPnziX3 bjq4Yc2hvW+fE86+/da2NQc3rDm05+2zqmMvrjm4Yc3BbbtavUUHnzu4YU3LQfHQc8fySxMt 8mpHdx3asKbloPhBNL7praNuC0d3HdqgLvFX8xq0HdLB59QliZYNaw6+mDhrpa8s9uu1XwLt CIuinh/xo3+KynDwuYOWk7kkWvdsMq+QAG+/tc1/vq17NhX8TJXXtHXPJvksHXtRvRTPnj17 8Dlv5WMvWi7gSMdeVM5e/oIPuqjKcXTXIdtbrILE6Yq6RLVLsdBmK3CtAgAAhDhnI77CdHV1 dXV1dXd3d3d39/T09Pb29vX19ff3p9Pp8+fPX7hwYWhoyEseJyYmtG6PRY25Xvnw0f0+bHwb 9h8IDx8N9iDQEh4ai637t61p3962hRYjhIaPgVtbGq7a8GAJET6itpm9wCscP1Z1z8e8dCLd GFO7NDrZ3X5HSFcqo3aQ1BtpSYw0xvobX3eCwscbN27Mz0+d+Fbn1vXnXn/nqnLnx57OF9ae Pjk2lslkRkZGhobO7Hzq6NMvdaTT6f7+/lQq1dfX19t6vHHNmxvXHN5/sqfb1Rxv3rCmZd/x Llln5/GX1jRvWHOkudPTtm9T84Y1zS8d7FQcPLJh09FjnW37NkkPHTyyYU3z9t1t+R+PH92e b+r4S2uaN2w6eqzTaGRN84bnj/tLjh/dri3R1jl+dLu8i3zjb+6TtpA1P9+8QXv0+NGXlM2L ZB5h4bTz09l5bPebG/SnU9Wany/maI3nW5i2fZssV4XbTtu+TfoLul2+tA4eUS/gQhjXp3iV zSu2bMd2v6lfkEvN8pYp4aURnwPFnlgAAIAidNl43196enpE5ihix1QqZSaPmUxGDLjWuj1W cMx1blnCR314tU/9Ih487NpbqDalN6x87Y7+Sm90yFQOwLa9HhxEHL89fLRubGzrOKtypDnh I2qbGT4anwyrgNH50dbtcbYjPtiRyu6O2UZei/Cx7+qpeH9jrP/NPj187L19+9atWzdu3Fjo HNha37l13/Ds7Kx658cLLTs7u7LZsXz+eHbX2mObXj594cKFgYEBEUH29/cn97218amWjS8k RXfIfBz5QmuP4cSewxvXHNq+51T+5+ajG9cc2hg/aax48uXNx070nNq/+eghb1nzUWVb91HR 5svN5t5O7d98SKSibqvHtmu7E0s2Hzth34W/F6tDcbX98plHWDjz4ANPb1VqPrpxTeCpDlhf e7FK2+rky/41oL/ch+L6Lg7Fiz2lcvvSkqKebGFO7Dlc4Qsy0slj281XoeiXRrxVK39CAAAA QvS6+vr6ROAoMkcROw4MDFy4cGFwcNBMHkO6Pcpjrms5fPS2tOWLxtd4e5wXdFj+UdnCR9vA aH8LJb8sLHw0N06kKj/48klF+IjaVmj4aLsLg7bM6FKt9BZXP/nUntW2btzu+k4ybvw9xn3Y 6L5d+seV0vnR2u3Rye6OZ6fEyGtjjHYuHz4uLk6N74r1Nz4/NuHe9vHuxKgXPt68ebP7te5t 9V2Js3PXrl3zpr32Bl9PTk6KyWdGRzt3rz2+6ZWzQ0NDg4ODFy5cOH/+/MDAwMDAqVefOvL0 U8cP+1nk4R1vpkx9yRONa1o2bjnR2tfX19fX8kLLxjUtr7zZV5A33964pqVx3zvq0neatrRs XPN2i22L1n1vKZuIvb+Q9NdQjyf/Y0BrppYXWjaueaspGb6CV36z7vK3W7SDlI5Q3tY9ReLJ Bpw08/y8+fZG6/PNlzjy5CvmEYoNxRL33+qZ94/Ee0g8EW3l1n1veYfqr/CCecqSr1he3KAT qOw9oEE7cQzq2Qu+hJInGs3lb74d/qKbrbwiX2PeEqVly/lUVw58puopyr+s1tfCW9NykWiN v/m2v463wpYTLW6z4gQau3ZPrHcpSteb+eJKLC+B2rh/wuWn5u7RPXv+SXZPmnK6lDOpXAPK +6KIywkAADwpLN9MXP0uETgODAyI3o4idhweHhajrc3k0bvbY0i3R/mGj9UTPkYPu44KH80v 6olU8EDmAsNHc4Wo8DFiUanho+1r/SrqBKUgfERtK2TYtdon2/45IX+YOsm4+ZFo7kBsovxk fjT796aVtlZ2LdY11iuanyrauj3mppKDYuFUclCbhUbIh4+Li5OtFxpj/btar+Q7P06M7qwf csPH6dbnurfV950cmb9+/bqY9tobfC3nj+Pj3XvWnti8o3NkZGR4eNiLIC9c6Ew0HH36qWOv nxoYGBg48tKRp5868urhgbSFiClPHEmn0+mzB7Ycefqptw+021Y0HT7x9FNHnn3tbHCD9k2e fulU/sf25LPyj+l0+2tvP60uEQf/9FNHXj0cfURHXlKOv/21t+XDE4277Zx69akjT29JtqfT 6fTZ9nax7YkD4gC8Y1CPULSgPuVTr4Y+WXll8Vz8JeoK0sHbXojDJ8RhHDl8ymhZfi5qs/qa Zw9s0U+v8Qp6jWhXgjgq78mKF1pax349RNBespCFaXH+pYN3nXpV3W/+KvJOiG195VFxWfpL gs+ndhKsp1e9Av0ftYs/v77t7Wa8L468pBywex7OHjl8Vr2q89vqr4I4zpdOPOte8FHvdO21 Vt477a+9bT8D3jXTfupI+9kDW+RzeOqIOKsB7/3g96b+4gIAgFo1oDp//rzIHLXYMZPJiPs8 ysmjNuBa7vYYMua6isLHqAln1G/F5YeP9m6RuuoKH6X1V3P+SPiI2hZ06wYzejTubKv2V9Q+ FL3Nw+8NkYtIH60fSvZPxFSizH7aU8nBxlh6dyJj6fYoxlzn+2Jmd8cs6aSYCHtxcXFxUQy+ vnBq8r4IH3fVD/XduXP79u1bt8bfqO/eVj/QNT/vTXstBl9r+ePERM/eta2bX+0aHR0Vd4H0 Usi3X3l701Nv73prcHCwK9FwdNNTxxPvXLDpzD/aceHChXd2PnV001OtR60rmo60bnrq6Lea OpWFHW3feuropoa2Dusm2qPix5fdIzvSuslyAOIIRYnjDHT0ZW/NfCmH19H2LenAjr6s7Cu/ 7cvqadKO0DxFR1r1TeSHpAPoaDq+STkznYkG9UR1tH3LW984t0dfPrrzSEjL8pmRW35np3nC /ePvTDTYT6l2cryd+sdgnhzr9RDl6MuWl9W6UDwv5QCk5Zv0VzbkSraeE393oefzQkfTcek5 vrNTOgPiJZaPUG1Kfq+5u7a/U8Sa3vGLq87fUL4Y9J3KV5FHvLPkfUW8WNoBGMfjNqW+Up2J BnUT5dkp58q4wKRHjcvb9qIDAICaNegaGhryMkcvdhwbGxMzzGjJozzguoLdHnPLEz4GDCrW v2QXGz66j9q/ARcaPq7csOugDqH2cZOrA+Ejapt1kivlI8B4/9v/SGMfJ208bHaVtPY3V/oz apvnP8BSCe2x8k23xNKNtmAxl8pIQ61nO+L22bHd8HHxft9Ioxh8fe/evckxKXzMNtf3bKs/ 37WwMO/nj+PHnj3zzPrTz6x/p2FdR8P2nl7HmZrq27eubcvOnvHx8fHx8bGxMZFCZjJ9bzxz fNPa1jfOjgwP97zxzLFNa0++cWbYM+TrPvjMsU1rTx48PTQ0dGbX2mOb1rYdGyrM0bZNa489 d6BbWXj61HNrj2165tRp6ybao+JHuV45Y9+XtKa+R8mxV7znMjQ0NHT6wMnCVz72iu25i/1K R3X6wMlNa4/tOupv5f1bd7Rtk/rslIMxWlaXnNmlnMYzu+RjU868eAXlI1eWyM/r9IGTuw6c es47/tOnnrO/Ut0Hn9FfRNv5UXdtvR6iaK9CyMKho21BF6f9tQskrnOplGcacT4tTeU3t6x2 +sBJ5Ymopyjk+lQ2PNr23IFTu/wNlYtBuyDFVaQ3a7405uWn0J+L2ItlfXGRW66iM7v09eUl 2uWtLREvkHEBAACAWjRsM+LKZDJy5ih3eHQcxxttbSaP3t0ey+z2mFum8FH6Tmt8BQ7okaMs CggfbUMQU8mguacDj0n/lh4YPkZ0KtI6DWlPUA8ftYN3kkl7CLq6ED6itimfGbZPsMAO3cbE Wv4Hi+0+ufrHkEFdwTueeDKZ0BYYd6fUj7lk6UQ6aEh1Y0wrfTURPuZyucXFxfv37/e/3t8Y 63+z9969ybFdsaG+u3fv3Llz+/ZM8rmebfX9raM3Ftz8Udz88erVFfVK7QAAIABJREFUwQPr Tz+z5/zMzMzFixenp/v3r2vfsqtvcnJyYmIim81ms9nx8fHx8f5DW09uXtt2qHN0dHT0xI4T m9ee2HNc5JKazj1rT2xee+pEJpPJ9DVvPbF5bbL5nG1F07FTm9eeeD7RF9ygfZPNOzrzP547 /bz3o7012+ZrT+w5Zn/8xI6o4xd79Mtf+cQO22HLR2hZ0rkn6Jmqz+hsIqkftn4kbrn7UjY5 dko5M8q5Eq+aWe6BHTvltXNiR7L5XOcedy9nE8mAE97XvPXE5q2nz2pLjCernLSIV1BcGH65 h2R5yQIXKocUcBjROvesdZsyX9/I8+m+NH7lj8pyis4mkuoTkXad6WveGnytnjv9vHTx7Dkm vSLHTskHrF9a0oY+86WxPHGZ+Vz806K9+8THi/HS+5eZbYl+Mahn0n+nB73iAACg9oyqxsbG 5MAxm816vR1F7Hjx4kXvPo8iefRu9WgdcG0NHwv59lcXuUYlwsdc4Jfg4G/d0jwsAeFjaDei AhK8gEMKDh/tmwQMm47FYvF43DuggEwh+ImsxuyR8BE1zv4HC9uo65APAOnDSc8eA8PHwKzQ byzflvQhm0roh6F8jpX9GRUQPk63aAOxxezYiWltWy98XFxcvH/feTPW3xgbTk2O7YoNp+7e FbOw9Tb1bqvveaPr5o0bfv54/fr12dmh19efeWbvBTEEe2Ym/dq6Uw27+x3HmZqaEmOxJycn J3o6X1iX3LLtXFc2m81mu95o37K2Nf5GetzUdTa+9uTmrWc7x8fHx8dPvnpy89qTe09YVrQ4 8c7mtSfjB/vVpf1vbj25eW37m12WLToPtiubiL2/2h25obZTdxPdyVfDWhDPztv7yVdPbl77 zknlUf9H2xEaeznxTtCReIfq7q5771q1ffvZs+/65KvqkzJbdl9Bm+69+Xa692492yk9U71Z X/+bW7U2xaujnx/lhEc+IxtxSaiXnHVf3XuDG7e/doGUM2Zc8+HnU7yO3nnzzq19w86D7doF 6T/frrPxsFfNewn639z6zkmpqc6D7fLp0k9g19m4eaLMl8Z2Yet7D3o7WM6POC3yJvKZMZZE 7D1PvDRFfCIBAIAnX1YyMTEhAkeROZqx4+XLl73kUevzKCeP5XR7zC1j+JjLGRGb8XXY+GIb FT7q24iv0E5weBiyQ7fHT2j4aOxQfQ76zLPSrAyW8FF6Wk6KCWdyOcJH1LrAez56HyXRcaH0 6ZRKxrX1goZdR9/9NpGIK59V8WTSyB61nZT7QWUPH1MZLWfMj7xWE0kjfLwvBl/vah17Mzac unv3ruj82D24vb5323PDmZta/jj8+vqzz+wbElPQXL58vmndOw17Bi5evCjuBTk9Pe04Tu+h d7asa3/x0IV8HNnb9cK6ti3bOnsmdT3NHVvWtb3QfD7/c+uZLevatuzsNVY837LtTJu2rPWM sm1Qm0ojbVvWdbR4x9HT+YK8O7F35Th79+mH3bsv4LlMTk627VTbD92wbWfblnX+k9J+tB+h tPCF5vNtO9v2tVr35T8d7zyI0+I3ZW3Z8nTOtJknQWlZnFXjyM12Ws/kN2k9s2Vd275W89x6 zrds00+y7dyquw64HiJYtrK9xPljDn2Che5SbV+8EP7moedTP9reff6LaNmwp7nDOGn5TXqa O8LPVX7b1s4XRPv5q65XeyeK68o/M+7FGXrYkZdf2Elo29lmfS3UN758ZiaNJWHvYrXRzqDP LgAAUMOmXI7jiMBRZI7W2FHMMGNNHsO7PVZj+FjllnS4sxmbwkT4iNoWfEdHsxt0yGeFmw/G 9ezRekvIiM81650ezWNQukFW5sPSFj7OdsTzqaJMzE4jL/fCx5yUP4rB19tjw6l79+7m88dL bc/1bqvv2Xn84k0lfxxJrD+3dd+wmIImPwp77/lLly5dunRpZmZmZmbmYn/vS+tONazrPDXt O7X7VMO69v1tjiq1f117w7pz7f6SwSPb2y1r9nW/uO70kT51Ydu5hnXtLx4adHRms/76DbtS arPykvze/Tb7ul/U2gncqeM4Tvuu9gb9OAePbD/XHrgvv/H2XbZj1reStt1+bv92Y/2wQxWn xTu34gCMs2q0sH/XOf3lUFvuO3Q65Jy4659+cbu3r9T+de0v7jr3ov68fObZsOxFOzmhL02w 1P517Q3bu/3T0Nf9onEF9h06HXyuxMvRHXIiw/fYvqtdvjJDzqd4yD829QyIduQjt12Q+XO7 f1foS+82/uL208oFs+vcfvWZWg9JP3jzpbFf2B7Lu8O6i75Dp/UrPN+m8aKob3/zXCnHpr86 oW80AABQK6ZVF13ia474yuPFjuHJY+SA68LTm7rINWo4fHQc6Vuv7f5rldwX4WMBCB9R08yO jmqnaO0WDUqfbzXoC0r/zPmqbPtUp6o25ri2fBjmFwXPDlYKS/joZG2TX1tGXpvhozL4+t69 e/fu3c0Pvp5oru/dVt+j9H88l95a37l1/8j169evXbs2Ozv0+vqzz+wdvHLlypUrVy5fvny5 o/uZ9e88s777HSmOnJmZmZkZfquxo2Fdx0stw+6SdNO6joZ1Z95Kz6jE8o6GPf4D/S1nLGu2 d6kNym30vqQ13t7VsK6jobG331xN2pG7YUdTu79V/t/+o10dll3OzMzMdOwxnlF7l7u+OAP5 R/tbupr2nJGb6thja9k8QvnpmMuNdZTzI7byjtDydNId7XIT4rUwjkpvOf/iNknbdrTLx5Zu Uk9+xx59fdvBa6+4thfxo3RsIddDqP6WM9KG+qHa96VIN6n7FQ0ajSjrq4/mr3m3keDzKV6y /LbDb+3pamqULgPtBW3veqnR9sZRGgmhP2v1RCkLpUO1nUDzpQm6sO27Hn5Lepryu6xjj78v 7UjUH9NNe3rlRmyfP8Md7cPu0arvkfA3GgAAqEWXXJdd4iuPyBy12DEoeQwZcE34WJDQOzhW GOFjIQgfUbPMjxtz+i1jVpngzyUnGdcX6xspYWPAI9KG5rw1ckDpz3Ztb6NIIkz0KjGd0+aZ kXJG0e3Rq5ZExv/RnQXb6/w42XqhMTbcf//+PSV/dMdf1/dsq+/ZVt+9rb7vZGZB/H7t3N+5 df05t85uXX/2mfVnn1nfdezCVTEoW5b/jd3R88z6037tPX85iLamtvL51MvKo+fetrV0eq/S woEO+cHM240BLXi73nvebCTwmM0DtjR+/oC78OXDmYHD59wDUw/G3YW3wjPrTz/TmBpQ9pd5 u1F7RjJ/R8+sP/3M+p7T7gNemy8fzljXfPt8Rm5o4PA57SkrJ0R6SD/bhzMD6lbuHr3T5R9V 0FNQNjH3Ip0Tde/26yGM/PKZL7G43vSXQN5W2aN7MJYnGHhNepe0u5fA8+kf6rm3z3tXjrsv +a2x97y3snYm9ZcjgP7qn0+9rDxT5br1GtSu29PSj/l15LNtnFVl8/wmQddz8LtYf7Tn9GXj XBmbH+jIBBwAAABYLbRvMVddsy6ROZqxozna2po8FtvtMbe6w0fzNoxLmAwSPhaC8BFAafyb P96/f98NH5X88fbt27dvi7/giSHY3ihscSNIMReNcM01a7iKShp8fX3vmZU+iCV1/kjXM0/A cxw79uyZZ/YOrvRhFGXs2LP5PxIAAADAY36F8b7deN93xNcfa+wYlDyWPOBaqCvkG12Nho+o OoSPAEojDb625I9yBOnlj3IEqaWQWhZphpKojDOpV97KrvRBLLXs8WfPVfvTPJPauj51bqWP ojhDA6/sG17pgwAAAKhG5hcZ+WuOlznKsaN1qHVI8kj4iCcY4SOAkmnhY0j+6EWQ1hRSziJl c6iYyRPf6ty6vnPr+v7OlT6UZTFycH3viZGVPopAVX54us794uJ5ko4ZAABgmZlfZ+QvO2bm aHZ4tCaPpXV7zBE+oqoQPgIomdn5UY4g77rkCNJMIb0gUraAShs51retfqBrpQ9jGTknv9V3 MrPSR2Ex+kZ9dR5YsM6BbU/cMQMAAKwE86uN961Hyxy12NF6n8eSuz3mCB9RVQgfAZQjPH80 I0hrCikHkSHMX+QAAAAAsCIK+Qojf+XRMkczdqxg8pgjfERVIXwEUKZFiTV/tEaQcgppZpEA AAAA8ETTvu/IX4XM2NE61Lrk5DFH+IiqQvgIoHxB+WNQBGkGkdY4EgAAAACeROaXHe3bUFDs WJHkMUf4iKpC+AigUkIiSC2FNIPI8FASAAAAAJ4IId90tO9E5pemisSOQl0h398IH7E8CB8B VFZI/mhGkIVkkQAAAADwJAr6+mP9rlSp2FGoK+SbG+EjlgfhI4CKC+8CGRlEAgAAAECNCflm VMEOj566Qr623SN8xLJYkfDxCoBV4HKUSwAAAACwOkR+P6rs17G6yGhm2cLHdCLdGPMqk17q fcWzU6VuPpUcbIwNdjglbDrdEks3JqZL3XONu0L4CGCJRf6WJZ0EAAAA8EQr+VvPEn0Lq4uM ZpYjfHSyu2NqGuhkd5cRDkYifKxOVxh2DWBZLAYLGYAAAAAAAE+ukO9BS/r9q66Qb2hLHD5O t8TKigJLQPhYnQgfASy/kF/AAAAAAFCrlu07V13kGotLHD6WEeSVjvCxOhE+AlhBK/2rHwAA AACW3PJ/1aqLXGNxacPH2Y54ZA443eLfCzLdkvIfmEoO7k7O5kdti9Kbmu2IW7bVwsep5KB2 l0lziXpLyrQWPiqPatmifHjWFYIPuDGW3p2c9Q8pMZ1LZSzPxdqyk92tni51yXRLbLDDkTdX 41R3R7azulQIHwEAAAAAAGpJXeQaSxw+RvUEdLK7tQBOCtTEj1JKqLWmDuh2srvdNYsMH0Ug 6K+g9nxU81MRNXrHkMrIAWLE89W2VVvOP1ll29BdR4ePZojpPinztC9Lb03CRwAAAAAAgFpS F7nG0oaPetymM8dHy0vM4c/phJ8SmpFiULMR4WMqo+1F2a/9UbHtbEdce3Zh4aN88Dlvc+XJ qk/H2LWypJDwMejYzJaXBeEjAAAAAABALamLXGNFw0dLVCcHf6GhYdiA7qLCRyMTVI7BjEf9 bdX+g0HPKPihiPDRPDBljwWEj+qxybtbgVmAcoSPAAAAAAAAtaUuco0VHXZtBmRKp7zo8DGk j2FR4aMlXpTCx5hZgx2OLf6LCh+D08CA8FHPB6VGig4ftQa9W23ae48uBcJHAAAAAACAWlIX ucaKTjgTFD7mE7RqCR+Djn+Fwsd8++WGj9JC/VksFcJHAAAAAACAWlIXucYSh4/6HDKqJ2TY dVDfwCdx2LXt2MIC1ooifASAVclJxmOxWCwWiyeX/XbDqC7etZBYlj97hkklYhU6FO9JLesl 7h1/NZxMAACwqtVFrrHU4WP47QXNfM2YcCYwNDSno7E2ksuZ86so01sHTGsjTzhTcHgado9L My1VzkzAhDPqrpUnoseLas5rhI+WfprS811F4aP0FYH/tKMI3p0K1NsvCNr7S3wUeCV9Jtju 5LACsz8tAelrsPaucpJx9Sd/LflrutZA0DvT8g7mfSxLJarkVIhXKv8SO44jXuHqOLYyBF/o laJe4kaUJR9A4N5TCf09aH3TlJuTGe0W0KCTSjmVuxSUq6xYqVSqIlel30YqUcSxiFey1H07 yXj+iTvJeJW8r6rmwwcAACy7usg1lj589L6Hy8nadItIu7S0To3bImapzmcB0o9ugqZnmmoX xXQivTuR2a2146VvqUxjfHC3HweIpFJKB1IZryk175vtiA/uDh4MLp6dfBiN4eGjGpIaWaea ZqYyjfFMSzxotmvjOaoP6YPfl0YVhI/5b23+l4Py/vOPVUa8JZV3riA+Cixdm+U3VypjZJH5 dZbnvgfLwBoEOMm48R6zRyPyhrattDZtyeVqfy9X05f//GviHU8qUYG0qzos3VMRbwX1nEkv qXLha+tKGxjvBXv4WN4z0E9CETGg8f4t8yjKeONX4FDCP6sitis9OE1U57upqPgVAADUjrrI NZYjfMzllC/tsXRjLN2SnDVmPtF7AEWFj9q26ZbkdDr/X3Kv25G7sve1P58FTLco+5LaSUyL H+U4QO2slOlITatjuv2Dn0oOhvUiVA8jvJunuWsjIpQOO56dErlqfh2jl5bc9yqVVV6OwBmB KmzFw0f3+5f8LUH5D7y7Av91RgDvLay8zb3PN/ktrP7xwJI85nKhPbjDuZ8MxU0YVdpWRbDE Ifl3lbHMW2BbQV/Huh/9fVpuDFG9CgxIqqcDlE3ZKU8FE6syLeWRaNmNsiujk54RgqZSKevx maG0k0yUn7ip56Dw2GkJ+8AW23T5h2Jkj5V/dpYWqzV7zBl/WgIAAKtDXeQayxU+whQ2Z07Z lq8/Y+FWPHx0+4ToX+20XiZV+196VAHbNPHSIGvpjxZy72MvnTRzxumWUqJAa9y5RFsVxexL nErE41oi6STj/psssPdxWDoSkP6Itmrv/VtQ2KWc1SpUbiRTZdnjUsUrqYSeGkojevW92o+k gOPT9lI8e6/LAhtdwpey2Kus/EOx98JejuyxehM+4kcAAFahusg1CB9XDuHjcvMHpJnfNayj 0sT/npW74+tfudT7f6nt6m0qj8qtSivmWw47VKwkvxO3nzPm79WgdmyU7/Zg7y9ZCL0L8+7k rNyB2uwWLfXFVvcYupW+ozJuAqv3xUolYomU9k1Z7iFV2p0PgiIDy8hP9S1q7Ei7g1886Vh6 QGuDuuUf/e21jwtjXwE3u7Q3Zv5JJOQ5eK1rw3Njxl9agrqbarcRtI4qVqcJUW9hYezO/EOO 7SWTdmsM37W9Ira17XdAVLq5B01wIjdbzBWonB7Ln6zM3oruj0X/fUtqyhY32WPGyEHhZUeP gf2VpYeUB9WDV26RqJ6QMq4y450S3nHavJqkvZkjovXW/f8OSA3F9f9GRB9C4Kj5wCdlOxK7 gq49+5uwTFXcLxMAACyRusg1CB+XkdLFKXQe8Irsi/DREBFD2P53rn6zVafGVBMJ9SdtiHdA eBGLxWKJhPgi6K+SHyFXRVOCwuele8r9WxPTtru45vs5+oFgcX9syAeCSoKpd6U0B3p767h5 onGLSevcVt7HUblDs9XkI38xK9mD3N24xOkiAvsrqVmm9QZ6Wh6mBnCJVM5JpRy1fW1aCn/u lERCeb8nUl6qY/0rhRqa5CMBr22vMfOkRHfP0od+Oo5jOwQt8/Q/x9R4J5GwZAeO404Tkn8B vROWjHt5TfD0Mnp2Jv8sn1ypFfOmGLbwUjlpboPJZCq/fv7o9P0rR6u+2vqdga3n2tut4xhH Jh23k0x60bv8wV788GRrVzdr+Bi1g8rcFzT495N/oagrq8m3dkKk81nJqyzouJVPCPeiSeVf qqQ+M7v6qaLuo8SOj5brJuAdUXLHxwKuvcBdlo30EQCAVacucg3Cx+XjzE4pnY+WdIpbwkc7 oweN8n9te9eAgK5Mxsq29NHovqT3PNK/O5vJCf+FrzLeIOt8zujeIjb/7s6/r407uhYfPro7 kqe0UifC0iNC7U8aRoxo3crNKI0+kiX+aUQNgRJy3zP/raG9MYr+yhuYryi5nfl1Wj8OPSFR pvIwO1DqXZ6Nnnb2cMtszhZ3GZ8uAY0VfD6MxFf7AIonHXuPyaA9iXWT7nB4NzO1Rnj6j1pv PEsS6h+O9Xow0wx9idm7Lp5MJpQAyZY5WfOoyP5kAQmO5Wf3rMXlT/qCPtSNaMjYyro0PEWq TPTo78j2O0p/ipZrIZ5MJpQzrqbMJV5legZvP2TttdJbi8fN6yz4LRKes4axXa+2t4ulxUKv ofBrL3iX5VvCkfUAAKA61UWuQfiIZVMN4WMuFzYaOiJ8tKQYtnxR+sagZxW28DFoe7o+Viv1 Bo6pjJvlyR0Vlenm/Wmj5PBRulOkvaeh/VaS2jGoWznZ3dKSgsJHby/esbnhY6l/vZC+dvpx njp8VH/PhQyHDckYo3o+RoxTDctozMeieliFLTATNXufy8DnF/lN3vpctAAjHlcHA/uDMbUg LXBHqUQsFo8n5OxC/wAL6hAW3N/M1q3M8rIYzzAgH1ayxng8aT0e+VkW3fdWD2mMTqe2184/ awX3MLNkx+V3fExVeipi849muUJiYfmlsbwbyrnKQp5fVC9FvWu0f7SB20TkrCGC03D1KUd1 +Q0Reu2F7LISKtuREgAAVL+6yDUIH7FsqiV8FPxOG/5/kYsJH5XtFWZ4aO6J8PFJ5vVkbEnl x1zncjk/2otnp5zsbikxDO75aJu+RhbYVzpw6hj9no+R4aPtXpDlhY/+13WpK6H/FVpeGBr9 hH17LSR8tOc1XqvBfeys+y4/fDQtcfioBL5xMQ7Zz2VtfaEi+8yZGVJQpmb7Uc37jA/MnPpg 2AmxnhIjWQlKVdUP7yI/XvXrprBAS+8IGbXPiETTvivr8emPRQRjxi+2Ak6P+5IFXc+Wno3B r2XZV1nhXVYLeZsVtE1wt9fg82l2jQ54R9ielJLuGh8vgV2q5YON/gtPeQgfAQBYbeoi1yB8 xLJZ+fBRG3Dm/+9bHqVp/Ec8Iny0//dae9hsg/DxCeb3DZzuiJsh42BHMhMQ8AVkhWETvChT wUhDsIMHUOcXmuuEho8VnPwq/71TjRndb/HauzC4y00p4aPcWkj4mA9Bg9uvbPgYNaBxicJH b6kjhl3KuauR/0ZnEAUMeC3wx6hcwvLJF32+w2NUI5gsOW3RX0zrnoJfuoJ2bvZPtF5Cwf1d rSe38AHBxTPeeMYFFtB3UV+/cleZwR5g67+T1RNkj5aDuwqX2PEx5B1ha7HAVzL02lvqcJDw EQCA1aYucg3CRyybFQ8fzW4fWt5XTPjoLQ0cFCo/SPhYW7z7JA7utg1h3h0fVPNEP0DUBlAX ED4qLQcHi+ZMOIWFj/otLCsh/yU3qc6pK76NJqUpl/3FgUFiceGjZQSvtV9dIhXwcPC+y+/5 GNEja+nCR3cWHLcVNf519BekwH2Ejz4NXbmQXELtH2emLUVFWOEPFiWi42P+Qzv4Qol+7srL 4752tos1qrur2W6lfpeY14x8WsLHMkf0YS33Kis848+/VIG9KkO2Ce7HGnEIvoLjeFuLBe4l 9NojfAQAAJVVF7kG4SOWzYqHj/YBVNJ3iWLCx9D00djEXWB8SSV8fDL5t3FUMjsv3TPGLHsd DNWMLzR8nLV1q4wOH/XekX7joXNkV3IKLH0cppC/wvU3jBECyKsXEz7qMaZlSLcSHYWkj/YO T6WGj2GDy+3PtNjw0b6CWBqPy3lDPJEocNh7+C601CVslLX+Y2H7NLppWT6WA7uc2WKXwMGo RQkNdJxkIpEIfeWi+qypwXAqEZxfB7QU9K6JCsCLYRm9rUft0slOJEKT59B4sairrIBzKyfQ iWQyNNk092i+vNaOj4WcZPXlCHlH2Fosp+NjAbusiPK6FwMAgCdQXeQahI9YNisdPuoZR2Rv RCeZTFnXy/Pv5qR8HcqPa5QfSSXj3s8pMccn4eOTLWBWFn/ktfGtS7obo5EYWsNHsYv8Q25E qE9i406unczfaNJfJ5Xd7UWNqYxIJC1bSc+lUZ2spsTZrsWxW/OdwLTPFvuHRkQBIyjt/Ry1 L9whfZ9yTirlWFZNJRLJ0BgkcoHRZSqXS6WCewJau3hFpo/2ro+haaz/KRMzXwKjrfABrxHd AfXASf2kS6TU86AlRUpU4zj6MlsHNbV3Z1j/NWmUc0BAHnRG5T07ybjoVhrWGS+sz5r+UqhH orwfAqPEoMwn8gIqQsBf8ZR3mddfM5FSD8kSEgefn6KuMu2ScQL+Jpjv9RxPOuHJpn0b24VW xCGo5zD6HWFvscBOhRHXXtAu828B/aPL+MNp+NVUcBdQAABQK+oi1yB8xLJZ6fAxZ/t2Zx08 Jn3t8wNG+1dz/XF9sJm71G/Y+5Idsh/7ElQTMZLaCBnzCWDABDJyl0nLNDKKKSfboqypBZ22 e0HKs8ckpm0T3VjvIKkvt82vXSS/z5YkvMdO1HtNbsQiqF2l2aCR2t7jiZTRN1m0Lf0pQH4k nnS0Q1L++KDsUnuCiaTjqAvj6u0f5K2NTybrabGkvcq6+s+OeVfOoFNpy1Itn3ZyPz3LMzL/ 0COtpb2yRjc/4+lLJ8rs32oG2XKbymuhx5TBF5Ml29Oeq7orPSYK7i+vX/22s6D+TrEcmcx8 /hX6JeI4qbB9GedAfc5OKhGP2LLUq0x94/jv5KADC3+pCtkm4E8OYYdgfyq54He42WKBnQqj rz3rLo1RGu4BGO+dsPiT7BEAgNWnLnINwkcsmyoIHwGgNhX7fd+6fiV7yNUexpJCVvAo64qq /mBvZc4LAABYWXWRaxA+YtkQPgLAkrF2Nw1b2T5Qu7qDjRXEyYHMcu/LZVDUu3xFVP8RAgCA JVAXucZSh49TyUFpxJ+6PHhkYllSGctsD7npFmN36YQ+OlIdERk8/YKT3a0MSxS3Y6vgdA21 ifARAJaQf6+4SPqt3So7J0nNoTMXVESPdvq9HQAAwCpRF7nGcoSPttuHLWH4KG5epiWeqYxx GLMdcWk1cac2edoHJ7vbPgVtUPhY9l3Sah3hIwAsMXXC5Ig1ZUQGQGGKSPkrqPpzveo/QgAA sFTqItdYnvDRzBmXMnwM7tIoJ5JKgGjLK0Po4WOBZjviAdParg6EjwAAAAAAALWkLnKN5Qgf 45mWuB7tLWn4OJUcVAdBT7fEBlsSg0rwl8p465hhZQTCx5IQPgIAAAAAANSSusg1lqXnYyZt 3IfRDB/dPpLpRm34s3u7RvmGjBHBn5PdLe8ulXGPwU8k0wlvL0V2e8xZwkc9vkxl9OciL1Ge wnRLIXeZrAmEjwAAAAAAALWkLnKNZQof8/GcH65p4aMa3k23KPljPp7zwkSjY6NJuZ/jVFL0 eZxu8RuRVtCSykKEh49qg9KUO2bPR3WJk929ZL1BqwHhIwCiGRAUAAASpklEQVQAAAAAQC2p i1xj2cJHLVJUwkdzFHP4DRkLiAulNHC2I55fWevtmG/fPjt2qPDwUe1iKTHDRzkPrX2EjwAA AAAAALWkLnKNZQwflZhPXm7rySgHjmZCV0Bm501v7WR3u437OxUDsY2jyuXcaa/Dx0FHDLvW em56LPd81DqE1jbCRwAAAAAAgFpSF7nGsoaPUtZmhI/acGN53HR4+CjfM1HuIJlfxx1zncvl /NDQXGiJMqXU0vZQ6D0f/aOSF9onnPHuZVn8DDZPGMJHAAAAAACAWlIXucYyh49er8B0IeGj NES66J6PbnyZTsiJpFiY9QZi+4dkTjhTVvgoL/fWDJ3tWsxIU9S8N08awkcAAAAAAIBaUhe5 xrKHj25yl8gs7bDr/DwzmZa4khJOJQcb44MFRYeVCB9zyo0mQ8PHXMjNImsE4SMAAAAAAEAt qYtcYwXCx/zCwOmhvSXyhDMlhI/5voT/f3t3j5y4sgBgVFvwBm6ieFJFzhV4ASoCBxNM1eDk 1eyApb8AkPpPtLBBBvmcusEztITwPFPlz63uPH227+mm0sd1HpNZh+LjrYmPAAAAAFvSVEd8 S3w8ZbjSWpDTs1Ok+2x8LN9PXd4N5tRDw8dr8TG8gHS362zpycKw07PxN+FCmnx+4iMAAADA ljTVEd8UH4/9Lnr8PB1yly19+On4eNh1hWHFB8fT/hf8d2EHmHGXmOOpwqq4G/68tcU9cOKt tNs/f4ePt/Bdz8yd3AzxEQAAAGBLmuqIe8dHGImPAAAAAFvSVEeIj6xGfAQAAADYkqY6Qnxk NeIjAAAAwJY01RHiI6sRHwEAAAC2pKmOEB9ZjfgIAAAAsCVNdYT4yGrERx7X0L3M6ea3vSew 79vs2xY91vb7u15A8m8Y/Lvt+zb+ar2LAgAA2LimOkJ8ZDXiI49tjFdTqBof0qiWOYa9qNcO 3YoB9/j6yb/Wvm+zS1j1qgAAALarqY4QH1mN+MiDO6fGrJ39jBmQxbd/pTQ+lrrfFwxd7foK 9fM00zF7bMFl1V8PAADgh2uqI8RHViM+8uBm6tsPyY/j3ci3i483To+LYuDxXyscM3RtmxTJ fd8umswqPgIAAFQ01RHiI6sRH3lwc1P/ivVxfoXBk2QNxFPryhNf/sj51G2/D14mPcGF68zu FI9eIxh2PkNpyctP3WkexsehK58kerHs29D2+/A9jidIvp3zFzh08XND99INSUUcurkTL3i9 0uKWX3prAAAAT6ypjhAfWY34yIObi49jMDrnotPA5MvCWpFThXt5een6oFodj406VrZFS9t1 bTeE8Wro27bfx3nywisevwqLWNd18YPTGW4887GcHgszI0/vexj2+749vun4Gxtcz6KZiHF9 HLqpuIave/rf0eDsnu3C64UHRO/xi28NAADgOTXVEeIjqxEfeXAL42M+LOl24Uy36cRxbrwU /bJtbvJ9b5JryFJi8vyUNIvTK2eu4xPymhrJYl7WBAszNuNZjPXriyrgqT1GD0YLPp4HLHy9 uGwG22h/9a0BAAA8p6Y6QnxkNeIjD64aH1+6IZ8GGY0IJyoWb/O9Jj5e6ILxkOopCpeUXcht Zz4WZ/ald0SXJh7GPS6/XXrB9QXn2fdt+C0Y6/FM9UunPs7NfMyP//JbAwAAeE5NdYT4yGrE Rx7copmPxQUg6yPSkTeNj6UlG5fGx2Ry3q3iY7HSzVznrePj1P2m9hicPXyweFmV18vnod7i rQEAADynpjpCfGQ14iMPrrbhTLTc4ifj45K1Fj8fH+da1nfExzw/Zksqlg6+RXw8j4sz4zlJ hjdan9509D1YdJt38i3/+lsDAAB4Tk11hPjIasRHHtxMfJy5xbl+2/WlrZ7vc9v13BqC3xMf p612wnUR59c5vF18PJ2p7/KJl10/rdOYNcPr1pgMF3L88lsDAAB4Tk11hPjIasRHHlwxPi7a mKW813QpRuW3XefTFq+Oj9X6+F3xMd0Y/PIez7eLj+ObKa3XmH7vC5Mj51+vMJky/Ef//FsD AAB4Tk11hPjIasRHHlvh5uV8nuLhkGe6vHTl+XHcFzk55dB13bRcYHwX9fL4GK45GF1Futv1 hfiYXVn/ia2YC7cfx9+dfCXI/TCkqzJOkkJXu7s5ObB8A32+VON4m3jXddHz+esNwYDiNM/P vjUAAIDn1FRHiI+sRnzkcc1v2TKTh6YdsOeGxafMitZ0XDRtMjlvuL32hUfKbyJaejF6NDnD +eKikdd2sbmrOqRZN33xbtjn35TC9+m6Sxy6wvP7vk0fDV4l+LcoRN2X0yqSpW/czPfgurcG AADwjJrqCPGR1YiPAAAAAFvSVEeIj6xGfAQAAADYkqY6QnxkNeIjAAAAwJY01RHiI6sRHwEA AAC2pKmOEB9ZjfgIAAAAsCVNdcQN4mNpl9h0C1AQHwEAAAC2pamOuFN8VCDJiY8AAAAAW9JU R9wwPnZD+kj42FPb9+2G3s23ER8BAAAAtqSpjrhLfBxr3UZmP57fjfj4NeIjAAAAwJY01RF3 io/To0F9HItkseTFd2+3/b4Q/aIHgumIyVTL4IXi+DlzBcUznQ6NDwmOS54QJuvERwAAAIAt aaoj7hYfxzZ3evjitjR54VseH9s2Pjb7+vwipSuIOmJ65Evb7+fiY+Fk8mON+AgAAACwJU11 xN3iY/xwOg8y/rowS/JwOCyMj+NhYw9Mvj4ePXMFUeTMSulpcH7bdXj08cr2G7i9/N7ER7Zn lSUmxg+3Ff7EMfOBDgAAACVNdcQ68TGvd+dH2n4//8vusvh4fjY8ZXgF5UmU52fLlxfHxdnn /YJ+FfGRjQlnQN8rPkaTr+/7gbPiSwEAALARTXXEOrddZxMFo4cKz8bnWBYfs/OEX5fuuf5C fEzvxt7Evjp3Jz6yQdlfPe5hxemIZj4CAABwhaY64u4bzoR3XT9gfLw8LXI+PoZvUX9cSHxk g8RHAAAAfrCmOuJO8THZbmaV264vxsfznjLFPvDJ+Ji8f/WxRnxkg8RHAAAAfrCmOuIe8XG6 JTnbafryhjPBKfaFPWOSfWGuio+lRLjv+yG64Fp8LB1beF1miI88sXT29PkHPvp4CAal8S5Z qqG0iEM3hKMKM8WjZSJKHzrz07GjT8Chi55NLq18/QAAAFDQVEfcMD6m4t+LS6PGEYXffeMN rccj2mkC43Xxsfz79fG56m7W2W/0hXejPVaJjzyr+BPh+FUX/+2i7fsuWmaiUPfiD5xsRYi2 baPPtvzPN13fJ0PybbCOj8zkype2H6KzZycy8xEAAIArNNUR94mPl+9uLv5qm04L6vdZ9wt+ ry9uE3M5PhYutRuOMyyr8TE5suv3Q3y5yuMS4iNPKv2I2J8SYPhc/lGU5snw8PBzI2+Ns3PF 87/YlGeT5xcxfYRFn1Z5KBUfAQAAuEJTHXGD+AjLiI88qeBvI7NL0xb+yhFNlCxN9U4WlMgX xU1PURgxd47aRZQGlV8KAAAAZjXVEeIjqxEfeV7R5Oew4BWXhC3dZV3whfg4c5d17lJ8LMy5 FB8BAAC4RlMdIT6yGvGR5xavvlC+hzp/qFT4IjeNj3PNUHwEAADgHprqCPGR1YiPbEC6xmM1 PlbD4IXNY9IVG2fjY7Vwio8AAADcQ1MdIT6yGvGRZ7Xv26nGxdvP1ONjrT7m8XHJFtRzu9rM 1Mfymo8LXhoAAAAuaKojxEdWIz7ypI7lLtmcOql+F+JjMFtyGjXtmL0gNdbjY3hTeHRcMncy aZPZ/d19G6xQKUACAABQ0VRHiI+sRnzkOe33fbKfS5oNg1iXbP1SCJCFDPmSKdyCPR1Xet3S 2PSe7GJUjJ7thkJMBQAAgDlNdYT4yGrERyhwpzMAAABPq6mOEB9ZjfgIBeIjAAAAT6upjhAf WY34CAXiIwAAAE+rqY4QH1mN+AipuSUiAQAA4Bk01RHiI6sRHwEAAAC2pKmOEB9ZjfgIAAAA sCVNdYT4yGrERwAAAIAtaaoj1oiP+z+/Xnb/jf+1f/7e8cVyH68vu1/9v1VfkxLxEQAAAGBL muqIu8fH4fd/L7vXYBPXv/37uv1RfHwU4iMAAADAljTVEXeOj//e2t1/3cd9Tr6Q+PgoxEcA AACALWmqI+4cHz9eX8RHTsRHAAAAgC1pqiPWmPn48v62nx8SrQgZjfzbv/8XLBYZ3Lv9763d vQ6HXXd86vfu9PjHa+FUp/gYnk2L/BbfEh//BwAAAMB9NNU0c+81H8fkFy77OIlXhNx1QTQc fodLQ/7t34OeeGya8TmPEXOcZTkdfiqSY3CMT8V6/ic+AgAAAGxIU00zK+x2fZ6fmE+BzFeE nL9Fev/n11QbC0tJ7rq5fbTzW7/diP09/ue2awAAAIANaaojVoiPh8MhuiF6TIRRT5yGfSo+ XlhcMj+n+Pg9xEcAAACALWmqI9aKj0fnBHmshNFqj8F/4a3T8VOX4+NMTxQfH4X4CAAAALAl TXXEuvHxcF6u8ffuUJz5ODkuFjklwgUzH8XHByc+AgAAAGxJUx2xenw8VsUpPs5EwCwvuu36 +YmPAAAAAFvSVEesHx+DnWH+vbWLd4mJ9sWe2XDm2DRLpxIfH4H4CAAAALAlTXXEnePjx2u8 w/XxZurpVuvjqo5TRvz31p4C4q4Ldsfe//nVvl/e7fq0gmS4m81pgPj4KMRHAAAAgC1pqiPu Gx+Hj126aUw2OTHeduZX/2cXFsZgg+xdNwbHUnxMT/X+1n/sDgfx8XGIjwAAAABb0lRHrH/b NT+W+AgAAACwJU11hPjIasRHAAAAgC1pqiPER1bz3fFx6F5ibT/07csF3TB/8Evb76uvUB7G w0qXidj96v/tul3yYDLgfHCwUsT5v2l927PS2aKFcZ/YPv5xuvR//f3cT16XfccCpR+wJcel L7tsMAAAAAs01RHiI6v57vh4iJLH2B+mx4Ikse/bKZ6cRySHRG1lzCLTSYSOpxQsHZtujRVu aXV+8Dzm4zVpkeluWsFJoi22yo3yeR3/b7/o//XRT9nhMP0U1Qtk9MO379uFP2anF/AXAQAA gJtpqiPER1bzAPFxKo1paEyTR9AzCsFi37fh8EJ5HEfpHM9mnMAY7o51aotRfDx8vJ4nLf7t 34uHpC3yJd0p62///rmZj+cZlNkWXnc46ipfiY+Hw/jDNH+CPD4e9n136x+zofOHAwAAgCWa 6gjxkdU8VXy8fMhh6Kb8MQ7IO+PQ6RdPZ3l8nJyjXpgR/72145TG8Zx5Z/x4/UwKLF7knY66 zlfj4zk/zlb7Qny8A/ERAABgmaY6QnxkNc8eH2cGjNMezXHchq/Ex5kBxbu2Fzm/brjEZLYw ZXi793kOZnY9F49KX+jq65x8PT6WljUIXIiPwZqQxwHxmgrnp7NJzPHSkfl6lOMB8aKTfuIB AADERx7K08THcFrjIW0RaXAoLhnJE1sUH//27+X1HEv7zExBML7nuiZeRzJaRLJ4kecHT2PO 15wtMZnOfDxf/PGyv3hr9g3i46nxzZwjiY/7vs1/WotPD8OQHhx+OXTZM4VlFE6PJQsvAAAA /FxNdYT4yGoePj7OJ8Z0l93gafFxay7Gx/C/wuqN4YDp8E/Gx/PWN8G92+Nd2+WMeHyhMX1m GXHZpM64RV7rFvHx4tTH6sbzQVFMymRaLuOv9n2brOMavYvkjQ2diY8AAAAH8ZGH8vDxcWbm 42F8NBJvR5OUijRoCpPP41MzH4+CnbLDFR6nm7LDQ9LB2UzD4r7bly7yeMj0yKL4OL7KeG3n +BjclH2Fb575GA4Z8qdKMx/nL6E089HPMgAAQKSpjhAfWc3TxMclx4/NYn7m48we2Dy4z6z5 GIluwf69uzTzcZxQOXOPc3SqdDeb4oHZBMxafCytBXnT+DhT7Q83io9lc2fIDp5bsrW44Yxp zgAAAJmmOkJ8ZDXPGh/TqVXJXMfy1MfgxO7OfC6fio/D75lZje9v+zDwzbTCS00zuuM72z67 eG/48cF8zMX4eN16lLNuMPPxYnu8Jj7mw8oHF/5OML/b9YXd7QEAAH6gpjpCfGQ1zxUfp+Q4 dMXF38YDZuuj+PiUroiPu+5UA//27/lTwXTFKSCW96KpTqicauZcWJzmPJ5nLC6Lj+OZv7DD dXSlX46Pl9vjkvh4XDihdPr5g5N1Jufj45JrBAAA+Dma6oh7x8fCPYA3+RU3vFXwRhN2crvu Zr+QxzvVXu34bfzcXZCP46ni47SbbR5TzrUxDhV5ZxQfn9Ly+Pjxev6p3HW126LHj6z4I+Vi fPz31k6x8vxZWo+P6ezI6eQX98iOrv/zvhof55dhDAckz6d7xQR/Nyj87IZbzAQninpjIT4O 3ZJbxgEAAH6Y/wMbO64kxrNPkQAAAABJRU5ErkJggg== --------------E551C56C7D77B73F699BC083-- --------------EDDF964F9B1C52A2620AFADC-- From nobody Fri Jun 16 04:42:51 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3C9129B57 for ; Fri, 16 Jun 2017 04:42:50 -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, 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 gZXi-XcUXnpu for ; Fri, 16 Jun 2017 04:42:48 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09196129B21 for ; Fri, 16 Jun 2017 04:42:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id A609E154097B; Fri, 16 Jun 2017 13:42:45 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id KsZG2K0EZX-T; Fri, 16 Jun 2017 13:42:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 772B81540BFE; Fri, 16 Jun 2017 13:42:45 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Wr92KhQYmhvc; Fri, 16 Jun 2017 13:42:45 +0200 (CEST) Received: from [192.168.209.116] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 55888154097B; Fri, 16 Jun 2017 13:42:45 +0200 (CEST) To: Robert Wilton , netmod@ietf.org References: <148943391240.20421.7015046968650807465@ietfa.amsl.com> From: Vladimir Vassilev Message-ID: Date: Fri, 16 Jun 2017 13:42:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 11:42:51 -0000 On 06/15/2017 06:18 PM, Robert Wilton wrote: > Hi Vladimir, > > Thanks for raising this. > > > On 15/06/2017 12:59, Vladimir Vassilev wrote: >> Hello, >> >> There is a problem with a mutually exclusive 'when' statements for >> the /interfaces/inteface/encapsulation container in >> ietf-interfaces-common@2017-03-13.yang >> (draft-ietf-netmod-intf-ext-yang-04) and >> ietf-if-l3-vlan@2017-03-13.yang models causing error with our >> validation tools. >> >> As defined in ietf-interfaces-common@2017-03-13.yang: >> >> ... >> >> container encapsulation { >> when >> "derived-from-or-self(../if:type, >> 'ianaift:ethernetCsmacd') or >> derived-from-or-self(../if:type, >> 'ianaift:ieee8023adLag') or >> derived-from-or-self(../if:type, 'ianaift:pos') or >> derived-from-or-self(../if:type, >> 'ianaift:atmSubInterface') or >> derived-from-or-self(../if:type, 'ethSubInterface')" { >> >> ... >> >> and here augmented in ietf-if-l3-vlan@2017-03-13.yang: >> >> augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + >> "if-cmn:encaps-type" { >> when "../if:type = 'ianaift:l2vlan' and >> derived-from-or-self(../if-cmn:forwarding-mode, >> 'if-cmn:network-layer')" { >> >> Short term fix I use is to add "or derived-from-or-self(../if:type, >> 'ianaift:l2vlan')" to the ietf-interfaces-common definition. > I suspect that probably the reverse fix is probably better. > > I.e. add derived-from-or-self(../if:type, 'ethSubInterface' to the > encapsulation when statement replacing the l2vlan, since > ethSubInterface derived from l2vlan anyway. > > Thanks, > Rob The "TODO" text you have placed in ietf-interfaces-common@2017-03-13.yang under the when statement "TODO - Should we introduce an abstract type to make this extensible to new interface types, or vendor specific interface types?" for me is a hint that a better long term solution is under consideration (replacing the list of technology specific references). My understanding is that only the subset of all sub-interfaces based on encapsulation will have encapsulation container. Identity derived from sub-interface -> encapsulation-sub-interface could be the abstract type, right? Examples of practical use of the sub-interface abstraction and /interfaces/interface/encapsulation for the most common cases (e.g. l2vlan bridge configuration) is something that should be presented. If not as part of the draft on the mailing list as proof of concept. IMO ietf-flexible-encapsulation@2017-03-13.yang and ietf-if-l3-vlan@2017-03-13.yang along with the /interfaces/interface/encapsulation container definition can be merged into single module called ietf-sub-intf-vlan.yang where the encapsulation-sub-interface identity and the encapsulation container are defined. Vladimir From nobody Fri Jun 16 05:38:09 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8111294F0; Fri, 16 Jun 2017 05:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_P_Ldpwo4zL; Fri, 16 Jun 2017 05:38: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 8CA9F129BA2; Fri, 16 Jun 2017 05:38:04 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id DB2AE1AE03F5; Fri, 16 Jun 2017 14:38:01 +0200 (CEST) Date: Fri, 16 Jun 2017 14:38:19 +0200 (CEST) Message-Id: <20170616.143819.1546920443725020981.mbj@tail-f.com> To: xufeng.liu.ietf@gmail.com Cc: lhotka@nic.cz, lberger@labn.net, draft-ietf-netmod-schema-mount@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <025301d2e53a$40576960$c1063c20$@gmail.com> References: <20170614.190714.1094691660981968653.mbj@tail-f.com> <025301d2e53a$40576960$c1063c20$@gmail.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: [netmod] Schema-mount question: Augmentation to the Mounted Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 12:38:08 -0000 "Xufeng Liu" wrote: > Hi Martin, > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Wednesday, June 14, 2017 1:07 PM > > To: lhotka@nic.cz > > Cc: lberger@labn.net; xufeng.liu.ietf@gmail.com; draft-ietf-netmod-schema- > > mount@ietf.org; netmod@ietf.org > > Subject: Re: [netmod] Schema-mount question: Augmentation to the Mounted > > Module > > > > Ladislav Lhotka wrote: > > > > > > > On 14 Jun 2017, at 13:43, Lou Berger wrote: > > > > > > > > Hi, > > > > > > > > (speaking as contributor...) > > > > > > > > > > > > On 6/14/2017 7:17 AM, Ladislav Lhotka wrote: > > > >> Hi Xufeng, > > > >> > > > >> please see my answers inline. > > > >> > > > >> Xufeng Liu writes: > > > >> > > > >>> Hi Lada, > > > >>> > > > >>> > > > >>> > > > >>> We have got two questions on how to specify the module entries in > > > >>> a > > > >>> schema: > > > >>> > > > >>> > > > >>> > > > >>> 1. Are augmentations of parent modules inherited when augmented > > > >>> module is listed in schema-mounts schema? > > > >>> > > > >>> For example, ietf-ospf module augments ietf-routing. When we > > > >>> include ietf-routing to the schema entry, is ietf-ospf automatically > > included? > > > >> No, you also have to include "ietf-ospf" in the "module" list > > > >> inside the corresponding "schema" entry, exactly as you do in the > > > >> top level YANG library, otherwise ietf-ospf won't be mounted. > > > > > > > > I agree. The draft should have text that makes this explicit. > > > > > > Why? It should be sufficiently clear that modules that are not listed > > > in "schema" are not present in the mounted schema. An augment is just > > > a special mechanism of contributing schema nodes. > > > > Yes I agree. But let's see if we can clarify the text. Xufeng, what in > the current > > text led you to believe that a module in the parent schema would be > > automatically present in the mounted schema? > > > [Xufeng] Thanks for looking at this. The confusion is because of the lack of > text, I would say. The term "mount" has an analogy to the Unix file system > "mount", where what we only specify the parent directory and child file > system (the connecting relationship at the connection point). Also, similar > is the command for the Unix soft/hard links, where we don't need to check if > there are other links under the child. I see. Note that the analogy doesn't quite work, since there is no requirement that the mounted module is even present in the parent schema. It has been suggested before that the term "mount" is unfortunate... Anyway, I think we can clarify that there is really no relation between the parent schema and mounted modules, maybe like this: The modules that are mounted under a mount point has no relation to the modules in the parent schema; specifically, if a module is mounted it may or may not be present in the parent schema. /martin From nobody Fri Jun 16 06:51:22 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4655E1294E1 for ; Fri, 16 Jun 2017 06:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkAkxI2w-Ylk for ; Fri, 16 Jun 2017 06:51:17 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07F71294C8 for ; Fri, 16 Jun 2017 06:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4441; q=dns/txt; s=iport; t=1497621077; x=1498830677; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=8/wQFi8rkYGu4S/gIbgN+TKh/iU5IxYATzsTbMkJtwA=; b=JYhRvLFy5bwafFU+Jhqgt8TauhQtH4eMASwK0iiMYFh3acR9vHp9z5aX NNQFT9QeQNJaBJ/8JpbvD9t88/eGSGcIlqwzOnu3uWTQQU1KE1S7dDvTs xIAZ0VEhC1PsUU6filJmvYC51rjZPcUH/4mjMfHqtYZHNQshDMy8X7g+z c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AADo4UNZ/xbLJq1TCRsBAQEDAQEBC?= =?us-ascii?q?QEBAZNKc5EIlgeCEYYkAoMnGAECAQEBAQEBAWsohRgBAQEBAgEnETYbCxguVwY?= =?us-ascii?q?BDAgBAReKCQirKzqLRQEBAQEBAQEBAgEBAQEBASKGY4FgK4J4hEOGGgEEnleTW?= =?us-ascii?q?oIIiRKGdIkegyWIQx84gQowIQgbFUmHED+HSCuCEgEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,347,1493683200"; d="scan'208";a="695189739" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2017 13:51:12 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5GDpCTH012221; Fri, 16 Jun 2017 13:51:12 GMT To: Vladimir Vassilev , netmod@ietf.org References: <148943391240.20421.7015046968650807465@ietfa.amsl.com> From: Robert Wilton Message-ID: <038cc4dc-0e54-9ef0-3a64-8e8fa9cf8ca8@cisco.com> Date: Fri, 16 Jun 2017 14:51:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 13:51:19 -0000 On 16/06/2017 12:42, Vladimir Vassilev wrote: > On 06/15/2017 06:18 PM, Robert Wilton wrote: > >> Hi Vladimir, >> >> Thanks for raising this. >> >> >> On 15/06/2017 12:59, Vladimir Vassilev wrote: >>> Hello, >>> >>> There is a problem with a mutually exclusive 'when' statements for >>> the /interfaces/inteface/encapsulation container in >>> ietf-interfaces-common@2017-03-13.yang >>> (draft-ietf-netmod-intf-ext-yang-04) and >>> ietf-if-l3-vlan@2017-03-13.yang models causing error with our >>> validation tools. >>> >>> As defined in ietf-interfaces-common@2017-03-13.yang: >>> >>> ... >>> >>> container encapsulation { >>> when >>> "derived-from-or-self(../if:type, >>> 'ianaift:ethernetCsmacd') or >>> derived-from-or-self(../if:type, >>> 'ianaift:ieee8023adLag') or >>> derived-from-or-self(../if:type, 'ianaift:pos') or >>> derived-from-or-self(../if:type, >>> 'ianaift:atmSubInterface') or >>> derived-from-or-self(../if:type, 'ethSubInterface')" { >>> >>> ... >>> >>> and here augmented in ietf-if-l3-vlan@2017-03-13.yang: >>> >>> augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + >>> "if-cmn:encaps-type" { >>> when "../if:type = 'ianaift:l2vlan' and >>> derived-from-or-self(../if-cmn:forwarding-mode, >>> 'if-cmn:network-layer')" { >>> >>> Short term fix I use is to add "or derived-from-or-self(../if:type, >>> 'ianaift:l2vlan')" to the ietf-interfaces-common definition. >> I suspect that probably the reverse fix is probably better. >> >> I.e. add derived-from-or-self(../if:type, 'ethSubInterface' to the >> encapsulation when statement replacing the l2vlan, since >> ethSubInterface derived from l2vlan anyway. >> >> Thanks, >> Rob > The "TODO" text you have placed in > ietf-interfaces-common@2017-03-13.yang under the when statement "TODO > - Should we introduce an abstract type to make this extensible to new > interface types, or vendor specific interface types?" for me is a hint > that a better long term solution is under consideration (replacing the > list of technology specific references). Yes, my original idea was to define more types like "ethSubInterface" that derive from base iftypes like l2vlan. However, this doesn't actual solve my goal of allowing the models to be more extensible, and instead I think that the solution might almost be the reverse. We could define some property identities like: - sub-interface, - ethernet-like, - point-to-point, - multicast/broadcast, - physical, - virtual We would then update iana-if-type.yang to also derive from these new property identities, which is a backwards compatible change. So, for example, in the other discussion about interface statistics, the broadcast/multicast counters could be conditional as to whether the iftype inherits the multicast/broadcast property. > > > My understanding is that only the subset of all sub-interfaces based > on encapsulation will have encapsulation container. Identity derived > from sub-interface -> encapsulation-sub-interface could be the > abstract type, right? I was thinking that every sub-interface would probably always need an encapsulation, because it necessary to know how to demultiplex packets from the parent interface to the child. > > Examples of practical use of the sub-interface abstraction and > /interfaces/interface/encapsulation for the most common cases (e.g. > l2vlan bridge configuration) is something that should be presented. If > not as part of the draft on the mailing list as proof of concept. I will add examples to the draft, and updated before the next IETF. Others have raised this as well. > > IMO ietf-flexible-encapsulation@2017-03-13.yang and > ietf-if-l3-vlan@2017-03-13.yang along with the > /interfaces/interface/encapsulation container definition can be merged > into single module called ietf-sub-intf-vlan.yang where the > encapsulation-sub-interface identity and the encapsulation container > are defined. I'll think this over. I wanted to enable maximum flexibility as to what devices implement, although of course feature keywords is also an option. Thanks, Rob > > Vladimir > > . > From nobody Fri Jun 16 09:17:58 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C9C1294B7; Fri, 16 Jun 2017 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnVafV6qpps9; Fri, 16 Jun 2017 09:17:54 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 4C23A126B6E; Fri, 16 Jun 2017 09:17:54 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id o83so27751760lff.3; Fri, 16 Jun 2017 09:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=O+4g4o0ybAKzfWJ/eodqbKMbtwnhv9seAdCHc1c9EEM=; b=vdt9O5K9qZ+WBYXvtJc7W3JGitfIj20SdF91Jl34YqDprkmBIHCpYIRrhxhau3q3Em BLG4EwywYvMnIUkNPnEurdr8Xrj/Yvq1uveTQJO2TJUYPm98IztIiD1CkKOqIBm5OCqw kMr+aMwW3EppO8he0XPJTxF26JwjeiDuTpHkBp0JguE1WumaQZ3KQUfGUXZRPcKEh+UD lxzOOUu7+B5FJ46XGM3ksrj3YzTCo4oP+XVw7dz6oYxROZvPS3iCz46nu+fXUeEe3YSl f56d0JJM4xeNA2//wY11CJLUeKcSZXERbkUAngwg9MJiKmcC7deqs2cwzaECWI/6xV9C qDrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=O+4g4o0ybAKzfWJ/eodqbKMbtwnhv9seAdCHc1c9EEM=; b=GkgYMH0we1WiqMJGnJo+O5bx1A1cGxPcRqcfZOCvMEVOiEYOMd4pl5hbMbg7c2kVL6 fn+4Dp3ZGGR7oyssnAZjh1klEG/ADQrKV4rW/bcLUwPuiIsChTznRXEfCeCcxNxZGLFu rzCFwDOoS0wK9dW4MwJCD5sYfLV7OeIpba6wGJASzbkGRt7Fyh2Qs7uKWzLn45RY4rx1 vflJk/97WRYJIbO5RsmJRiGsx/fjh79MRiMEXerEahcG6ZVXtsLuC93DrYOpGknyVUHY g6PV8AslgS0wjOyWJxh0d0YvsHlumV8cbujmr3fxeHLHNA9QoD8xf0w7lMjdxKZXBVKz z8YA== X-Gm-Message-State: AKS2vOwmwsDyTuJ1ZYrdWvEy2ZMjZ5JVlrIQ2/lZ6NeXTqgORjYeRpRP LHlvyB1ZBQ862SgIsyI= X-Received: by 10.46.5.130 with SMTP id 124mr3399033ljf.95.1497629872096; Fri, 16 Jun 2017 09:17:52 -0700 (PDT) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id w2sm516512ljd.52.2017.06.16.09.17.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 09:17:51 -0700 (PDT) From: "Xufeng Liu" To: "'Martin Bjorklund'" Cc: , , , References: <20170614.190714.1094691660981968653.mbj@tail-f.com> <025301d2e53a$40576960$c1063c20$@gmail.com> <20170616.143819.1546920443725020981.mbj@tail-f.com> In-Reply-To: <20170616.143819.1546920443725020981.mbj@tail-f.com> Date: Fri, 16 Jun 2017 12:17:47 -0400 Message-ID: <02a301d2e6bc$19e083b0$4da18b10$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFccaLe8nDjqdS+GVv9FVRFetRQCwM81hkJAfEwPN0CaFHNYqLX4fIA Content-Language: en-us x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTU0ZmQwMzA4LTUyYWYtMTFlNy05YzE1LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFw1NGZkMDMwYS01MmFmLTExZTctOWMxNS0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjM3NjQiIHQ9IjEzMTQyMTAzNDY2OTY4MDI1NSIgaD0iT253T1poWHNIRmV5L3VCOHRDWnA2T1ZCcDlzPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== Archived-At: Subject: Re: [netmod] Schema-mount question: Augmentation to the Mounted Module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 16:17:57 -0000 Hi Martin, That will be good. Thanks, - Xufeng > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Friday, June 16, 2017 8:38 AM > To: xufeng.liu.ietf@gmail.com > Cc: lhotka@nic.cz; lberger@labn.net; draft-ietf-netmod-schema- > mount@ietf.org; netmod@ietf.org > Subject: Re: [netmod] Schema-mount question: Augmentation to the Mounted > Module > > "Xufeng Liu" wrote: > > Hi Martin, > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: Wednesday, June 14, 2017 1:07 PM > > > To: lhotka@nic.cz > > > Cc: lberger@labn.net; xufeng.liu.ietf@gmail.com; > > > draft-ietf-netmod-schema- mount@ietf.org; netmod@ietf.org > > > Subject: Re: [netmod] Schema-mount question: Augmentation to the > > > Mounted Module > > > > > > Ladislav Lhotka wrote: > > > > > > > > > On 14 Jun 2017, at 13:43, Lou Berger wrote: > > > > > > > > > > Hi, > > > > > > > > > > (speaking as contributor...) > > > > > > > > > > > > > > > On 6/14/2017 7:17 AM, Ladislav Lhotka wrote: > > > > >> Hi Xufeng, > > > > >> > > > > >> please see my answers inline. > > > > >> > > > > >> Xufeng Liu writes: > > > > >> > > > > >>> Hi Lada, > > > > >>> > > > > >>> > > > > >>> > > > > >>> We have got two questions on how to specify the module entries > > > > >>> in a > > > > >>> schema: > > > > >>> > > > > >>> > > > > >>> > > > > >>> 1. Are augmentations of parent modules inherited when > > > > >>> augmented module is listed in schema-mounts schema? > > > > >>> > > > > >>> For example, ietf-ospf module augments ietf-routing. When we > > > > >>> include ietf-routing to the schema entry, is ietf-ospf > > > > >>> automatically > > > included? > > > > >> No, you also have to include "ietf-ospf" in the "module" list > > > > >> inside the corresponding "schema" entry, exactly as you do in > > > > >> the top level YANG library, otherwise ietf-ospf won't be mounted. > > > > > > > > > > I agree. The draft should have text that makes this explicit. > > > > > > > > Why? It should be sufficiently clear that modules that are not > > > > listed in "schema" are not present in the mounted schema. An > > > > augment is just a special mechanism of contributing schema nodes. > > > > > > Yes I agree. But let's see if we can clarify the text. Xufeng, > > > what in > > the current > > > text led you to believe that a module in the parent schema would be > > > automatically present in the mounted schema? > > > > > [Xufeng] Thanks for looking at this. The confusion is because of the > > lack of text, I would say. The term "mount" has an analogy to the Unix > > file system "mount", where what we only specify the parent directory > > and child file system (the connecting relationship at the connection > > point). Also, similar is the command for the Unix soft/hard links, > > where we don't need to check if there are other links under the child. > > I see. Note that the analogy doesn't quite work, since there is no requirement > that the mounted module is even present in the parent schema. It has been > suggested before that the term "mount" is unfortunate... Anyway, I think we > can clarify that there is really no relation between the parent schema and > mounted modules, maybe like > this: > > The modules that are mounted under a mount point has no relation to > the modules in the parent schema; specifically, if a module is > mounted it may or may not be present in the parent schema. > > > > /martin From nobody Fri Jun 16 09:40:27 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0D812EA93 for ; Fri, 16 Jun 2017 09:40:25 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 O8Nz_oxysQ7J for ; Fri, 16 Jun 2017 09:40:23 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527CF1295A0 for ; Fri, 16 Jun 2017 09:40:23 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id m7so5060991wmg.0 for ; Fri, 16 Jun 2017 09:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gFwVBhnnd5IDnXWohAzF+4D2nEJkVOik/jrAxNbe5GQ=; b=tqzdZwUiSC8V7B1gNdvOdc4BDsIaqhjgOE8Gts1awY5hvthZrtvb4yNS0G0FdeaSwX rn5qgA6gmD+S7lTot0r4EQZ2nMpr+jn034UVduRgVL5HOhB6jblpNQNjfY1MZt6O41Xu IrdMTi+iN9ZJcv9J9wQNTsJDgKjpL8ZAZhKlCyACH0/LSr92dAyMgIHVzYR6j2PR4oYF 4j0/td9LSTelVfw0XKNmJPaYPK85825ziIukGzZJ1ddStdNsIdtw6+V/v4HvRQh5SWET tzjytvL+lL/xv005p6PaVgQ3LOE9+Xa05ZOPGbw9fneqiwUCjlfL019RH14tEWmRCZRr bXzA== 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; bh=gFwVBhnnd5IDnXWohAzF+4D2nEJkVOik/jrAxNbe5GQ=; b=DEg60SXzXM3Zi7+4zfy7YinnytBVQfnYeuGh5bxzHJsUvIPNuZy9xFnrg9LTrU6FEl WlEDYHBKSmxz5h/N1wQUTUZhJwHf7reBBGJLTbtM0sYphzNe6mKRK/jxoamyeDoDfq1a upZ8Mhr7jTUuy1IoktNHJ+vnrtuhHemh//Rf8R5VzZm+3B7cznmCqAAmhdr3csK18ZRa nErl+d7Y4hpuH8pzfd7hSHxVbEXmuTnKo49+S6VwBiGLt90/387IanYxKWpsnfVfLaEP SnpcQeEdOBfW9SDpqedsovZk7NzQ+4UtIxjUnhN68jOlhB3Ny8Nfv4nAw4X4zXRA7sf/ l6nQ== X-Gm-Message-State: AKS2vOzJg7GTuSFvPGB94kOvJnl5ToMPaTAfvl5+NOBzKby+Cbl4Eu0d lP9A6Oo0veZgKoVhTpbvcThtnoFNIOuI X-Received: by 10.28.30.3 with SMTP id e3mr5718643wme.60.1497631221724; Fri, 16 Jun 2017 09:40:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Fri, 16 Jun 2017 09:40:21 -0700 (PDT) In-Reply-To: <20170615.215904.29472750939400252.mbj@tail-f.com> References: <20170615.210324.866114685910056800.mbj@tail-f.com> <20170615.215904.29472750939400252.mbj@tail-f.com> From: Andy Bierman Date: Fri, 16 Jun 2017 09:40:21 -0700 Message-ID: To: Martin Bjorklund Cc: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114b3508f9efbd0552167003" Archived-At: Subject: Re: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 16:40:26 -0000 --001a114b3508f9efbd0552167003 Content-Type: text/plain; charset="UTF-8" > > ,,,, > > > > > Sec 5.1 of the RD draft does not mention config=true nodes. > > The operational state datastore's schema is all config true and all > config false nodes. > > This actually changes the behavior of YANG XPath. container foo { leaf A { type int8; } leaf B { when "../A > 3"; type int8; config false; } } It has always been OK for a config=false data node's XPath expression to point at a config=true data node. But this has always meant the configured value. RD changes this behavior because the new opstate datastore contains only the operational values of config=true nodes. Now there is no way for such an XPath expression to test the configured value. > > > > augment /foo { > > > > when "blah"; > > > > } > > > > The XPatch context node for this when-stmt is /foo, which is a > config=true > > node. > > Sec 5.1 says > > > > o If the XPath expression is defined in a substatement to a data > > > > node that represents system state, the accessible tree is all > > operational state in the server. The root node has all top-level > > data nodes in all modules as children. > > > > > > The augment is a top-level statement in this example, so this text > > does not apply > > Ok, so is your point that this text needs to mention augment as well? > This text was copied (and modified) from 6.4.1 of RFC 7950, and that > text doesn't mention augment either... > The text is misleading -- it should really be the config-stmt value of the effective context node that matters. A top-level augment has no config-stmt value. > > /martin > Andy --001a114b3508f9efbd0552167003 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
,,,,
> >
> Sec 5.1 of the RD draft does not mention config=3Dtrue nodes.

The operational state datastore's schema is all config true and all
config false nodes.


This actually changes the behavior of = YANG XPath.

=C2=A0 container foo {
=C2= =A0 =C2=A0 =C2=A0 leaf A { type int8; }
=C2=A0 =C2=A0 =C2=A0 leaf= B {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 when "../A > 3";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type int8;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 config false;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 = =C2=A0}


It has always been OK for a= config=3Dfalse data node's XPath expression to point at a config=3Dtru= e data node.
But this has always meant the configured value. RD c= hanges this behavior because the new opstate datastore
contains o= nly the operational values of config=3Dtrue nodes. Now there is no way for = such an XPath expression
to test the configured value.
=
=C2=A0
>
>=C2=A0 =C2=A0 augment /foo {
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 when "blah";
>
>=C2=A0 =C2=A0 }
>
> The XPatch context node for this when-stmt is /foo, which is a config= =3Dtrue
> node.
> Sec 5.1 says
>
>=C2=A0 =C2=A0o If the XPath expression is defined in a substatement to = a data
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0node that represents system state, the acces= sible tree is all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0operational state in the server.=C2=A0 The r= oot node has all top-level
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data nodes in all modules as children.
>
>
> The augment is a top-level statement in this example, so this text
> does not apply

Ok, so is your point that this text needs to mention augment as well?
This text was copied (and modified) from 6.4.1 of RFC 7950, and that
text doesn't mention augment either...

<= div>
The text is misleading -- it should really be the config= -stmt value of the effective context node
that matters. A top-lev= el augment has no config-stmt value.




/martin

Andy<= /div>

--001a114b3508f9efbd0552167003-- From nobody Fri Jun 16 09:46:24 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 940811295A0; Fri, 16 Jun 2017 09:46:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149763158256.642.17505138061358076832@ietfa.amsl.com> Date: Fri, 16 Jun 2017 09:46:22 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 16:46:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : Network Access Control List (ACL) YANG Data Model Authors : Dean Bogdanovic Mahesh Jethanandani Lisa Huang Sonal Agarwal Dana Filename : draft-ietf-netmod-acl-model-11.txt Pages : 44 Date : 2017-06-16 Abstract: This document describes a data model of Access Control List (ACL) basic building blocks. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please note that no other RFC Editor instructions are specified anywhere else in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements o "XXXX" --> the assigned RFC value for this draft. o Revision date in model (Oct 12, 2016) needs to get updated with the date the draft gets approved. The date also needs to get reflected on the line with . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-11 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-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 Fri Jun 16 09:51:33 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D01D1295A0 for ; Fri, 16 Jun 2017 09:51:31 -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, RP_MATCHES_RCVD=-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 gByGylqki39E for ; Fri, 16 Jun 2017 09:51:29 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0241200ED for ; Fri, 16 Jun 2017 09:51:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 26405360; Fri, 16 Jun 2017 18:51:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id oHbqzv7DgqKu; Fri, 16 Jun 2017 18:51:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 16 Jun 2017 18:51:28 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 002EE20091; Fri, 16 Jun 2017 18:51:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tV0f6t6tI2Aj; Fri, 16 Jun 2017 18:51:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85B0D20090; Fri, 16 Jun 2017 18:51:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 589DC3FC503C; Fri, 16 Jun 2017 18:51:27 +0200 (CEST) Date: Fri, 16 Jun 2017 18:51:27 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Martin Bjorklund , "netmod@ietf.org" Message-ID: <20170616165127.GA60526@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20170615.210324.866114685910056800.mbj@tail-f.com> <20170615.215904.29472750939400252.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 16:51:32 -0000 On Fri, Jun 16, 2017 at 09:40:21AM -0700, Andy Bierman wrote: > > > > ,,,, > > > > > > > Sec 5.1 of the RD draft does not mention config=true nodes. > > > > The operational state datastore's schema is all config true and all > > config false nodes. > > > > > This actually changes the behavior of YANG XPath. > > container foo { > leaf A { type int8; } > leaf B { > when "../A > 3"; > type int8; > config false; > } > } > > > It has always been OK for a config=false data node's XPath expression to > point at a config=true data node. > But this has always meant the configured value. RD changes this behavior > because the new opstate datastore > contains only the operational values of config=true nodes. Now there is no > way for such an XPath expression > to test the configured value. > Having something in the operational state dependent on a configured value that has not yet been applied is broken. If you set A in to 5 but the operationally used value of A is still 2, then we believe B should not be there. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jun 16 10:17:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992B51294E2 for ; Fri, 16 Jun 2017 10:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 8aiWFJRj-VF3 for ; Fri, 16 Jun 2017 10:17:54 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0102.outbound.protection.outlook.com [104.47.32.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624C9126D05 for ; Fri, 16 Jun 2017 10:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oJbs7aEj2SeOf+WZh0sjqvhyAZUOzExyY68t5twsjlA=; b=I/NfFgWUuK/4nAwDrsp9dTJpLfIo/YoaDiNd/LQMRQ0sVrbwFgq1P47DSBLQEhF2YM0Lqx6MMcDOx1DowAROP8q1e9czLnSC9KabHPvDwmKh8MD+0ipuVgT1lOyoR1qXkne8ktNY5QNKQXwdVJguIIsTV0vjSy4GA2MktVOoRh4= Received: from CY1PR05CA0003.namprd05.prod.outlook.com (10.166.186.141) by SN1PR05MB2239.namprd05.prod.outlook.com (10.169.124.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Fri, 16 Jun 2017 17:17:52 +0000 Received: from CO1NAM05FT062.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::201) by CY1PR05CA0003.outlook.office365.com (2a01:111:e400:c5a4::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6 via Frontend Transport; Fri, 16 Jun 2017 17:17:52 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT062.mail.protection.outlook.com (10.152.96.180) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1157.20 via Frontend Transport; Fri, 16 Jun 2017 17:17:52 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 16 Jun 2017 10:17:50 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v5GHHoDa024701; Fri, 16 Jun 2017 10:17:50 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.15.2/8.15.2) with ESMTP id v5GHIGAH068175; Fri, 16 Jun 2017 13:18:16 -0400 (EDT) (envelope-from phil@juniper.net) Message-ID: <201706161718.v5GHIGAH068175@idle.juniper.net> From: Phil Shafer To: Andy Bierman CC: Martin Bjorklund , "netmod@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <68173.1497633495.1@idle.juniper.net> Date: Fri, 16 Jun 2017 13:18:15 -0400 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39410400002)(39860400002)(39450400003)(39840400002)(2980300002)(199003)(189002)(9170700003)(8276002)(356003)(2906002)(1076002)(23726003)(81166006)(478600001)(8676002)(8936002)(47776003)(189998001)(54906002)(38730400002)(4326008)(54356999)(53416004)(229853002)(77096006)(110136004)(53936002)(50986999)(86362001)(46406003)(6246003)(7696004)(305945005)(2810700001)(106466001)(97756001)(50466002)(2950100002)(76506005)(105596002)(5660300001)(6916009)(7126002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2239; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT062; 1:Jx5nxZyEv7TKvP/w/NQbiFFl3tsOI8v8+msW5SMFGgXAxEWLEvJzIBJl8VaI5iQL1aSMMrAKHzbeCPa14EKpEbFc506KrVnVgY+Qb9oCSrM4ND5fvnsiAFevH47uuJ/QOSQccjs3Cbr0KLTR7/CCRjJOtXraoZC+lIjbaRiZX26UShdaL1r9X0x7YPaPAiyZLhKNcWEThJXYSMURGiqa/hb9UqYtu707Ub7pGnzM9fg/pL7fTxW2rt6l+HK3Mz67MExsrEJzRbsV+G61+rsyJJr1rf9HHIY1Yicwq7I57Illw1/BP7Ilm/4eRM7GlKlC+eOVLHIB5RysUvXBHTsjiEaVKgtVZwCXqiPDbpNaO5PiRX/bP2XnE/uXjkmY7bsxQnTnpJbkHt034aGbqq4OKlyki2N4yLVo9VL4kJ6bI4vky2tpYu45Manj8B2Lnru/HWOgWu4jY3TNNMbN8Vb6oSf+oWsWYTRb4WmrV2CCAJvPdPcjan7EMFnFL3Uz+uCV6jE8TrtqHLXmm8FZ4kjNbsu0yTCgu13uPLod6kX7lecm31+Drxsrtcl751jyC6WS X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 57982163-29e3-42cc-f604-08d4b4db9efc X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN1PR05MB2239; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2239; 3:Taht3smrF9WgGnrGc+Eoize4pgu5USKWTXuIDVSCh2orLk3zEHJrb3DZZa1BmGvuNfoR4vlsGaydT0MkvXTVDxibeFUqpi36pQ9p7aYYTUAoMJEU2ZhzoZNh9igU5dLGe6UWBKlUYjIAosDQGqBwD/nbptqRWXxKEw5JUvneExcl/xsa/Qe7OvvxpTUTs2w2tdQkvoQEDHctsYvzdoxabaZ56mqaj2Sv4NG0osRbXlXfGY+g42vzlS0FNEhEMLfwo0rbbIT9E4X5LjLSql2oWpau26d1gysrASHNILL+XnLj346CRjS8ZZhFhORoMdR+mcL2X0qfcvB3J2jXvYxJaKcyPFEYCh299dnFRl7yiQpIvPsY3riSaNkBOxofBdkaDSKv23Gn6A++0is5QbZlW2Zw+pdOcqNBUyzIsfb6B0M3EmjvU/cI7qxDqpxDD+H8SBXNDUIIvXlNc3HDYj9LIA== X-MS-TrafficTypeDiagnostic: SN1PR05MB2239: X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2239; 25:jwlsYQ/e53W3MMbG2l/ixDqHPmY1x53hUcuL9Sg1j+3ygy7GxISzzkSeZJCZSX34SNwESuE3hJ5iMnXZxCjjTmxd/X20bMDmbTASEjlwM+4uqUZF/JiUJGhup15tRunLaESHLdKQtFaZzLZ4p2owig+iPpFN0CN0z1dGzJ7FK1l98lhgjl7nF3pCziLeZ0PkA87skX0FOFkYG68nichKUVjqIKX9c9Mu7kioAmNRIW5uag/uJa1q8YW3fa8XaaI7mDQwkuf5NDhIzV8+j19fpapwQIzhL6pGZqqP+hP2AM0YELEsQa+1Am6MVjNCNmUMcGsPSg+wrayjIeAHrxuH4cxKEYVHyZVQwHeye+yCPQKc8Df/jfCajBi9Ag47ZDonKny2zsz5gxqkN3YQlHXREbNKuZi2vHyYGGb8qUPXfiBILg/00WEajOtMsA2qo250LgPXdDHX1BZcxTYPkrYgyUGYbV+ujUXP/gjKXvPFPt8=; 31:NvMBUk8LaHIdS3pcJV4zz1ICvvU3khoq19kH8gbZA/ZGiQXzzrx0f3D4uoIuvFh9o0QtoeSTYqdhW9PXQdLhChkR4mJMXP58z97SSkhnmkwckDoxgZsCjtRFtoDCNNJF/bw+uEgHd/T3awCmnxl/q2d6e8k4R70UK4schlPBowMVrEHtEkyGrM7KGHsuLSFHdOmpba08Remyb0RB8hXbKRfdZWixpm9MQTmj/rFPJW9VnD6dOG5k1uYQlEDIzd39 X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2239; 20:BirJ+AwDZOX/LChORR7g6pERAdoq/SeXbhc2RsCnY/z7Z4LL66ouLu4SFB3OlUIvXVpyCOobpkqhDIn36Aivv8a+GgIPc7kuJ+50ZB1IX8u5NrcgSCvXPs74wstIVz22yRKz4o6wQRydEYdke98Zw6vjlUQwRa3thf9qjwKsssGdrHZgyD/WSB3EgJbluOnt1cXc73TvBQK4SwxPFp33EI7POzgysqFAxgnrDfQoRtRNXBAHjkhPXPLQiQH914d9PMsrYviWqRXizgSoO/A77mACITJAHfDPyGdkPF6ZjWjsMkA1zO7OSRra5MwglkVVoIF6z0whEjTR45l2ONAsNqNzsCFgvsse6VCZWaya8nzu6TCVwsEk88zD3mh+aBqIp3hyQ6Ok82i1Hb7Y+4ubnZvzuxsTNs3GO3D88b28KudtJHa+ddn3PDQ9GXBe/rpEVphogbAWIWeK6cOKCRsu9b4RzLgGiQbmbRv0UFQAacOJ9kKOpcxZ0V2uUMALp5N3 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(13016025)(8121501046)(13018025)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93003095)(6055026)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR05MB2239; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR05MB2239; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB2239; 4:jCvKa0pxEZo7WiEEovmAXXYXuTScqRsYZxG4SsoY6I?= =?us-ascii?Q?Y9gEwqHkDPKI7Wyezj2BuSag9HoP4ZQ53gW/HK450dNC8UzIWPdlm3Tdqhth?= =?us-ascii?Q?JEbGE8ugDkpsWUpE4l49Nl7Ju9Qq1QyMx/jgUvtaLf5IoYz0CxxRzkKmhb4A?= =?us-ascii?Q?rTqekExcCx5+0a/tNb57bEmzVrfAi8hG8QzGuIeIw5unnZ4dWWMzc7aRjI1l?= =?us-ascii?Q?v0wRIjMtD29Ch4YcoeyZEaoJmF7TI5Gwq/SILLbktXeBC1qAmPlSPK5LIkxf?= =?us-ascii?Q?3cXPEh5GmSIZemaIdgnpoPSmMEI1NXEgxO0MxhJWefElHtL2aS2qS1booJq9?= =?us-ascii?Q?WJcGcRUzV3i2AXSwb97ZCPPkWGCc39+nv6hKiX2JDazpLR7AZ4hXfklHTwB6?= =?us-ascii?Q?IJDqWOhIt45ifPikhCsgQhIJASN5oRa5HXcDkvW6g000gtMj9D4o06kd7BNv?= =?us-ascii?Q?Hdwsq863x6ArcXE2XOnW8sGMim2fqTPvWGyfsk8Bl2sqN6E+bac/rZSZ5wja?= =?us-ascii?Q?MbcRa3+H5Uh0iZfQgyNuPN6REeWknVqTSGnWjX9gCwncMVufPO8X+8o64pFb?= =?us-ascii?Q?ImCJX5dfuV6+b0rTY+glAI3rrJXv9LfIYz+0D4Wve/ZQtX2V8mXfdu696zE6?= =?us-ascii?Q?2tXDdvQ7WA3GxKMaepm1goIoCXObM7w+rJ9VN4M3GbubJ/nRYiMkqnHrWE6/?= =?us-ascii?Q?9sxnhwUv9QwAOaUVUOXFkBQVkuYY0OtTcJiUUaW11/ZPJlu9u1F5QuGrE17x?= =?us-ascii?Q?6Qhve0tKnVyiUNsYBEQ9aQcGCaQcIjvRbD2Ug5k7y60igdbzemaIJhn82jNG?= =?us-ascii?Q?RCr/STIzJ+Vp6F5Fj4LzR0D+6wp7nv4axfXXTWUnPfy/XdAx4CPfo1ZjSjTb?= =?us-ascii?Q?jGHl3fc9tQ64tx09bJvIUfMI9bSq+TkR4hh69W+QSS7e0SXDXJrNfP1NijZQ?= =?us-ascii?Q?VRvbBh0SF31HNPipzmBK2auh0sz62kIPt3LM2fX3opf561mT23MkEbumCQRu?= =?us-ascii?Q?kHFvNdQFL5tuO2Oed0TTD4b5QDhiYgbccB6Dl5tBwaMe/KZk5cidIoRnE8e8?= =?us-ascii?Q?GgwevExaIOW/1q9oa6efqxNEB8EB0mflINj3L41ig6oyl8ccYq8ORANbnWmJ?= =?us-ascii?Q?I/XBt4S+QXUvaxonGCVhfjOX9KlnZ/lZbUaXL0X2oJ6SUKACtbhPCVVMGqUZ?= =?us-ascii?Q?4TZnK59HlVkJ68ZQ8vP5WYmdN249QglkJZ?= X-Forefront-PRVS: 0340850FCD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB2239; 23:Z9Nbkln7mYo0gXausr47M2EtQJiZBrusgpphN0g82?= =?us-ascii?Q?DAmpIsrJ7oiKao98K+esintvrveg0lXG6IMXFlwd36c4WAcGPjQV4ImqYVnX?= =?us-ascii?Q?gbkQc4E8twVW5mzA388Ib1pjoCG8HqsPyUUbS3PbwY2TAbEfYKa8PdrHxipz?= =?us-ascii?Q?uxT1FkhEICCf7E6KkxZOUw7J+QuEXeS4wcKCv8pb+G165XqJFv71eMIlF/5a?= =?us-ascii?Q?9OZjXZUDf4m3JGGvVJyeWxYYhBB1G9CsYdFxFgJsPntKXJYFUbeVTGT/Kjbv?= =?us-ascii?Q?Ek3xalfmU7VoyF6K8rSVohRu8kwX6Zj3YU4dtPho8zuijOd0b4Jq+L3kgXoP?= =?us-ascii?Q?BB0huIsjhqyjNCzd2Kyy3RSqi0/M7JMBpigKE/YraHFbJFJeRbz68SMCitsK?= =?us-ascii?Q?ESeuMCZc0omD/Z4lG9VmziQkaiBpbkktiBkuWQwWofjHbgZzAVlyjAVuS+bL?= =?us-ascii?Q?/Bt2mKpWp0a9DuWRkaCb4Kl88Jfjygc4yw5gnSjUa8qCikqkFT0E1cMrPcr4?= =?us-ascii?Q?JuwKkPO2kKrSLaCidqgFIcYTAAvpMZBYYxxNZQv5LAOvXEt5CnTJqpVu0bpN?= =?us-ascii?Q?z4yqD4+mpwkh/iisQKc2rVsKj5JOoW2vInRB0wlIhsaikg9DyZH4MCBilQPg?= =?us-ascii?Q?4dty63yfekH9fY6Cc6Oypf0ZHUhZDIyppxmjR9FfKOt84iaw07mRDvLTwrmw?= =?us-ascii?Q?d3iuSf3umsRzBsSaKHg3/40pKqIEZF+tYjJEQc3AC0a8V7oIcr9z0Z152Ih9?= =?us-ascii?Q?exaUj60/pamQ/71WkirvdCHGad6eoP47nlUuCYwV0wuG5HqpEIDG5JqtpJK3?= =?us-ascii?Q?eOhl1r2s24jyqaAXqt0VPCRTG2KjVC9K0kUEZXL5JdjlRsfBJxWWR9vefLZy?= =?us-ascii?Q?mZFj5BRRcf6DmK3XaTLdlxRZZhAJjc7fnigJPUimshkdh3qMeu99k4DrxPRJ?= =?us-ascii?Q?19zd0PUU92co6dBCEWiW3S1SBgl5/QD5FTbiq/wNkHw/pt4UBvJ8wYzocaoA?= =?us-ascii?Q?D5G1Ty06P/RaOfVZC6T/NHUM6KLWZFB8ST02wLqIBdkAJukQKEln2RTOdQK6?= =?us-ascii?Q?7Cow/cdCOfaC7gTC4JDdDkYa/zkhOUyKJfut7z7qk9HSVS//zhzkRB4cSQK6?= =?us-ascii?Q?FUucasoHdvqEpjA5OGoLCFbWWPpeuCSXOkSMDn0WJB3/F1UqaTM/Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB2239; 6:FsigJ+8xZwuUxjDdYququFH+JMvly9qLNgPXAYPB5f?= =?us-ascii?Q?m9ZkXO681UuGTK44nUj6Dp0CSSO3wgbSa+V8hA+qjhGAzPY6u9BRyIW9WuFx?= =?us-ascii?Q?gLx5xJF87YSoNfUKONaOkOrDCB0ui+z29DG7Uf368ePKwgIuv5RJPYlKhhbh?= =?us-ascii?Q?w+SbK2k2UF5JZQ3SSFwb1eZNug0UyFnYYCh7ZdPiD+7TAmMod+CKUajPaSWh?= =?us-ascii?Q?+4BvdVLqIRnyPQfv+7ZIR4AwTS6fr5psomZT+rVDbyOObvYWECOk6cXHNnwK?= =?us-ascii?Q?t8JxeFtvxaZzTVfIaZ5LrZxOXw35ek+mh4tkI2Qq0AjTlOvIHw2sYpK368po?= =?us-ascii?Q?KiEAUYchR4Ub9gE1tohgHtBPysogZeoHi6hsCbcJTSxD7yNatW4eIpLiVLbW?= =?us-ascii?Q?s/jqw5afAYkzFvI8VERuJSkCv3uUetmMx/MPX1Cz73ylL/krrZVWsh9wImvS?= =?us-ascii?Q?kRQnkQTTSBoOlna4l1hBJflDZiDGn8mGzZRDEoeQFN2KC3vkHJzopGFuB1eP?= =?us-ascii?Q?OYiXlV+IttNC8E7hXmAg07fFNyRrODUCpu/DV6c7YzODQxTyTSs+WRaayChi?= =?us-ascii?Q?1cEfL83LWyfw7HhTKZ8CTRV8xWbQKzZFy4L9BnBURTtlsF74CFU7fHINr2D5?= =?us-ascii?Q?Y5Opk/p9xLNMkGdR/ZpAbnzet41R7tQR7NMMbv/RBSfT23t9QxCuhhdZfsak?= =?us-ascii?Q?0xUK6IaglVYvIzpfn5++ujpbkz7Fb9sQOr4Q1RV1KD5Vng8FieWyC6M/S6Xx?= =?us-ascii?Q?WYaaYdeFpSjz7rVraW6LuJ6VEtJclpA6Y5oY8yOEPs0d2feZE9zQU/QwDYhz?= =?us-ascii?Q?Wz+WqhlQ2szFOf0/fT5oq8TUQfRHM36cgRyGlUZt4i5uP9sHAjs9dML0zC1B?= =?us-ascii?Q?kF1202Q5tGFcsvFMqDnoqiEiPHL4w/NBUDNxHe5FkCKGHsGotgNlvjAMdlAX?= =?us-ascii?Q?Nb43sIWvL3jChdSrjLZ+A1ZbWtaZIlSLdym7TPpm1xnXxAOAHdN8Ax09hEMu?= =?us-ascii?Q?2AXXh85WmQKCBRtySVxShX?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2239; 5:IvyOtgYt3NuWelUYVpSKSuNqrHc0zlNDwMq+o1vS8NaBDcklvjtsWXzr3w9uhASWh2LuJ+JHEal+9M985He7KZ6m9kFuy4SCgaHfkxB7lEjM3re7wcnXr8bk+YLlfC2G8L4mJnpR9F+W1INKccvWM4wgcTkL8OxjdSt8CzxtIQ7sp+W4yZKjFXbbRf698Ue+6jQEg5jZibkCTsL66PIM50krTASp2l1KrEDa1Qu0JH3kWrjTE13ec7n8YgE4MpYtoAC9AaIb/4Z9K3Nq3LuIfXjWVxqmiQxkgTWZs0Hguqfz31gcChjzIYNuW5yFHwtnWNj3W/D3UnBsirevh9hBhYyq3T4cEbvmRawqEpDkkjvhIJBrptPGtMsclIHO45aH//sMYkVwIbT+3awG5bQXVLrjMgf1QqIF5Q/yuU/TlaEHuZ1XweBQuKmKLUCDEdWQt8OxX1Jo110XcuKO+fzxDQkn60TyYfRnyfRuUwqOvk+rmLA1y38ot7mDDflTY4hX; 24:G2DBgGtNlBv7nshwEoxY5i8cj+zibSm3T1hoX0/Q3RSZa4lcSySe3uTHAFk1oESslRl8CbwtRwQykGBnqReOkvKpBqk4PRYifAbnT4UbzYY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2239; 7:g4Or3EtBxW0CtzrEtU7A20wqtowtNqU2sfWucZAViMzjIgGcmq/bD4iKWtqRz46PzqTqwsvO9tK1ZhnENtIMXcr/52yJZlfxL14c+MkYreezPLZZQ0pyXuZ497jVNs+FssZlLpNsbyruaFGuAWK+s8nJThx4caVD2uCwxbSSNnI1JWafggM39Vt1/QbwGeLHaoOvgpZQ/98zsNtC6dOt8P/mIQD+Xz535RMkvZfmwc4Z6b50iyTizv2r+Ff/ZdTnT6uRPxp6piEn6x4puZgxauFuD6rEwLwoojz31VWFz3EgExSNapB1AbWyBzu6WATtIXQ3ToOF2qfvJtKgErhn2CKbLnGJOOktF44qE8HQNCoMdHp8yw0pXFvaRCZqMUCrhsLMWExregY/YdkJj7APe4RZdxWBvQcerxuFI34R2z7HQgS7aY34gcw0C7g0sZhSNQ3MEdLxCnS1Bh/ahJPkFhGMwPDH94s9+P2956oKl1QXjDc8fvHVViS7R1uJSBRbl5/swOeRzoLk/JJkCzedXGoTbPLEvM1rhIHDX9rb62qvTKwQ8YSSBq+tKjGhiYODY9WyUHqf7Gu5YwH6yd7q+eQ3a1WD2CSQ7Z+9F2qAqnW5oBwrS3J0pxEM/ah1X08ltRTIU2tsTVHp0XKs5SEw68+ih1ghysY12AccPCsebaldBGnxSQba2NH0WwHA20BERLtCy4jEkR7WxrBNgPq0aKjVV6lgxzdX3+NrHuG8IAfpQgvy9rAms9K8LXfJIpzMi0LohEbLusxf72TeVAffFtSvjJSSSQCNogrXtdCT1iQ= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2017 17:17:52.1485 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2239 Archived-At: Subject: Re: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 17:17:57 -0000 Andy Bierman writes: >It has always been OK for a config=false data node's XPath expression to >point at a config=true data node. >But this has always meant the configured value. RD changes this behavior >because the new opstate datastore >contains only the operational values of config=true nodes. Now there is no >way for such an XPath expression >to test the configured value. The XPath will refer to the current operational value, which is better defined and more consistent behavior. During the lack when data is flowing between and as system components read and follow new incoming configuration data, the operational value should be guiding the constraints, not the unrealized incoming value. The XPath continues to work in a backwards compatible manner, but the outcome is more crisply defined and the datastore will have better odds of being self-consistent. Thanks, Phil From nobody Fri Jun 16 10:24:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB473129503 for ; Fri, 16 Jun 2017 10:24:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 zks_922QMnkq for ; Fri, 16 Jun 2017 10:24:21 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F8D129463 for ; Fri, 16 Jun 2017 10:24:20 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id e142so22646010ywa.1 for ; Fri, 16 Jun 2017 10:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t+fuhMqkSSs3U3rJI/BIoK9PdHL3F72f87ztmcUFMiE=; b=UvUFJO+5W6Xv/gDevmDxt+5/hMDeEFyYkSj+paIyqjHdeTOI6/GoNJYiouMrNP7kvb 9bR4C46ehoRCilTUJbrnTYuFv9dxZKfTqgESmcOPl8y+iW3FkcbvP9OCXCymggDMX7AI QIRIGu1ZNFNZ7zqu50XT+DTM7GMgqg+yK3gQaK2axJU8+xmgaS/TvKFTzENyisLEbMjJ mIoGMK8AWyqJWcL5m0e9FkfKXjSkln6LeQYumPkVWRWzdwm67spXhLftVtZu5i+qPspy HE1ZFKCKlZNcfjdvgslRoeXfr5C/PFIZx9zMIfQ+8TZ0CxubWml/8/9v0cJCJXeM47a5 w7xQ== 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; bh=t+fuhMqkSSs3U3rJI/BIoK9PdHL3F72f87ztmcUFMiE=; b=f+hHjyfxW4/612pqrqBOBJ6PRcDjDW5qpwULo+J3jPY3XqpEee8FmOMLMCIgcguVBA eUrLh5fs8UzTg3TDuQkZFQ7l5syz1UsPgquf3PVrzAYRlqX3Di31VT16/AznEpQ2zq0X Srou555/qCbGHaHd0nHtJn2nt4jADaq7vffnDqkBtHW5CJDkq3YlnJGWGn93a50vZNML 5J16aBo2KVxv+w6wlx6MrSmujhWnPcLpSjPzHEc3YGvCbq67muTZPapupcEY28C9kFzQ lpgBVEqDrRxPh435aZHR9cSRIVxGT59A/9MWC4uipyV+Fw2JEinseyKySFKdp24CEXQv 6Pdw== X-Gm-Message-State: AKS2vOyhoznau3bT+KI0QQM3ngtN87tX2845L+OOufLB5nL9WTWKwj4p Jvq2Fa6iRNyIWutsvpe9xeGha+oHMVGe X-Received: by 10.129.131.193 with SMTP id t184mr9060431ywf.317.1497633860219; Fri, 16 Jun 2017 10:24:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.236.11 with HTTP; Fri, 16 Jun 2017 10:24:19 -0700 (PDT) In-Reply-To: <201706161718.v5GHIGAH068175@idle.juniper.net> References: <201706161718.v5GHIGAH068175@idle.juniper.net> From: Andy Bierman Date: Fri, 16 Jun 2017 10:24:19 -0700 Message-ID: To: Phil Shafer Cc: Martin Bjorklund , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114ec83a3e246e0552170e7d" Archived-At: Subject: Re: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 17:24:23 -0000 --001a114ec83a3e246e0552170e7d Content-Type: text/plain; charset="UTF-8" The draft should make it clear that this change is being made. Before there was no way to access the operational value. Now there is only oerational value and no way to access the configured value. Andy On Fri, Jun 16, 2017 at 10:18 AM, Phil Shafer wrote: > Andy Bierman writes: > >It has always been OK for a config=false data node's XPath expression to > >point at a config=true data node. > >But this has always meant the configured value. RD changes this behavior > >because the new opstate datastore > >contains only the operational values of config=true nodes. Now there is no > >way for such an XPath expression > >to test the configured value. > > The XPath will refer to the current operational value, which is > better defined and more consistent behavior. During the lack when > data is flowing between and as system > components read and follow new incoming configuration data, the > operational value should be guiding the constraints, not the > unrealized incoming value. > > The XPath continues to work in a backwards compatible manner, but > the outcome is more crisply defined and the datastore > will have better odds of being self-consistent. > > Thanks, > Phil > --001a114ec83a3e246e0552170e7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The draft should make it clear that this change is being m= ade.
Before there was no way to access the operational value.
Now there is only oerational value and no way to access the configured val= ue.


Andy

=

On Fri, Jun 16, 2= 017 at 10:18 AM, Phil Shafer <phil@juniper.net> wrote:
Andy Bierman writes:
>It has always been OK for a config=3Dfalse data node's XPath expres= sion to
>point at a config=3Dtrue data node.
>But this has always meant the configured value. RD changes this behavio= r
>because the new opstate datastore
>contains only the operational values of config=3Dtrue nodes. Now there = is no
>way for such an XPath expression
>to test the configured value.

The XPath will refer to the current operational value, which is
better defined and more consistent behavior.=C2=A0 During the lack when
data is flowing between <intended> and <operational> as system<= br> components read and follow new incoming configuration data, the
operational value should be guiding the constraints, not the
unrealized incoming value.

The XPath continues to work in a backwards compatible manner, but
the outcome is more crisply defined and the <operational> datastore will have better odds of being self-consistent.

Thanks,
=C2=A0Phil

--001a114ec83a3e246e0552170e7d-- From nobody Fri Jun 16 10:27:10 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC463129AA3 for ; Fri, 16 Jun 2017 10:27:08 -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, RP_MATCHES_RCVD=-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 I0LnIAv9v_wy for ; Fri, 16 Jun 2017 10:27:06 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69029129503 for ; Fri, 16 Jun 2017 10:27:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 32CCBE90; Fri, 16 Jun 2017 19:27:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id aLiiw2CKPhfK; Fri, 16 Jun 2017 19:27:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 16 Jun 2017 19:27:04 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2A9520091; Fri, 16 Jun 2017 19:27:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9hoUaLf3Ldri; Fri, 16 Jun 2017 19:27:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CD9A20090; Fri, 16 Jun 2017 19:27:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8E91D3FC51A7; Fri, 16 Jun 2017 19:27:02 +0200 (CEST) Date: Fri, 16 Jun 2017 19:27:02 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Phil Shafer , "netmod@ietf.org" Message-ID: <20170616172702.GA60585@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Phil Shafer , "netmod@ietf.org" References: <201706161718.v5GHIGAH068175@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] XPath questions about revised datastores X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 17:27:09 -0000 Andy, in the past, there was the assumption that the operational value and the configured value are always the same. This is not really a 'change' but much more a clarification what the expression means in cases where the values differ. /js On Fri, Jun 16, 2017 at 10:24:19AM -0700, Andy Bierman wrote: > The draft should make it clear that this change is being made. > Before there was no way to access the operational value. > Now there is only oerational value and no way to access the configured > value. > > > Andy > > > On Fri, Jun 16, 2017 at 10:18 AM, Phil Shafer wrote: > > > Andy Bierman writes: > > >It has always been OK for a config=false data node's XPath expression to > > >point at a config=true data node. > > >But this has always meant the configured value. RD changes this behavior > > >because the new opstate datastore > > >contains only the operational values of config=true nodes. Now there is no > > >way for such an XPath expression > > >to test the configured value. > > > > The XPath will refer to the current operational value, which is > > better defined and more consistent behavior. During the lack when > > data is flowing between and as system > > components read and follow new incoming configuration data, the > > operational value should be guiding the constraints, not the > > unrealized incoming value. > > > > The XPath continues to work in a backwards compatible manner, but > > the outcome is more crisply defined and the datastore > > will have better odds of being self-consistent. > > > > Thanks, > > Phil > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jun 18 21:54:18 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DF2127011; Sun, 18 Jun 2017 21:54:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149784804955.10723.13177357489958504644@ietfa.amsl.com> Date: Sun, 18 Jun 2017 21:54:09 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 04:54:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author : Andy Bierman Filename : draft-ietf-netmod-rfc6087bis-13.txt Pages : 64 Date : 2017-06-18 Abstract: This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG data model modules. This document obsoletes RFC 6087. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-13 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 19 00:21:26 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B093C12778E for ; Mon, 19 Jun 2017 00:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQdKBxpZkBJ0 for ; Mon, 19 Jun 2017 00:21:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AF9126BF6 for ; Mon, 19 Jun 2017 00:21:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIT63950; Mon, 19 Jun 2017 07:21:19 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 19 Jun 2017 08:21:18 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.18]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Mon, 19 Jun 2017 15:20:17 +0800 From: wangzitao To: Martin Bjorklund , Lou Berger CC: "netmod@ietf.org" Thread-Topic: Some comments on yang tree diagrams Thread-Index: AQHS6MyAF6Hs5y+U2kSOuNFx4+IvHA== Date: Mon, 19 Jun 2017 07:20:17 +0000 Message-ID: References: <149735725207.17561.16997653317514816844@ietfa.amsl.com> In-Reply-To: <149735725207.17561.16997653317514816844@ietfa.amsl.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.161] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59477B70.0019, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.18, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1d7fee21b5edea3b7038752780205c04 Archived-At: Subject: [netmod] Some comments on yang tree diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 07:21:25 -0000 SGkgQXV0aG9ycywNCg0KSSBoYXZlIHJlYWQgdGhpcyBkcmFmdCBhbmQgdGhpbmsgaXQgaXMgdmVy eSB1c2VmdWwuIEhvd2V2ZXIsIElNSE8sIHRoZXJlIGFyZSBhbHNvIHNvbWV0aGluZyBuZWVkIHRv IGltcHJvdmVkLiBGb3IgZXhhbXBsZToNCiMgSW4gc2VjdGlvbjIgVHJlZSBEaWFncmFtIFN5bnRh eCwgaXQgZGVzY3JpYmVzICIgISAgZm9yIGEgcHJlc2VuY2UgY29udGFpbmVyIiwgYnV0IGluIHNv bWUgZHJhZnQvIFJGQyB0aGUgY29udGFpbmVyIG5vdCBiZSBtYXJrZWQgYnkgIiEiLCBmb3IgZXhh bXBsZSAiaWV0Zi1pbnRlcmZhY2UiIFtSRkM3MjIzXS4NCiMgQW5kIEkgc3VnZ2VzdCB0byBoaWdo bGlnaHQgdGhlIHN5bWJvbCAiLXciLCBpdCB1c3VhbGx5IGFwcGVhcnMgaW4gImlucHV0IiBvZiBS UEMsIGZvciBleGFtcGxlICJpZXRmLXlhbmctcHVzaCIgW2RyYWZ0LWlldGYtbmV0Y29uZi15YW5n LXB1c2hdDQoNClBsZWFzZSBjb25zaWRlciBteSBzdWdnZXN0aW9uLg0KDQpCZXN0IFJlZ2FyZHMh DQotTWljaGFlbA0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogbmV0bW9kIFttYWlsdG86 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQq3 osvNyrG85DogMjAxN8TqNtTCMTPI1SAyMDozNA0KytW8/sjLOiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmcNCrOty806IG5ldG1vZEBpZXRmLm9yZw0K1vfM4jogW25ldG1vZF0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zLTAwLnR4dA0KDQoNCkEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5FVENPTkYgRGF0 YSBNb2RlbGluZyBMYW5ndWFnZSBvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAg ICAgOiBZQU5HIFRyZWUgRGlhZ3JhbXMNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTWFydGlu IEJqb3JrbHVuZA0KICAgICAgICAgICAgICAgICAgICAgICAgICBMb3UgQmVyZ2VyDQoJRmlsZW5h bWUgICAgICAgIDogZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zLTAwLnR4dA0K CVBhZ2VzICAgICAgICAgICA6IDQNCglEYXRlICAgICAgICAgICAgOiAyMDE3LTA2LTEzDQoNCkFi c3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBjYXB0dXJlcyB0aGUgY3VycmVudCBzeW50YXggdXNl ZCBpbiBZQU5HIG1vZHVsZSBUcmVlDQogICBEaWFncmFtcy4gIFRoZSBwdXJwb3NlIG9mIHRoZSBk b2N1bWVudCBpcyB0byBwcm92aWRlIGEgc2luZ2xlDQogICBsb2NhdGlvbiBmb3IgdGhpcyBkZWZp bml0aW9uLiAgVGhpcyBzeW50YXggbWF5IGJlIHVwZGF0ZWQgZnJvbSB0aW1lDQogICB0byB0aW1l IGJhc2VkIG9uIHRoZSBldm9sdXRpb24gb2YgdGhlIFlBTkcgbGFuZ3VhZ2UuDQoNCg0KVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3Jh bXMvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlh Z3JhbXMtMDANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zLTAwDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxp bmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0K From nobody Mon Jun 19 08:17:18 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99753127977 for ; Mon, 19 Jun 2017 08:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6CXMkKGJdgl for ; Mon, 19 Jun 2017 08:17:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8422F12717E for ; Mon, 19 Jun 2017 08:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3602; q=dns/txt; s=iport; t=1497885435; x=1499095035; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=SX2RtH+dPajwBmUzJVIKq2ceekEBHY7osP30RQXKDGY=; b=W0OxK3iX3y4+0oJT65KsPQMS4TaxnjdrIWLC4yzG1iStu58216EW27j7 v+vb92J9nPCpnqbU+PD9+ZDcfVJJAY9NPU4B9sd0eAhJQkEU5+TPqX73i uMsY83oPXaOteWmHiFnjyCN+PzNEC1cuiYIMoqScnV2b4Yuq8gQXmxYLG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAACG6kdZ/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0Hg2SKGZJtlQSCESENhSxKHII4PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?ZAgEDAQEhEToLEgEGAhoCIwMCBCULFAESBAENBYosEI9mnWGCJothAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYELhziCbjSHe4JhBZ5eAocujC+CCFaEcYNuhlCVCAE?= =?us-ascii?q?fOIEKdBUfKocPdohCgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,361,1493683200"; d="scan'208";a="259709258" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jun 2017 15:16:46 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v5JFGkTn025588 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Jun 2017 15:16:46 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Jun 2017 11:16:45 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 19 Jun 2017 11:16:45 -0400 From: "Acee Lindem (acee)" To: wangzitao , Martin Bjorklund , "Lou Berger" CC: "netmod@ietf.org" Thread-Topic: [netmod] Some comments on yang tree diagrams Thread-Index: AQHS6Q8Q/1mh09tbr06MMr8vipQSIw== Date: Mon, 19 Jun 2017 15:16:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <0AF11BEB78705C458D70C0DD132E8D49@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Some comments on yang tree diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 15:17:17 -0000 SGkgTWljaGFlbCwgDQoNCk9uIDYvMTkvMTcsIDM6MjAgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9m IHdhbmd6aXRhbyINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygd2FuZ3pp dGFvQGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+SGkgQXV0aG9ycywNCj4NCj5JIGhhdmUgcmVhZCB0 aGlzIGRyYWZ0IGFuZCB0aGluayBpdCBpcyB2ZXJ5IHVzZWZ1bC4gSG93ZXZlciwgSU1ITywgdGhl cmUNCj5hcmUgYWxzbyBzb21ldGhpbmcgbmVlZCB0byBpbXByb3ZlZC4gRm9yIGV4YW1wbGU6DQo+ IyBJbiBzZWN0aW9uMiBUcmVlIERpYWdyYW0gU3ludGF4LCBpdCBkZXNjcmliZXMgIiAhICBmb3Ig YSBwcmVzZW5jZQ0KPmNvbnRhaW5lciIsIGJ1dCBpbiBzb21lIGRyYWZ0LyBSRkMgdGhlIGNvbnRh aW5lciBub3QgYmUgbWFya2VkIGJ5ICIhIiwNCj5mb3IgZXhhbXBsZSAiaWV0Zi1pbnRlcmZhY2Ui IFtSRkM3MjIzXS4NCj4jIEFuZCBJIHN1Z2dlc3QgdG8gaGlnaGxpZ2h0IHRoZSBzeW1ib2wgIi13 IiwNCg0KSG93IGRvIHlvdSBoaWdobGlnaHQgYSBzeW1ib2wgaW4gcGxhaW4gQVNDSUkgdGV4dD8N Cg0KVGhhbmtzLA0KQWNlZSANCg0KPml0IHVzdWFsbHkgYXBwZWFycyBpbiAiaW5wdXQiIG9mIFJQ QywgZm9yIGV4YW1wbGUgImlldGYteWFuZy1wdXNoIg0KPltkcmFmdC1pZXRmLW5ldGNvbmYteWFu Zy1wdXNoXQ0KPg0KPlBsZWFzZSBjb25zaWRlciBteSBzdWdnZXN0aW9uLg0KPg0KPkJlc3QgUmVn YXJkcyENCj4tTWljaGFlbA0KPg0KPi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj7lj5Hku7bkuro6 IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnDQo+5Y+R6YCB5pe26Ze0OiAyMDE35bm0NuaciDEz5pelIDIwOjM0DQo+ 5pS25Lu25Lq6OiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj7mioTpgIE6IG5ldG1vZEBpZXRmLm9y Zw0KPuS4u+mimDogW25ldG1vZF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy10 cmVlLWRpYWdyYW1zLTAwLnR4dA0KPg0KPg0KPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPmRpcmVjdG9yaWVzLg0KPlRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5FVENPTkYgRGF0YSBNb2RlbGluZyBMYW5n dWFnZSBvZiB0aGUNCj5JRVRGLg0KPg0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogWUFORyBU cmVlIERpYWdyYW1zDQo+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBNYXJ0aW4gQmpvcmtsdW5k DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBMb3UgQmVyZ2VyDQo+CUZpbGVuYW1lICAgICAg ICA6IGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtcy0wMC50eHQNCj4JUGFnZXMg ICAgICAgICAgIDogNA0KPglEYXRlICAgICAgICAgICAgOiAyMDE3LTA2LTEzDQo+DQo+QWJzdHJh Y3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBjYXB0dXJlcyB0aGUgY3VycmVudCBzeW50YXggdXNlZCBp biBZQU5HIG1vZHVsZSBUcmVlDQo+ICAgRGlhZ3JhbXMuICBUaGUgcHVycG9zZSBvZiB0aGUgZG9j dW1lbnQgaXMgdG8gcHJvdmlkZSBhIHNpbmdsZQ0KPiAgIGxvY2F0aW9uIGZvciB0aGlzIGRlZmlu aXRpb24uICBUaGlzIHN5bnRheCBtYXkgYmUgdXBkYXRlZCBmcm9tIHRpbWUNCj4gICB0byB0aW1l IGJhc2VkIG9uIHRoZSBldm9sdXRpb24gb2YgdGhlIFlBTkcgbGFuZ3VhZ2UuDQo+DQo+DQo+VGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRp YWdyYW1zLw0KPg0KPlRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBh dDoNCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy10 cmVlLWRpYWdyYW1zLTAwDQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMNCj4tMDANCj4NCj4NCj5QbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv Zg0KPnN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdA0KPnRvb2xzLmlldGYub3JnLg0KPg0KPkludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+ bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QNCg0K From nobody Mon Jun 19 16:53:16 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF6512948A for ; Mon, 19 Jun 2017 16:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 RZwXwm5Pn8WI for ; Mon, 19 Jun 2017 16:53:13 -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 71900129516 for ; Mon, 19 Jun 2017 16:53:09 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id c11so27181882wrc.3 for ; Mon, 19 Jun 2017 16:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=1BL+LSP5gy8cgPRy8QRFHKOad1ee/i3jMz78hplmlDY=; b=p8wdWaHhNXsX2ew1e0W6l4EB7p893ZM7S3rcv4guQ1uWKyUtAvP7vzFSu4xItObZds pQOz9VfsdwjwOMvcIGJIkdg9KRMpytuGrsrLdXlOBIlwBSZGsw0CkbO0/6dHzOF4Ir6l v3nDB+V98ODrWBWlw//YGKp6BDjaQ8LiqLC2bsNQN3X46IcPw06rUpjW5hY0Y6pxGXVS 1j5hD3DB9NDHXJYppRuLLC430tnP4AUupO4HTFtsP7xtrXv5qEJbg0e+0i0WePK8/Jdy VUgtPoEQV1nWd8AQRTvZ+ih6kIskBx0iBruC3UDay+yEr+7BpG9l+MlaCWDiblUIojGO 665Q== 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:cc; bh=1BL+LSP5gy8cgPRy8QRFHKOad1ee/i3jMz78hplmlDY=; b=Scb/DJJdDilnzMgGUA1ms6pP/t018giV74aLFM7dsqJEA+K6lZpX3THgBCYQC5obX5 THBBPVp2XmFThTyUSw0X+99IYeXC/q/DEIqcKKrclL2+851q5ezR/MF2bndKEZcY0tFF Yr+b0mTwUXAnHO+VkkiHIDq8nX3OpXoGrOfZv+tw80h4lKR9SYUhYKZeyrN7ghAjvNck DuBUqPSDWKheDnTFxcCM2MbednGbaParsxhpERVhmZtAzS9FSUUjd4HgdBGTFezm92Ro 5Vpkr5ciN4Znr07Y/+HW0PcGiejgoYb6NJ6fMPylXQ0rgGokp3ERR37Uy4zk2W4YQO5/ l9bg== X-Gm-Message-State: AKS2vOwhUjVSVpiLJrS3+GrFxWGo5dIElSvJbfOWiVLs17/HCI1aFjmH MD0BdbWt39skT6cX3ZINy2cXDDu/Qzcx X-Received: by 10.223.163.135 with SMTP id l7mr9594243wrb.88.1497916387607; Mon, 19 Jun 2017 16:53:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Mon, 19 Jun 2017 16:53:07 -0700 (PDT) In-Reply-To: <149784804955.10723.13177357489958504644@ietfa.amsl.com> References: <149784804955.10723.13177357489958504644@ietfa.amsl.com> From: Andy Bierman Date: Mon, 19 Jun 2017 16:53:07 -0700 Message-ID: Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="f403045f14662fdad7055258d6cd" Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 23:53:15 -0000 --f403045f14662fdad7055258d6cd Content-Type: text/plain; charset="UTF-8" Hi, This draft addresses all remaining open issues, include the rewrite of the opstate section. I think it is ready for another quick WGLC and then back to the IESG. Andy On Sun, Jun 18, 2017 at 9:54 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the NETCONF Data Modeling Language of the > IETF. > > Title : Guidelines for Authors and Reviewers of YANG > Data Model Documents > Author : Andy Bierman > Filename : draft-ietf-netmod-rfc6087bis-13.txt > Pages : 64 > Date : 2017-06-18 > > Abstract: > This memo provides guidelines for authors and reviewers of Standards > Track specifications containing YANG data model modules. Applicable > portions may be used as a basis for reviews of other YANG data model > documents. Recommendations and procedures are defined, which are > intended to increase interoperability and usability of Network > Configuration Protocol (NETCONF) and RESTCONF protocol > implementations that utilize YANG data model modules. This document > obsoletes RFC 6087. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-13 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-13 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --f403045f14662fdad7055258d6cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This draft addresses all remaining = open issues, include the rewrite of the opstate section.
I think = it is ready for another quick WGLC and then back to the IESG.

Andy


On Sun, Jun 18, 2017 at 9:54 PM, = <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the NETCONF Data Modeling Language of the IETF= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Guidelines for Authors and Reviewers of YANG Data Model Documents
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Andy= Bierman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-netmod-rfc6087bis-13.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-18

Abstract:
=C2=A0 =C2=A0This memo provides guidelines for authors and reviewers of Sta= ndards
=C2=A0 =C2=A0Track specifications containing YANG data model modules.=C2=A0= Applicable
=C2=A0 =C2=A0portions may be used as a basis for reviews of other YANG data= model
=C2=A0 =C2=A0documents.=C2=A0 Recommendations and procedures are defined, w= hich are
=C2=A0 =C2=A0intended to increase interoperability and usability of Network=
=C2=A0 =C2=A0Configuration Protocol (NETCONF) and RESTCONF protocol
=C2=A0 =C2=A0implementations that utilize YANG data model modules.=C2=A0 Th= is document
=C2=A0 =C2=A0obsoletes RFC 6087.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-netmod-rfc6087bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-netmod-rfc6087bis-13
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc6087bis-13


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

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--f403045f14662fdad7055258d6cd-- From nobody Mon Jun 19 23:05:18 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D90B1286CA for ; Mon, 19 Jun 2017 23:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 QVUMDlPu7PnL for ; Mon, 19 Jun 2017 23:05:13 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0105.outbound.protection.outlook.com [104.47.32.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0012126DFB for ; Mon, 19 Jun 2017 23:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9fhj7nx0F8zyAqFfaGM4CmpE8ili24SMQ41VaF9ICfU=; b=ZdZSKlP6IcJj4uuARsocsAuKBp2U92GEoKv0q6UJ6Y1g15CG/9UyXrWdzVZDFnu54HJuC/zQliFcbe14L0cVawN3geM2TUF89nAMbIJabXox32dUJfLjUlNIOQ5K45ybh4p8ReS9GwI0TNh9iwsbcWUJIX3Yf3pgH+uWRscyiGU= Received: from SN1PR05CA0020.namprd05.prod.outlook.com (10.163.68.158) by CY1PR0501MB1658.namprd05.prod.outlook.com (10.161.165.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Tue, 20 Jun 2017 06:05:12 +0000 Received: from CO1NAM05FT049.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::208) by SN1PR05CA0020.outlook.office365.com (2a01:111:e400:5197::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6 via Frontend Transport; Tue, 20 Jun 2017 06:05:11 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.15) by CO1NAM05FT049.mail.protection.outlook.com (10.152.96.164) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1157.20 via Frontend Transport; Tue, 20 Jun 2017 06:05:11 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 19 Jun 2017 23:05:10 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v5K65AhW011133; Mon, 19 Jun 2017 23:05:10 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.15.2/8.15.2) with ESMTP id v5K65g8E000929; Tue, 20 Jun 2017 02:05:43 -0400 (EDT) (envelope-from phil@juniper.net) Message-ID: <201706200605.v5K65g8E000929@idle.juniper.net> From: Phil Shafer To: Andy Bierman CC: "netmod@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <927.1497938742.1@idle.juniper.net> Date: Tue, 20 Jun 2017 02:05:42 -0400 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.15; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39850400002)(39860400002)(39400400002)(39450400003)(2980300002)(189002)(199003)(9170700003)(478600001)(53416004)(76506005)(230783001)(106466001)(50466002)(1076002)(23726003)(305945005)(7126002)(4326008)(2810700001)(8936002)(105596002)(5660300001)(7696004)(2906002)(81166006)(2950100002)(8676002)(8276002)(356003)(53936002)(229853002)(6916009)(6246003)(77096006)(189998001)(47776003)(86362001)(110136004)(38730400002)(54356999)(97756001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1658; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT049; 1:pEOgAKc/s2xcl+WhfPJgyrxlJv8T5djV8d2K1UaPF+t16Z7I02EqspE3iJpVp+k7IwugJExnC9ckUFZ7rpTQvkod4xYkgOuKZfsYXktv9WflnUa0VP9I2yTAkmLBjl6Tvd14vCgeJPUVismRvi/1Vw37YoxACV2UBmBfC2PSQ0Fd1tIqaMIpUQeC0jC1RjSsAISEHb9XPxy4HoSZys2ElEYJObgt+crUpnf03U1SY2MaDUd8dKYmmGgOTUlRuLHX2b4FcbjSfBHZw7VxaFTIiERlh+WIFNC3pcJPkwAv0706wuhaSNz2NYfIJFqNp9Xdgo0gnV9illsReYmys96uV1+/4gkBYK6oHfp7teSP2xJXwGwuobiggK2HoI5E24an5qAfOz4Rzitxq/jj2Ol39MHyvywen4XQgwD/jCOlW5+W7BuNH5EQrM7SU1yRfO7ue+c3tiv9amBc9sqNwPWWWMX11otuBrraI9CvjpIa/zXbpWsTv0VFUdgpjPpuHwQz4zwuofv8BJD9J2vIcsrGRcIOjTl2G1B+5BXW9XQV8mQ= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d265f570-029d-43f2-a06f-08d4b7a24fd9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500054)(300135000095)(300000501054)(300135300095)(22001)(300000502054)(300135100095)(2017030254075)(300000503054)(300135400095)(201703131423075)(201703031133081)(300000504054)(300135200095)(300000505054)(300135600095)(300000506047)(300135500095); SRVR:CY1PR0501MB1658; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1658; 3:MuYJCKOQ8Me5qV/GVfvhHPagwnbHKpERazMTHTBFNuKz/46fN3xTobR7cTRBnD0BgT1wmaFQURy2om2t5wznEXizwYJQgtPGKR1xeyI6Ya0OKSKhus2soBxbSmuPmyR9kZLy2DHVWu7pskSx75NLgSdNm02X8XbO0mtH7Cv6xiNZi3mq7Vm+s1ygs62ypdcO/nVgXZ6is4blfqmVB0FBNEdoyLexud5GiNsU3Nsn+1NIGm+qwMzdJLma7gyCCanMZe9QOmmOfqQbrgwqJ4xW80kWdupjQYSeZpp7x3t7vavt8zs+Ku6+5Dm7kpnd3xcxm2+J9ucrTd6wf+ve73Us82pPjxtRhMx3mV5/iIUttOc+CFPFTCkia/oSsdbn6eQH+lnc3y+nlhX+Vdjb+BMbD9dAa1vIK0rL21mu0IRJsKg6fSFePJTD/P1Zeweeh4gvl9xLjnR0cRzGYmb8i6xEwGGEt6JS6kTBWeja70BTa+CgRxH0G1QSczNHa2LLHwvvHsmI9HX4KBiTDnHznckU94mq5x10Zvv5O3UMLul2wopAWGGOQKV1FKdPBFYWv7m5CMnpfPI2yCO+xJQFCOe2cpctk0uIQSFWUK/sydp4PVbGcTB3LF1jvbNMEnfvTPZMhm5Ozg+bsLhGU6hAyuNgQ0MnZhLLNFdCd/9Dd+Ms1y7f9G+WSMm0YSYQoDcoGYsUbe39rUdT6VdYI5Fs30Z7/5LFx7uwDwXr/+X1Ha4LMxrMTAHrLIB6KtS0O++zJyIEB+6LESWqx+KDiW/aeEMVbLfcNM1ZAS8RTVkjxEPEyUv0IfxuY9taLsfqpdsmhtaKu1K/oGcf5TzGvYklHngWikKo5o3n4l3KmjpTYUh5F2jY/JZLJ9I2hKmAO1bzk6XG X-MS-TrafficTypeDiagnostic: CY1PR0501MB1658: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1658; 25:55V6m4ZMF7dw6mZrU6PeXPD1eQy38r/5pMK6UGJq9wapW2+YYnzYG/1DnwjP9+zpWdHQqeVzqa+BWywrNyfprJENejRAQOCmo+ET/C2ezcGhhTxBqTSX+U8717VKcxyIAViIB8doNicQFJDHE/iKe+wYZhXlQua/l0MaDEfpp+5MklYkF/XijgjyNbvmwnnMdty492DLu0zfsfIBXkyTrsewonh1i99WfklSvtHYV2AihpMDhe5pMcY/lQ5iDrYhfyQSSiPDZ6jAmnp6Lbnrc2Gc7SWaP1vVOXbw4YiosBdXINHu6FPXLV5QEGm4VSbh/qDqmoVAl+PFr7HX/K+LJ37PpXiPKTZJODPPuhKh1r6bKIM6eYT2Kfxt4qeog03ktl9YdWG5E7SNQ5AH1w1XTrUyajismDvVghisYL9Z+I9p6TaYVsIPOEozsLiwCsZx9hWtzGtabtc6J/r0LiJnUUnd/8v/CH1+ZdkNZUtRrLkQ9VfwmHdzzrkpJpqzDW2hjtbHOlQ+etek5H9EyzWurdyL4bVLRyJXqWLzkmNqT1jd5OlHDESJJSK8lefys5ucDEmquQgw1s8wboOIxgrXW6EnjzRn3DuYLr6sb7cMvpdg/UnuIQ6TU9+zoI00KXZ2+eVUFKTmsK0jAKZ9GF+kK4N0pLyw9/oOokaLwYTtAbM+SGCuAcab7ddteqolzPKVBNLoP60lZIpG3z49K/2H0DRMKx526o8hIZOHeX0n9jNy2gvIee8arAYBSl/3pLuNJjH73M54Q2r7o/x/aXW+iZrQ4OiZYcNOjvhB9m5E3LFidq2RPftd1QbVp50s3qx4V7EmX967UOrgDodc+TIULRSXrcrH138AbZC90bd0HxdE4f/UwJi4pRiVeSuoqx9eYtblBW+0XPZyg+QYnXfd8CmbXe0nOvSBcN1f+XYlYJQ= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1658; 31:kfvjI3lYCis89wyP+1ui9yvx2nlLboeSlKJlZYbcQhK9qT4Ymy5JAMbBLjPijJflYmXS2jFGDBEuiy2z4THWF2etdhEtLmrzdIIG0Kho7u/NcQDmchIyCn8xLWVsjKE7Md8+Zlxb2wtDCLnVS0mEGziQ9qW3f5MLXpd8MzB0M3SX0iCwlc/nQ05d4ouAtV3GPLQaK0IlDrR1Fesjr3GiCi2CmS39IUnYaevtE2oQM+4hpaKXCqUmsoYmSkty7cAhTzlcJf3UtH8EBsgnr38/NAg4G4wCTngOsNFakho/OBOjJ/G+ZFZWtnVStvUqoNvHTga8zSZhxf52MRm8TUZp/BgpEjvjo3B4pIDLj/OIeFx3JdeXnuSandaI6I6dAMVRupGpQTn94NUbzMgOBLk1MeUp6Dmv0A5RCcElXqCdpMc2Se/0mn6dAa4fHSX+HjEDfDgl65Qr06nz3RuWznfQt8vvA2DZ5PEVUbYVp2e4Lwk0S8DYEGZqP5e5EOxOuLMjiYVFsNRTt3HUM5m0cXY0Houq/dW3VW2uo1Aou5TAVsSMiSBXQiupSfD/6GYfzZgKQ8EIDzfK0/njs5xShtYXuLoqduuvaOMGTcmnBzlW8RccQ/UPouSe9k3XW0aqpBsq4fezYaRgNf7/45WtqYOH5wahfB13O2MQN+5AO/U5lx69DIVfsOgEgJHIONizZqQGmYnxJbuaxCmW/2vmv09jqw== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1658; 20:sxQcpFeR2E9TziwJvSwlnzKRGY7Zp6sIN91FXjMnW8RuK6p9hBXKVo9bqTDnZ1sUT9lwqPQjHvQE4cGTiA8IQ4Jg32sxbtqnNvp7GZR+HIFNyTceOSAQ/F3BwaDIrbo34/Ygf6SovgLjS5p5t73O7f0Z5d+VB/O8k8Hnhe3FuFnchhG6dkVJgHNpMN65Dh3fGcHydpfO4mSmMwljlos+I7LzmVix9CYEiacCKsGcmB0bFEQs8RqkiaLG/ZO+/EQV/StlrKkNwb14C7r4JjF+PUs+AHDqtYUgNmmDG7HEjbt8iHpr9ms+4ux7z8Vr30GTQaCDJpVrR5mFlWVSZFBVBQp0SAFJ1zpdFm+XTbq/0SlSns/1aoK2dI15hsJ2pcaiKmyljU2cfM6oATSXWCkl+JCBjM57g/j4YtvN3rnS+yrhFmlkOhmxMUOykmftBXHZVmr0JOvxJsTgQuXRBnTazdDsgQocGmGPQujBVIGrCYtwUrAQoQwfp3Mci0jb0/bz X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13016025)(13018025)(5005006)(8121501046)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0501MB1658; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0501MB1658; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1658; 4:0Ba0KAGQNeeiKNK+6uLjT51YdGQgOYOTDLu4qJFI?= =?us-ascii?Q?hNxOUo6240F4yyF+NQL9DpJFKfwfqKwTIHmnW/ESSMNf2MTR15rTusM8Ez+0?= =?us-ascii?Q?uC3Tme8JiCxmt/FQWiIAvub3jJrylc8GG4jEO/bjYzJDEBuCQBUP+zUL70gm?= =?us-ascii?Q?eHGgOWLHSW498bGA1M+IwryasAltZBSoRZIA4nPk/7q0D8gu1pOWdLodZ2wl?= =?us-ascii?Q?Zjlt5GyOqzFFF1SpLngN8r2+L3vGbjnke55FPkqYpl5UNUAmbOl3QC9m/2K9?= =?us-ascii?Q?EuhLSp9UO+c23Y2qjRIayKg/lqWsT8SEjaO0kYyAx1HFV6PrG1u38Ld8cxho?= =?us-ascii?Q?w4csWtbmpS5T1J37gycQ/osgMuIFgY2LEhaMqMeqda+RKOm44PnJ5bQHovj9?= =?us-ascii?Q?eYViNydohum1pr2JtZ/StHf2g9jRsRbdpuBqlLdgoCJSVxVKgUxzeWB4HFV/?= =?us-ascii?Q?yBwkTCUdm0+2mF9YGSknh+XsCfDaFbl2kH6nSZuesw3lg62Gt09QdXGc0Kb+?= =?us-ascii?Q?7EOPc5xk/gqjUAv6Wu3/gm+FpuMmAgz8//43reJ1CYiZ6d12rrZ64i1lzwSw?= =?us-ascii?Q?mnXakj6x269szgJD245lQ4656tBFl9mUpjPPYppU0usFQiVCalbUWPhr6i8q?= =?us-ascii?Q?5WyImoX60XtnNjGOAwUW9MFw5r17WR/dh7A5BtNBRGNoyPQPm8oan4MLJRsD?= =?us-ascii?Q?161T8WkZ06M5tep6at+BBYDIfrvFZTWSdS32vpMFgWMhQfBXd7SAwdjYwyxC?= =?us-ascii?Q?dm2bApRK8uRXQ4dFa8k9o8bxe4IyH9B/izapKrB/pWXbbMvPs51L9i/CGZtT?= =?us-ascii?Q?pTjJPKDRuEqy0f9mQgrpKz962l5CR+8RG419t6mUvc4gnb0x0Twnh6gDXC5T?= =?us-ascii?Q?AP3pnoA2D/nZBFNQsd47lMTX/+RZGk4RIqednjcL9GwJhDSXSfoeBLgAJso5?= =?us-ascii?Q?6VO4cB7MaE8grh/rMv2i8OpWsQDEAEK1jVFnu752hUfQbu0WE+GqP8cMzQVg?= =?us-ascii?Q?qsYDGn8anZaNRSFeXVIUo49H5NcA1s6R2kq+ueH1nZJ7Q1nUJeqHJ2nVomQN?= =?us-ascii?Q?g9EosxOIUd1o88pPQTidmfgh4wEUUD2Qj0CuAVyV0PbEfwNjxLoXx1R18pxH?= =?us-ascii?Q?BCtNXZa3L72+afFxVkA/ffquVU5Tu3CNFtJqBkI8woTsHVeN7eurMy2NqhwH?= =?us-ascii?Q?u+32tTowcsBAPxlugJTbuUlmNUL69/3oWc66?= X-Forefront-PRVS: 03449D5DD1 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1658; 23:XAYwm97k+QhW1S3M2jzXB0vn1SXydeEMeAFdCNr?= =?us-ascii?Q?P0zLDdOEW7Zp3cilDO/c1G/WySJ/tx/NBEMXELm/WtkcZtnGvtNvxdO6C0FH?= =?us-ascii?Q?b2ft+AJ5SeLp11/k3imJcciVZiND5pCXd9CEnfwLK/DYg0MhJ6OQTC7YXglT?= =?us-ascii?Q?xsKNT/NiZELOZ5EC03IL75hPYirL9qXXsFDWiIGoOp+DHMSBiHQp4rTb10If?= =?us-ascii?Q?dkcmoVVmVGSrB2+2d1y6q9CvC0SOYgps5MCuUyeEHbmW3CFOIFy+UPtWCCqy?= =?us-ascii?Q?WDPdWepFf+B79SApD4TGb47eQkpLYOWT9xmtIh4Y1+QNfj1ONcmFZ8hrhk8b?= =?us-ascii?Q?7GFqUhRAG63wIitrtrt+ltkn64vUyXDekjyWoMBaCMuz2Vbphj3FC9e40nkN?= =?us-ascii?Q?6cReQZeKMVlInqHld2qgQq9IfwI06WStxXlXRRknY0MqMmR7Orojq0GwHcVE?= =?us-ascii?Q?ruVw7G4tMUubafBtHQVios7BPUUwcs3f+iEGBy/lZrJwOpcq24MAEPeIC1oP?= =?us-ascii?Q?s6Ci0P4wQQFvFJLnzrGY/OIHA9mZMisiPR+PIbnWJgV9rvEolTsPscN3xMoC?= =?us-ascii?Q?B57v0/MoUE36UIwfLYgjPNxHc5D8YM7AWnkt84vwTUbZCAubhnHiFLkwGUtV?= =?us-ascii?Q?42n5G7CYeg7vsapDqWHRXPc+sdmoDLk5CHklvuHmVBQFyeZqvXy5f/5SAnzo?= =?us-ascii?Q?3ALEMP/gzyHxQiH2hFJzHs78IPwxxsECmsbDQxNMKEo0l5xV0P5Ih7oVGJSo?= =?us-ascii?Q?iLGwLob8FjTNl1G7/HaxZf3IOglOszJxXL+0DHVu8toWqCC8USOcJ+j2DYM5?= =?us-ascii?Q?k1W8dhlZ3ihrewzv/pIArONF92+MLIIPgkADikPBz9pElHWafc8YbZoR/Agx?= =?us-ascii?Q?OQytmw3LvL+cnwnXTriFfu+3JlCyj9QijigyppdLvjmPIAau/LjolAxpZGCd?= =?us-ascii?Q?eK8wKbGuLQEGou0T691FyFPdoyvreyUGvFbWaZqztOKfnZwQABjxR9QlQPmC?= =?us-ascii?Q?S+ugc7mj8vA/p/21tpUW7rH0w51l6yahfnS8/fy09aVAKxr6S3/FuD7QFWwJ?= =?us-ascii?Q?s80MTjZCX26NSaeWw7sEz++R5nLe7I3qPxPVyMxhtQ/Ox/R8YdHjsBEo0MV+?= =?us-ascii?Q?AbxXnUsQsfPJRuOOKErHsgRmTIoyBPtz0?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1658; 6:G7FZt7qN3eX3F2+ZSmPRc8iS0HIZgat3HiAymAmk?= =?us-ascii?Q?dhtnLQcRmZ4udOEjIGB5KjLSrWHun/suOKdyTGL23VraIx0Juzzv7zjG3D4Y?= =?us-ascii?Q?zQhJfxWl+C1kQDpHhq5CD+a13pmtx+03nXQTR40nXEQ17DL9A06hYitcwYeU?= =?us-ascii?Q?NtSn8ddniU8fVomkAaQSdIF1+aXwYL0U/5wIR09z1iKJSIdaJ7yoHSGSJVfr?= =?us-ascii?Q?TOVhDVeL1oQT0IKKT8L+UkLQu5eTs/o39MNl6eAY73q5dkdYpYwf6abfVIFU?= =?us-ascii?Q?T/qp1YxLBLH80/Wf/GXIG7QN/FYU88bNk8yVXI4ds2KbhPX7OTRnzEpuPetV?= =?us-ascii?Q?hKVDsGlKdOlpORrOgXexoTBrejiF0r1zOCwgp4qKygwbigQv/35pwSVjp38P?= =?us-ascii?Q?TbU1lnD1EyqJAsC1fA5M+Eb+DV1aPkzKMaP3uxcmXdQW5VgXcKPwe4qmujwM?= =?us-ascii?Q?wnVVA9SjVg/9jaX5yVlkg6R8jB9Z2jonhVOz0lJDXSghRDpr3NuK+TD0mXNs?= =?us-ascii?Q?iuJXtEQS99puWocZfUfzXVg9gW4aSq/wON2N+J/MYKfn9HznSCwF2sHK2e39?= =?us-ascii?Q?xkkim1wIhTXhNik7yPkPRF7g/u1tQt/ZAC9c3ab4e3RSPbTlOKTW1/ofPWFZ?= =?us-ascii?Q?8pE+YJnCisVD8MsjtBGOkkkWLDECAusaei8M9K0BNMu8ZpWNxUsn2McIICb+?= =?us-ascii?Q?7K+lfT79IIbBthyIDt1VLO+PmUcoIpPZOegSllGaNDRC/cBnhtgpOPGRUzAL?= =?us-ascii?Q?LXLtS1oMbiV/Jkhitjv7u5PH6VmSp/2kqBUzBwjDfPQKZjoT/ClLxI6tdNkL?= =?us-ascii?Q?HM0DnVH5As2YLnvAr03P4sTKvvi1tygtXuBCahTo3LxTheKkUAIDjPLX5ACt?= =?us-ascii?Q?WydRkaygCQASevgKttlePwol1w15/yRZ8kQcLWPi5TMC2YHWtmmm+aXd+KnO?= =?us-ascii?Q?iA187GKamDHtGXF3zC0++jFnYkrtp9KKwg32I8FnnfKxDYMA8MVftliHLoB+?= =?us-ascii?Q?ySy+vHvEnm0y4xe2eSjXOjct?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1658; 5:uY74zqZRcx2LKJDs4VjxedKHYeyGWCBxj1s3UHoYszb4XOXAH+J924zbcrQQQrY1zqv8Goxh4QDZfJiCfwF3SNkZXHYIYtykGYbFeSKFJkb8kqd5AZ9R5Jb5vIn+vnAEOzWD4fgbAsC+hPbzzQzkXsYbMAKN6Cp0u9oTlkzGosvqoCseU5UMqHiaWHRqWS3T+s7xHgpr35zsQGdIvUGuoaajTMxZiRaX8fl/LJ6GOKbQ7wsQgaYiL+h/mwvrc3vBJBn6iBpnPHvvileopoi5dIuQzMe9HoC+bFl9T15/ejR7+cmOPq9JrGOMDqzEXl78/IWBntklLsSEahfBS5vxpAmY2u6ZibVt+YixMtvdHkU/ajD1g1sNqwHfBU+UHr9S2PvVmdvKUiA7iu/gEaQyaWc++VVJgxQEg/6ydCqQD6ClXPjCWop8ICvgXO05YHYniepi3YKi/F7Iws8E/Rx5IUqC5OW89F5q4CaHHWokkUJ3gqz7S6UsU6mjmUpUfZ8v; 24:56X5qAEVwSJUX4UXNAWvXG1QqgL7MKt/FcvWKwFFkE3oOeQBhthMFLBieNPbz5tYxHLeImmfvzJxHuTujwUvhOvpGakntEOWMM/HgKY0fOI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1658; 7:6Y6lPfgiBx55bPnFyj7lihARyiAydnHggM1M12lTOlP2jlv+12uoMNwC9aj2RCzEr9WawkFUoWiX/nxsOL2faMGsdkto1wAy+lPwjjFyyH5QUgibZhIXpRUR59is/fo+bjaSu+xzoIQ8aIx6stuO2ct/iDj9cSGC4OkVxDr1ed/eV1Z6yBDuA4kVv/HqO5v+Ea6L6Z4ZXagKcu/O3ZYDg9M+eC1G6hDwEgUR7jXa1auc1pcDsetpIK6bDHK38PEtrHg4A6PpiHCaKWG/JV9ZD19vaL7lRyJT0kzBA2jJE36HVV7IwUocmCT2BBRSPyoGTFKzySeknZPKdHauoWpCN11JCSFKhfK35vwTorhnU7ifEwTtIiYZpJBmk8xOzbBPIJSdBBqbJqf40XoYrHIngtSWO6W7S0sn7AkfvfoNDuHCHIbGXpRvugDpfyUkTJieEGkEw5hPXf+z7Yd1f2aTlItt/HULSTZVPrkjnDOsY+uDbMsO6+aaDHik1Ej/Ofh+14BLwils0oFjQ800P+yUGzzU94eH72mqtkawehWhgIioJlx3B/kv0ywsvuv9y812P6w5+fzzRts+f5VSSp2vkfELtiWRS120YZO05uz2gFFBGWZ9xf2u477jX3a29rCHJlofZ7uxtduEHUgrEhmZuMC+5TSw91sJPhv9J03EjWBoc6a8cwnUVwuGNYhDDmDVDZq4A2iIJM3xioXWtLTDPM3ZrfqNoSYppRZfZypPmez/v3PDQPYT3gU8FrZcQ3nvzrCzYO6QKAJDN5iu12pzjHJPnxl7s/AY5QrtF+RYNWM= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2017 06:05:11.5673 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.15]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1658 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 06:05:16 -0000 Andy Bierman writes: >This draft addresses all remaining open issues, include the rewrite of the >opstate section. >>In YANG, any data that has a "config" statement value of "false" >>could be considered operational data. The relationship between >>configuration (i.e., "config" statement has a value of "true") and >>operational data can be complex. The NMDA draft includes the following in its terminology section: - configuration: Data that determines how a device behaves. This data is modeled in YANG using "config true" nodes. Configuration can originate from different sources. - operational state: The combination of applied configuration and system state. It would be nice to use matching terms, either by importing the NMDA terms directly, or by mimicing them in this draft. If your "operational data" means "config false" and NMDA's "operational state" means both config true and config false, readers will be confused. Also you say "operational state and other data such as statistics" which inconsisent. Under either set of terms, statistics are part of operational state. >>The original set of datastores defined in NETCONF (i.e., candidate, >>unning, and startup) are not sufficient to fully manage a device >>ith multiple sources of configuration data. In additional, a >>separate datastore is needed to store operational state and other >>data such as statistics. Refer to >>[I-D.ietf-netmod-revised-datastores] for details on this new "revised >>datastore" architecture. Guidelines for usage of the new datastores >>(including the operational datastore) is defined in >>[I-D.dsdt-nmda-guidelines]. "not sufficient to fully manage" is too broad a claim. Can I suggest a more positive spin: The Network Management Datastore Architecture (NMDA) defines a new set of datastores that improve visibility into the device, both in terms of the "intended" configurations values and the true operationally "in use" values. Refer to [I-D.ietf-netmod-revised-datastores] for details. Guidelines for moving existing data modules to the NMDA are defined in [I-D.dsdt-nmda-guidelines]. Thanks, Phil From nobody Tue Jun 20 01:29:15 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42590127180 for ; Tue, 20 Jun 2017 01:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMphVgQl3y2k for ; Tue, 20 Jun 2017 01:29:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9CF127735 for ; Tue, 20 Jun 2017 01:29:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPL88281; Tue, 20 Jun 2017 08:29:07 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 20 Jun 2017 09:29:02 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.18]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Tue, 20 Jun 2017 16:28:37 +0800 From: wangzitao To: "Acee Lindem (acee)" , Martin Bjorklund , Lou Berger CC: "netmod@ietf.org" Thread-Topic: [netmod] Some comments on yang tree diagrams Thread-Index: AQHS6Q8Q/1mh09tbr06MMr8vipQSI6Ita82g Date: Tue, 20 Jun 2017 08:28:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.5948DCD4.007B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.18, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ead460ca23d30f2a6ca614aa25dabedc Archived-At: Subject: Re: [netmod] Some comments on yang tree diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 08:29:14 -0000 SGkgQWNlZSwNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBBY2VlIExpbmRl bSAoYWNlZSkgW21haWx0bzphY2VlQGNpc2NvLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTflubQ2 5pyIMTnml6UgMjM6MTcNCuaUtuS7tuS6ujogd2FuZ3ppdGFvOyBNYXJ0aW4gQmpvcmtsdW5kOyBM b3UgQmVyZ2VyDQrmioTpgIE6IG5ldG1vZEBpZXRmLm9yZw0K5Li76aKYOiBSZTogW25ldG1vZF0g U29tZSBjb21tZW50cyBvbiB5YW5nIHRyZWUgZGlhZ3JhbXMNCg0KSGkgTWljaGFlbCwgDQoNCk9u IDYvMTkvMTcsIDM6MjAgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIHdhbmd6aXRhbyINCjxuZXRt b2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygd2FuZ3ppdGFvQGh1YXdlaS5jb20+IHdy b3RlOg0KDQo+SGkgQXV0aG9ycywNCj4NCj5JIGhhdmUgcmVhZCB0aGlzIGRyYWZ0IGFuZCB0aGlu ayBpdCBpcyB2ZXJ5IHVzZWZ1bC4gSG93ZXZlciwgSU1ITywgDQo+dGhlcmUgYXJlIGFsc28gc29t ZXRoaW5nIG5lZWQgdG8gaW1wcm92ZWQuIEZvciBleGFtcGxlOg0KPiMgSW4gc2VjdGlvbjIgVHJl ZSBEaWFncmFtIFN5bnRheCwgaXQgZGVzY3JpYmVzICIgISAgZm9yIGEgcHJlc2VuY2UgDQo+Y29u dGFpbmVyIiwgYnV0IGluIHNvbWUgZHJhZnQvIFJGQyB0aGUgY29udGFpbmVyIG5vdCBiZSBtYXJr ZWQgYnkgIiEiLCANCj5mb3IgZXhhbXBsZSAiaWV0Zi1pbnRlcmZhY2UiIFtSRkM3MjIzXS4NCj4j IEFuZCBJIHN1Z2dlc3QgdG8gaGlnaGxpZ2h0IHRoZSBzeW1ib2wgIi13IiwNCg0KSG93IGRvIHlv dSBoaWdobGlnaHQgYSBzeW1ib2wgaW4gcGxhaW4gQVNDSUkgdGV4dD8NCg0KW01pY2hhZWxdOiBJ IGRvbid0IGtub3csIG1heWJlIGp1c3QgbWFyayBpdCBhcyAiLXdyaXRhYmxlIi4uLg0KDQpUaGFu a3MsDQpBY2VlIA0KDQo+aXQgdXN1YWxseSBhcHBlYXJzIGluICJpbnB1dCIgb2YgUlBDLCBmb3Ig ZXhhbXBsZSAiaWV0Zi15YW5nLXB1c2giDQo+W2RyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2hd DQo+DQo+UGxlYXNlIGNvbnNpZGVyIG15IHN1Z2dlc3Rpb24uDQo+DQo+QmVzdCBSZWdhcmRzIQ0K Pi1NaWNoYWVsDQo+DQo+LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPuWPkeS7tuS6ujogbmV0bW9k IFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCANCj5pbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcNCj7lj5HpgIHml7bpl7Q6IDIwMTflubQ25pyIMTPml6UgMjA6MzQNCj7mlLbk u7bkuro6IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPuaKhOmAgTogbmV0bW9kQGlldGYub3JnDQo+ 5Li76aKYOiBbbmV0bW9kXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUt ZGlhZ3JhbXMtMDAudHh0DQo+DQo+DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KPmRpcmVjdG9yaWVzLg0KPlRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5FVENPTkYgRGF0YSBNb2RlbGluZyBMYW5ndWFn ZSBvZiB0aGUgDQo+SUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFlBTkcgVHJl ZSBEaWFncmFtcw0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTWFydGluIEJqb3JrbHVuZA0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgTG91IEJlcmdlcg0KPglGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMtMDAudHh0DQo+CVBhZ2VzICAg ICAgICAgICA6IDQNCj4JRGF0ZSAgICAgICAgICAgIDogMjAxNy0wNi0xMw0KPg0KPkFic3RyYWN0 Og0KPiAgIFRoaXMgZG9jdW1lbnQgY2FwdHVyZXMgdGhlIGN1cnJlbnQgc3ludGF4IHVzZWQgaW4g WUFORyBtb2R1bGUgVHJlZQ0KPiAgIERpYWdyYW1zLiAgVGhlIHB1cnBvc2Ugb2YgdGhlIGRvY3Vt ZW50IGlzIHRvIHByb3ZpZGUgYSBzaW5nbGUNCj4gICBsb2NhdGlvbiBmb3IgdGhpcyBkZWZpbml0 aW9uLiAgVGhpcyBzeW50YXggbWF5IGJlIHVwZGF0ZWQgZnJvbSB0aW1lDQo+ICAgdG8gdGltZSBi YXNlZCBvbiB0aGUgZXZvbHV0aW9uIG9mIHRoZSBZQU5HIGxhbmd1YWdlLg0KPg0KPg0KPlRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFn cmFtcy8NCj4NCj5UaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6 DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXlhbmctdHJl ZS1kaWFncmFtcy0wMA0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyDQo+YW1zDQo+LTAwDQo+DQo+DQo+UGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2YgDQo+c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IA0KPnRvb2xzLmlldGYub3JnLg0KPg0KPkludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj5mdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0 DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCg0K From nobody Tue Jun 20 04:33:36 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F279D129C6B for ; Tue, 20 Jun 2017 04:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 eC0fB1Qx8kjd for ; Tue, 20 Jun 2017 04:33:32 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0122.outbound.protection.outlook.com [104.47.38.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183731319F6 for ; Tue, 20 Jun 2017 04:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DX3B4dD+Pxq4xD+QI89E5Tk1yNS681EuUfgIHUkpJPw=; b=CR7cTvt3DshGly/HqyE5WK2r123WycMMU4ObUFRf6y6dAnA855fNadjt2t3TKQQc6jRUiwkVSo6tHi+ZKSQBjz//V2VjQ0VAJ2t1XRiiU08QlYTrSgVimvPQNUyJXhazmDM4oddQTSjQyIecSY1qL8s+TpUp8H1s8Myhb5/9juc= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1572.namprd05.prod.outlook.com (10.161.217.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Tue, 20 Jun 2017 11:32:33 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1199.012; Tue, 20 Jun 2017 11:32:33 +0000 From: Kent Watsen To: Phil Shafer CC: Andy Bierman , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt Thread-Index: AQHS6Lgfzle4Y3AsJk+Wlj3X4chBs6Is3PWAgABoGQCAAFtSKw== Date: Tue, 20 Jun 2017 11:32:32 +0000 Message-ID: References: , <201706200605.v5K65g8E000929@idle.juniper.net> In-Reply-To: <201706200605.v5K65g8E000929@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; x-originating-ip: [137.118.194.50] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1572; 7:Bsu5f99dpQvFkZfYNHhnsuLCo3hYI8LFQaoYZIwyCTF15XYqugH1PP57RGeWeIo/xJdsMr1WwdEC+kqF/TbrVVBOPFr6gl8aVPQ5DyDe94WErdkDbT8RTZWA2oFE62hPMrLvqTlRJF/8zPtx6MFVV+Wt6aBm9kbGHQDW4VYzfP9ngvBIxlH/V1QVzyG1zfmq/RrZFD3PZIy/2mHhF0dvngwNFE+pPY4olzXxWj7Uy4Qqdl5qM4F7YOiBelnlLgQWICJnQ6/slgR8ZE6rmayEoiFX9WhYPgdjzSyC2piK/J35dwcXIZTJd7v4XgWrX6tGLPYcsXBWj+ikILp2msfhvJEJKIc1EM8dM6K+1C+AH3EOUI8ZQfUmBb2rf97PUXsolqnIuWdQjTNDOX0kVTK60R7Gf70ZV5qDGar/+kfUvHKbdIKKc6B1o4QJymzIw8+1HQbwFv2bdwPxdG+zhxFC/Oed9k8O6dUlw5QC/kinTt1L8jYDPOhyg71haE9YboZISagLZHvoVV6WtrIo5UQnVd1RkPZIotaXcvWQ0m5Rhn1NqkHacft8nmWSdxlBivPNEo3DTLn99qMqMA/foCMw5LxvCfCt0ZYJ+wHkgmn/3i8o5EVCgeivw5hxCgKFLxjijvFxzByo6m3dVJfiABAym3mu8KbV98UX+rYss3u+qb0j/O2Fslpr2OfPM9LtvVyaS11Cvw4z9B0G1+ttmQn5Dq1F5nu99HtsVMp4Rk57xW6SFtopcil7Jo3Byd/225ZlizehVkww2/gIbQGCRjZX2uQDUH5XOPJlj4fO9vEtJlg= x-ms-office365-filtering-correlation-id: ae2eb8b4-9b73-4580-795c-08d4b7d00aed x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0501MB1572; x-ms-traffictypediagnostic: BN3PR0501MB1572: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1572; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1572; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(39410400002)(39850400002)(39400400002)(3280700002)(122556002)(54906002)(6512007)(6436002)(229853002)(2950100002)(6636002)(99286003)(77096006)(6506006)(6486002)(2906002)(102836003)(6116002)(6862004)(4326008)(5660300001)(83716003)(25786009)(3660700001)(8936002)(81166006)(8676002)(3846002)(82746002)(230783001)(76176999)(2900100001)(54356999)(14454004)(305945005)(189998001)(53936002)(110136004)(6246003)(38730400002)(33656002)(50986999)(478600001)(66066001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1572; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2017 11:32:32.9404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1572 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 11:33:34 -0000 Regarding the suggestion to add this text: > Guidelines for > moving existing data modules to the NMDA are defined in > [I-D.dsdt-nmda-guidelines]. I'm hoping that we do not progress the guidelines doc. Ideally 6087bis can= just state what people should do, without providing a formula for transiti= oning.=20 Kent (any hat)= From nobody Tue Jun 20 04:43:59 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7169D129B1A for ; Tue, 20 Jun 2017 04:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 b5ozYcOGSiiY for ; Tue, 20 Jun 2017 04:43:55 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0132.outbound.protection.outlook.com [104.47.2.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0D1129AF7 for ; Tue, 20 Jun 2017 04:43:54 -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=hundVCfOvtm2a4tnxb5+Zrjt3Yk21vEBJx/6wUxcg64=; b=OfYoiZKs8aL/UBHvFL/N3WJzw7BOG9Vdp4yaathOfYxeNKk+hhiDPnnUNhkv2atpBSv0+tDdA3+av0lJE1KEvYMsIzckWz3NXz8RhoKiMU0h0sfgzPuG4qt6bzj49ngSpKgxc9QWtCd8xwlR9vNb2BTS5441sviBs+BoN4e/8EA= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by DB6PR0701MB3000.eurprd07.prod.outlook.com (2603:10a6:4:73::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Tue, 20 Jun 2017 11:43:51 +0000 Message-ID: <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Phil Shafer" , "Andy Bierman" Cc: References: <201706200605.v5K65g8E000929@idle.juniper.net> Date: Tue, 20 Jun 2017 12:39:55 +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.169.157.161] X-ClientProxiedBy: HE1PR0202CA0028.eurprd02.prod.outlook.com (2603:10a6:3:e4::14) To DB6PR0701MB3000.eurprd07.prod.outlook.com (2603:10a6:4:73::10) X-MS-Office365-Filtering-Correlation-Id: e366ddf8-bcc5-46ff-fa92-08d4b7d19fff X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:DB6PR0701MB3000; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 3:4MyAw4xBj4MGjeh76jnlO70cqwBK3KVvI0iGgyaoxkWs1KJP4NDTmeRNh7atIUWC9wSmW8Rrh9FwTuNgfIgoyy7jcdHhcJhO7dihY2vLhhP85TZx44mWZNC5Q2NqqyVKB/SR8gMIVtAGWRNfmBGryLLWU9qyOsbMRLPFPpGMI87L/9PhVZVLlL6a6okcPgHLn2n1egXa6AZYBHhjsGlMDxslxQlMbmRhJUaz9nX981TphhjEV6JgZDGSPIpH+2gPwhYRpTv+pMXoWbu4SUHSau4VSJvSkaf1VQuPZCcWYu2hg/Ham+0iGek+VI3IdHQ1DXvqphWr+0SVqg3Y8Te2hA==; 25:3ivaFm6TmE/qQebWH0CZo9TGGtL218fcMLqi2jQxel/XecF7GyKCOU+AbOghI0617rPtrOKTkgBj0oL/J/6iHSO7fCxIwVq25aajSVIyisGnlE80CJS4mD2ONzU/32uw0TxKpsV/bm3qkg/nr5hmeNa7Vi7EcbpO4MfP0teh3zCj8ZQlYjsOIezjPDBHvwekLq2hXRCCvAwq6IUOvYJGkZYEaKYpcdWRI2lidksdojLp1h6jeGukQUeeeps4338U7Nhn176wHHzq01gxuj2qNpV9hOsZYT1VpBB7QXfEbn6VTiB3yj0a9yZe5bTuTaTshsejI1dG0UvAFVpsqaXiDjMUv7rHbQrni+xyqvKwhe0z07rDwLtZkqVcs7iTN4Br/7iafU0StlFllNc72snwMNwXmP5MFM/4FqjkRRMcjOG91dPklXeBmJJk4cwPMEVy8dWPuqVAotbzvq/ctGNBso1TZUTJ+TnxbqNggqYX6oE= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB6PR0701MB3000: X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 31:M44vgID1m0tZLHcCbUDd7E4guyMy/UhGukaCf5aYpyus36+yUjLt/7Ji3129c9Ouf2u+bFCZeES4j+fQMzbZk9LVyb68gm3MEskcF9nJpwYMWblx9+KlliakogO7Fro/4rbiiBKK9S58Nhw0wUu16+qD4b0+YEZwJy2/hvHoY4g8cBRLwM8CMnI9YKhQbxfscj/DB7uNT2+r7NCfbvwxltvn9i9lUhH97yEzrybC7bqX9rPOK8f0OrdcTXgUAWx5XNHuhyqZ3gTISoBBYI3vsA==; 20:QU8OiEON57bhDW7ugWG1I/EuagUmIzqYWEcVA22OMQn5c8K5sNCWK+pUUq1q9Wq1AnDVLOMvJNOlCHm9q7s1fGfW2TAitwPx2tMnIRtAggjEPZ1q/3VJCbAKZN6CCi4e67GMtb1Xn7vR6waST9YUn1IntQFKSqzNRsbmOhbR4rU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB3000; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB3000; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB3000; 4:y2WdxDGGhxOwsPQatI3Qy5RqMDyLmhT3z2PFgR?= =?iso-8859-1?Q?9Q7abmwrAZvFG0pmzBMBXAYwPbGk2m4SA6ezpTzSvrmPF+x6QdgTyI+hsl?= =?iso-8859-1?Q?q99K72I/ZqBTx0fEOWHA4KTpuxMuobyVFs6mybuLs2VLt+A1t2JANBXMTD?= =?iso-8859-1?Q?W4Y8yeyOfYvmdK3cTHAbQ44km/aUAUtM/PutD49jIbAeMMYpJWv3GZtNtF?= =?iso-8859-1?Q?2GrVww3TZIbn87HRFLmH7jeKkFccJR8WM4LWgTmM+Y2FH4l5X/eCoMwnZW?= =?iso-8859-1?Q?5R9EXQ03D9mJk4xWv18kL6Y0T0fscqxVib0ppfcu+M/WDIMWLFptN9m/2F?= =?iso-8859-1?Q?uObbBpyIbzQZntEugZTu1ixGJ6KyGE+aOKkM2IF5N9QdrcNo4/6l4/uXqe?= =?iso-8859-1?Q?BnSoCtvLl0GQFcThJEe4nyRSiefkaZLVPeynFHRZ188WWVY0r7rt/znK5I?= =?iso-8859-1?Q?12QLNMZw0HYtyCATCaeG/Bs7pvLLjbG0FQvG29TDvkQIyWgIJlJCHAH7Op?= =?iso-8859-1?Q?7o+huSZESNKSwjVhX1Q9NVnKBh1TPs8+fDsrcmJrTuIZurXvBZQ486oHrh?= =?iso-8859-1?Q?nbvvIpRn3jGnzWtabsM5to5PCLoR7nxKdUv5jq+ysBZzbZ4lhuXDd378wz?= =?iso-8859-1?Q?RSyGRbZn9Gl/RT1WLfh0bSTY3Mg3UL96jFgcUtaBpFKHrNdvYjmY+efroB?= =?iso-8859-1?Q?8zMfj2i50uhhICF7+8CVKqT22tCPbW9WSNh3zk/7mVdN1PHrmKpI2knRfn?= =?iso-8859-1?Q?5DH/Kan9m+lnWr6W3B0ZrlgK3jq9qxRgbhr3DTPU7LbSFzFHJzF/4d6/r9?= =?iso-8859-1?Q?LN83ZxyhZ75o8tdJzumAFmGia19EWjcQh7GYmk3UeLCahI39Ax+m9kHCsv?= =?iso-8859-1?Q?j2MJVRPM1DBXLbt2+y8yG2h8S+99pS+mQ8m6GfPpSm4oqf8DU8+BnE3dlG?= =?iso-8859-1?Q?1S1tnrobg0zKNT6Djeb3a5Rn2tSkRl/Ur2LwybO3eIy1orXMHNGqlxsWS5?= =?iso-8859-1?Q?2ebYC2gdcfRXsSrwq9EPWvrtMq5OCWjLKBE2Gqw1K2ZaX/TbpcIqGGdOHv?= =?iso-8859-1?Q?gXT72yuzpmbUfONM3cXKQHE+J+Dj5DFv1nc/9tJjhM2yndSQ/HRXxCsbaV?= =?iso-8859-1?Q?imciVy/p4bf/N9x1wz2QzLQ+qTW7HrN8UKWsWWEGjJ40XQe++b77yCcp84?= =?iso-8859-1?Q?TRhk91oe8nPDD8EKEtaary6PJ0MrlOubArlGWSCbAAzqVV0wRf/FZLU=3D?= X-Forefront-PRVS: 03449D5DD1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39860400002)(39410400002)(39850400002)(39840400002)(39450400003)(39400400002)(377454003)(13464003)(230700001)(2906002)(50986999)(3846002)(305945005)(966005)(478600001)(33646002)(8666007)(6306002)(47776003)(84392002)(6246003)(5660300001)(9686003)(81816999)(62236002)(38730400002)(81686999)(44716002)(189998001)(76176999)(53936002)(66066001)(230783001)(42186005)(8676002)(81166006)(50226002)(6116002)(6496005)(61296003)(4720700003)(25786009)(229853002)(23756003)(44736005)(4326008)(6486002)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB3000; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB3000; 23:70yeOqDSu2uGV/++Uz/9bN394/OK/dM8HZn5r?= =?iso-8859-1?Q?oukWazun1oLyzOFJQ45CmrpfRixxrkXbrsm5gyVJ6gvhTw0EtCMEw6+FgC?= =?iso-8859-1?Q?gEYkQuqnqz21wxuOIb6H7u6AU5Aav5q+bDqERoAvf49y/0D9ZT95n/2pZu?= =?iso-8859-1?Q?aqwzBWA/iRmRXq+ZRiEs8t1ILSEWfPC4z/B+Os7Vy0PkvmH4j9u+l18Z7B?= =?iso-8859-1?Q?eENcFbROaLhJTcjqFl1jdLyKbklMxrbDFMYKLqhsCDDFs3RZzixVHiD9LS?= =?iso-8859-1?Q?81viz/krUYWmDSY7Iys1xJKqjcIhWowyBLv80jey0ZyT745YWoyMXGxiXX?= =?iso-8859-1?Q?zhjTgTupCIoCPPq1LhHgnnz9E4/FUATY+w5AAcZUZNKFqq8vWIUJapQnPT?= =?iso-8859-1?Q?0PCRRf6X4zokukqL+ce9P+8b3iMEDCeI9H9XVvqwVc4QWNv54zWf0JKdM5?= =?iso-8859-1?Q?BqSjbWlNnmuMtZi2OTIZklPUGe0AXiWjxDF+6NJDcq5jgTxwGm1vkyeAvH?= =?iso-8859-1?Q?UqUmQ7Gr+jh9t5RcmRpmuTD1RTUA25hk2dNYicInu4pnls0qKUMwmBh3dx?= =?iso-8859-1?Q?KM71V8P51iTkPcT5CtRilp6u0cv8yHfVlNXho032KDbcc+QY8Gv32nWvc/?= =?iso-8859-1?Q?1ctK/CTuJ8HK+N9zLo9mND+BcpNZ8cxkAhUHtxlvWMoZDsE0RiiexxEnDY?= =?iso-8859-1?Q?TqG4EYByyglR7+rvPlOrmq8Y5lEw6eryHMvAEED+/kFW4bS/ZUfTRZBhhO?= =?iso-8859-1?Q?YlpA0VN0n0QzOLmyk5MDJwUe+TgAABgmYy025CmebuthIbkoHltsMI2U9X?= =?iso-8859-1?Q?Ss/yNrpDkFj+TCy4TC/GWMIgZm2g3bZVq4AG5a0apL5JHekRoYKXrIfBw0?= =?iso-8859-1?Q?zqch0U2oBgxhhtfW81jbF13iDO59CM5KgySrHEc/J3mPYslR/qM6smJhxi?= =?iso-8859-1?Q?uROl+4dpASmMZe1IRYuUq5//EmppYuSC6yexszQ6POD9hHZoQaDdvKgiQh?= =?iso-8859-1?Q?32hDNnzA36ZtJTfwjTQVhMlfJ1T6Wi+wWb8DnUvy+jN/93VJzzeumbLNzO?= =?iso-8859-1?Q?6SKM3I24XEr1Dljhr8Fo3E/dMh8XUBBg7l/t5MDYQvdyr6p915jHWygYDW?= =?iso-8859-1?Q?ql9SiOcYOwybvcWVnZU1Gl+Gn5zUwNB9FruaFbfV9djivojQ01s8AJG4Tg?= =?iso-8859-1?Q?LLdxFQ1c9VMszNTr9DaEpr+y4xPGjQz7MqXWPSr5uQ4H0BlMKwbKxQ3FnQ?= =?iso-8859-1?Q?Yic6X7AANgSi+SCwt6Wpsx3nPMX7kevgkvIjK4XZw=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB3000; 6:wfLMp/Vdssc+M64Q5rc75ABmCx8DtZntpxpDvo?= =?iso-8859-1?Q?iCIosvHOjmEODsxrBmSvWDkwax2oPo2pnYerGaq4pm4sKZbzOLdRAb+5hH?= =?iso-8859-1?Q?6KhkBe2GOiKdW/ncwF36l82AJjIYEvxHvDkyElIWCxfxFOdpFsXBlCLL3w?= =?iso-8859-1?Q?k4dDC1TiDgHc+nQIAni0icI9xDOY5nU6rqqQNBI4QYd53EubFnO8J+mm2k?= =?iso-8859-1?Q?Xu4BS8taUz4L+1C9YGsEYHD3h1D1ppadtG6PeO3dMuhAbXgY+JN/A3fwtx?= =?iso-8859-1?Q?kIkSVmdUiiCB9tq86yV0obf+vwUbm9PlnxSZfy3Z5uTZnP+kesehQK5+7Z?= =?iso-8859-1?Q?xwtSw2rPAjaz4hTnAi2ap3G9mr5pSD4L4nEBlfRuh1dr/xrjKwGpJ+o+OZ?= =?iso-8859-1?Q?k7vHi97hRx/OyoByVZNLYhoUBkMXHXwpMTcg4/Bt+AXyHhHqwHzcm/ctae?= =?iso-8859-1?Q?M6iAuqdFt++Fwq1/Uep5rTxArijNNyJCEei5WG3D/zusV4pTq8XOVGwZ7v?= =?iso-8859-1?Q?W+H8B1ZLuTESAAwbjA4zcgVLYq/D0UVht13xjeFR5qpv0nM2Vb/ZlzC4wR?= =?iso-8859-1?Q?BR09VOgKQckcUGk8HO6j5TBJBURfMvTXvKhFQdMNVsA7wvqhKYjMKUTW68?= =?iso-8859-1?Q?Ps7zFbCXPthQms8lKJ0WsJRNZTkFu+U4bIWLiGqomTVo5aCjqMTiC0TU3H?= =?iso-8859-1?Q?CtXd6iR+kuIzkA1jwMhAOFCnPH6Z/yMPFWczXqQA9MPXSNCIH/b/+GxGd6?= =?iso-8859-1?Q?tCwnRRd/1Ic0c+1PUCES6Hfn7AMVabsIvMZBH0gtUAfxYi9luum6hEvjar?= =?iso-8859-1?Q?JW0RKL84XHcwD15y2PlrrCJD7TX3G+OUbIIhp8kvvKtcMeXcOLIk0agrzs?= =?iso-8859-1?Q?WLZlKtmFdiHgJdTEDi8crlM1wfSJLRowsdKJSJj7zMqiRD3pbqi3UY2hut?= =?iso-8859-1?Q?sUjqyn8X7eqc+iIvBRlSaqIHzrs86NAUvA3rp7+lR/PGfbrhVtznVCYMtB?= =?iso-8859-1?Q?g+U1n9aHtdAO/4eAL/vo3FlLhMvWX+FH4jm0c=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 5:t899ioR+vXv5XI6Bue/NIFmiiMburr7wUZVxHoeKGB06wEvLzJfXtmRmxxjc5/7RAqOrT/GdwaoKF4E3FpD7LQfVC5skFKWL1LRWmx/j9h/d4HnmMzMCsUxC3fNvY2Zy96w7hFXZmW4JkCyGNK4qLMFzAorUm7XtIbD3Ah4KClBIi3SKFNrfeNsZgKh9+GP4CEgjWtoSYNLSmwoHAbeVVL59+fwhic1ntHwD3gl18dfdq5SYBZx1pHrPEbY1jCrAqv67CNW/8LtK8CMkEuDh1PzILDo4KzgCoCD9rsTFOFuVW3hkATi+NwiUwAl5Lj6H8/Dgp6jOIUhkSEH5zVadP0ulh2Ft2pUt0ASQO8R3lQdoWjzKkUtX1AmbZVdFZuTZyCiLVblIzUc7VL1p9IwWUiWocE3hR9MCXnqQb8/rx0vcgEITZ3oE4pX63BUO7wYfIGXz3zXkry3WBCOLcJbU8DcopEqXQH3V2IKBGuQi4p3BGPhdlr9j8+gKMWssxFNz; 24:5T7yGDKbRvzoYmSuGpYmCLKhh7JPckF6/wy+eZshgsflGdHnEdbGdL/IUgEmhHqawkc31Y1rKwbO78GrdzX2Vkh1AGIAAesEdcl4aE4xAcc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 7:xXkICkZS3i800z2x2gTpvHjZOXlUdCWoMRVkD0q6U6PUhq8JYiaPyU7X+IAqP1RUZzE3+UaHu7WI9POwT6YbCeU0fdp0HPW5343eyR++Rar4rU8Ivvv7px9JSigSEaqxghs3T9yvTObq/Qo+DGgNL2AvWlDZX0XyWji+kroDdQfowIyLkZhGx7cpXWJLHfNxXyj3QW4YJBglycA2x7ezas6Lf8k0VX2o4oLrCV3dNAPVFTCt/fjx6oBzlA0jYEacVkm/lG4/lL4EHn8SVifHAxCFp0TRkWbq5RCjKs8pxwm7b2hnT7Wdi1XbLLYJ3TOTUTXX2Wz6tdhZJWHBwUOJXiJhQfhprohzTgbUSMIT5zVlXN+m+QawkHN5ihhhtGmDIxcK+NJgprEU7ahJXcVLHw5MTkblmVGwqR3uZjI4hhBo7742HCkwrGk434iXdpwSXFmsAYyRtpJgOuB8T/g0Em6H4e7jtDnMub9hcysjSzzNNsKUcTDk4bi+2u0c/wyLSOUgspLTIwJoY4J91B9BhbeEXhQTjBjo9OeCMNLo+nKPKNrL9a//7V9OFd1xIzullwaVCZ85aYRJgjDqZtb0FpTJ3Rsv4kVHgpVlu9fTeGmYyGTukY0obWJRZRokfQGklWw+y+/SH4d8lj1zOCZ6cfx6KDCMUbnB62LIzHVTFJ/MbMg8k7kfwKhhd8JEJ0KzpbskqtIuZVpCnNtpEkpcawC46rO8rf+RESaa/5k6/Rv3Ueh9ouqNSM0X0Gtcw/Qz1l5gQjt6mpFPcn6BmM3ubCBuJs1gyQMEio5AeMetT/Q= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2017 11:43:51.7264 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB3000 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 11:43:58 -0000 --- Original Message ----- From: "Phil Shafer" To: "Andy Bierman" Cc: Sent: Tuesday, June 20, 2017 7:05 AM > Andy Bierman writes: > >This draft addresses all remaining open issues, include the rewrite of the > >opstate section. > > >>In YANG, any data that has a "config" statement value of "false" > >>could be considered operational data. The relationship between > >>configuration (i.e., "config" statement has a value of "true") and > >>operational data can be complex. > > The NMDA draft includes the following in its terminology section: > > - configuration: Data that determines how a device behaves. This > data is modeled in YANG using "config true" nodes. Configuration > can originate from different sources. > > - operational state: The combination of applied configuration and > system state. > > It would be nice to use matching terms, either by importing the > NMDA terms directly, or by mimicing them in this draft. If your > "operational data" means "config false" and NMDA's "operational state" > means both config true and config false, readers will be confused. Phil Well, it would if the definitions in NMDA brought clarity but I think the opposite. 'Data that determines how a device behaves' seems clear until you read on and find that this excludes data learnt from the system or data learnt from routing protocols. I find the idea that the behaviour of a device is not determined by routing protocols or a hot-plugged card an odd one. This definition is rather different to that in NETCONF and seems unlikely to bring clarity so I think it would be a mistake to incorporate it in rfc6087bis.. Tom Petch > Also you say "operational state and other data such as statistics" > which inconsisent. Under either set of terms, statistics are > part of operational state. > > >>The original set of datastores defined in NETCONF (i.e., candidate, > >>unning, and startup) are not sufficient to fully manage a device > >>ith multiple sources of configuration data. In additional, a > >>separate datastore is needed to store operational state and other > >>data such as statistics. Refer to > >>[I-D.ietf-netmod-revised-datastores] for details on this new "revised > >>datastore" architecture. Guidelines for usage of the new datastores > >>(including the operational datastore) is defined in > >>[I-D.dsdt-nmda-guidelines]. > > "not sufficient to fully manage" is too broad a claim. Can I suggest > a more positive spin: > > The Network Management Datastore Architecture (NMDA) defines a > new set of datastores that improve visibility into the device, > both in terms of the "intended" configurations values and the > true operationally "in use" values. Refer to > [I-D.ietf-netmod-revised-datastores] for details. Guidelines for > moving existing data modules to the NMDA are defined in > [I-D.dsdt-nmda-guidelines]. > > Thanks, > Phil > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jun 20 05:13:18 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A539912EB3A for ; Tue, 20 Jun 2017 05:13:16 -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, RP_MATCHES_RCVD=-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 x8YjnxgEM0ZC for ; Tue, 20 Jun 2017 05:13:13 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D888012EA53 for ; Tue, 20 Jun 2017 05:11:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AFC41F68; Tue, 20 Jun 2017 14:11:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id oqz9wOA9v60C; Tue, 20 Jun 2017 14:11:35 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 20 Jun 2017 14:11:36 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F01B20094; Tue, 20 Jun 2017 14:11:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id m6SVX-qyRXik; Tue, 20 Jun 2017 14:11:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1911C20091; Tue, 20 Jun 2017 14:11:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E73A03FCACFC; Tue, 20 Jun 2017 14:11:35 +0200 (CEST) Date: Tue, 20 Jun 2017 14:11:35 +0200 From: Juergen Schoenwaelder To: "t.petch" Cc: Phil Shafer , Andy Bierman , netmod@ietf.org Message-ID: <20170620121135.GA1924@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "t.petch" , Phil Shafer , Andy Bierman , netmod@ietf.org References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 12:13:17 -0000 On Tue, Jun 20, 2017 at 12:39:55PM +0100, t.petch wrote: > --- Original Message ----- > From: "Phil Shafer" > To: "Andy Bierman" > Cc: > Sent: Tuesday, June 20, 2017 7:05 AM > > > Andy Bierman writes: > > >This draft addresses all remaining open issues, include the rewrite > of the > > >opstate section. > > > > >>In YANG, any data that has a "config" statement value of "false" > > >>could be considered operational data. The relationship between > > >>configuration (i.e., "config" statement has a value of "true") and > > >>operational data can be complex. > > > > The NMDA draft includes the following in its terminology section: > > > > - configuration: Data that determines how a device behaves. This > > data is modeled in YANG using "config true" nodes. Configuration > > can originate from different sources. > > > > - operational state: The combination of applied configuration and > > system state. > > > > It would be nice to use matching terms, either by importing the > > NMDA terms directly, or by mimicing them in this draft. If your > > "operational data" means "config false" and NMDA's "operational state" > > means both config true and config false, readers will be confused. > > Phil > > Well, it would if the definitions in NMDA brought clarity but I think > the opposite. > > 'Data that determines how a device behaves' seems clear until you read > on and find that this excludes data learnt from the system or data > learnt from routing protocols. > > I find the idea that the behaviour of a device is not determined by > routing protocols or a hot-plugged card an odd one. > > This definition is rather different to that in NETCONF and seems > unlikely to bring clarity so I think it would be a mistake to > incorporate it in rfc6087bis.. > RFC 6087 (and RFC 6087bis) is about YANG models, not about NETCONF and not about routing protocols or any other control plane mechanisms. If the terms in the NMDA are not good, start a thread about it; try to improve them if you can. I do not see that using different terms in the YANG related specifications is less confusing. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 20 05:35:41 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB51129C12 for ; Tue, 20 Jun 2017 05:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zezreJW7cuID for ; Tue, 20 Jun 2017 05:35:38 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4390C12EAFA for ; Tue, 20 Jun 2017 05:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3898; q=dns/txt; s=iport; t=1497962107; x=1499171707; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=notZarAulltFBcpd5FSZlKGrEvBZumoUU0xxynX9YFk=; b=bW0G8ZmINSLSJM18WrfxA+hYWvliewPAT/QCmlZk8uGNCXPe3pz0KLp8 FVBFj0CDC0Pwz6VcFGAfF/awkM1BSh0gWL2JlbDo08VZZZtPuzrQdt7fx OruniL3qoir5mZJag/7Jb2W/0UK3Z+2MNBbKSV5+Wk9CEbl73sal6+Fvb Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAACEFUlZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqBDY4Ec5ELlXiCESELhS5KAoMfGAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgEBATY2BAcMBAsSAwECLiciDgYBDAYCAQGKIAgQrlGLWgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhmyBYCuCeYpcAQSeYZNhggiFSINLI4ZQjESIRh84gQowIQg?= =?us-ascii?q?bFUmHED82iVkBAQE?= X-IronPort-AV: E=Sophos;i="5.39,364,1493683200"; d="scan'208";a="695280693" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2017 12:35:05 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v5KCZ4dn009519; Tue, 20 Jun 2017 12:35:05 GMT To: "t.petch" , Phil Shafer , Andy Bierman References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> Cc: netmod@ietf.org From: Robert Wilton Message-ID: Date: Tue, 20 Jun 2017 13:35:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 12:35:41 -0000 Hi Tom, On 20/06/2017 12:39, t.petch wrote: > --- Original Message ----- > From: "Phil Shafer" > To: "Andy Bierman" > Cc: > Sent: Tuesday, June 20, 2017 7:05 AM > >> Andy Bierman writes: >>> This draft addresses all remaining open issues, include the rewrite > of the >>> opstate section. >>>> In YANG, any data that has a "config" statement value of "false" >>>> could be considered operational data. The relationship between >>>> configuration (i.e., "config" statement has a value of "true") and >>>> operational data can be complex. >> The NMDA draft includes the following in its terminology section: >> >> - configuration: Data that determines how a device behaves. This >> data is modeled in YANG using "config true" nodes. Configuration >> can originate from different sources. >> >> - operational state: The combination of applied configuration and >> system state. >> >> It would be nice to use matching terms, either by importing the >> NMDA terms directly, or by mimicing them in this draft. If your >> "operational data" means "config false" and NMDA's "operational state" >> means both config true and config false, readers will be confused. > Phil > > Well, it would if the definitions in NMDA brought clarity but I think > the opposite. > > 'Data that determines how a device behaves' seems clear until you read > on and find that this excludes data learnt from the system or data > learnt from routing protocols. Please can you clarify. The text that you are quoting above is from the NMDA definition of "configuration". Data learned from the system or routing protocols (for YANG config true nodes) would be classified as "system configuration" or "learned configuration", which are sub categories of "configuration", and hence are not excluded from the more general definition of "configuration". Thanks, Rob > > I find the idea that the behaviour of a device is not determined by > routing protocols or a hot-plugged card an odd one. > > This definition is rather different to that in NETCONF and seems > unlikely to bring clarity so I think it would be a mistake to > incorporate it in rfc6087bis.. > > Tom Petch > > >> Also you say "operational state and other data such as statistics" >> which inconsisent. Under either set of terms, statistics are >> part of operational state. >> >>>> The original set of datastores defined in NETCONF (i.e., candidate, >>>> unning, and startup) are not sufficient to fully manage a device >>>> ith multiple sources of configuration data. In additional, a >>>> separate datastore is needed to store operational state and other >>>> data such as statistics. Refer to >>>> [I-D.ietf-netmod-revised-datastores] for details on this new > "revised >>>> datastore" architecture. Guidelines for usage of the new datastores >>>> (including the operational datastore) is defined in >>>> [I-D.dsdt-nmda-guidelines]. >> "not sufficient to fully manage" is too broad a claim. Can I suggest >> a more positive spin: >> >> The Network Management Datastore Architecture (NMDA) defines a >> new set of datastores that improve visibility into the device, >> both in terms of the "intended" configurations values and the >> true operationally "in use" values. Refer to >> [I-D.ietf-netmod-revised-datastores] for details. Guidelines for >> moving existing data modules to the NMDA are defined in >> [I-D.dsdt-nmda-guidelines]. >> >> Thanks, >> Phil >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Jun 20 07:27:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B02B12ECAF for ; Tue, 20 Jun 2017 07:27:30 -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, HTML_MESSAGE=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=yumaworks-com.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 rxH_G8CNH0tl for ; Tue, 20 Jun 2017 07:27:28 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 0A08212EC87 for ; Tue, 20 Jun 2017 07:27:27 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id y25so54076952wrd.2 for ; Tue, 20 Jun 2017 07:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gqg3yeK602FUlMX+8iEMEdXEEGeU5MkoopM5IGjywGA=; b=Qr4MKL4L3DIzOWyhBFBco5dXTDHjfdve0u5oFtUJr7mQRcA9oWzB7of/0oAPul5GJM J8q8TkBY7U61ajNs/mW7EZa6LJWekdarRlRCWTZ8qq4LUZmfL9kLaJWpX9tYlSpjdm7l s7JxOvuRYxAHGQxYvR/Qa607T4we0jRrKoKxi2n8rx2Dw0VsIEvDjEwFdOdkKhL9zofh P1xieQ71vlex09d0P8O5k2Hc7QcMhVpdGUknasn86EY64S9re5zz0wdMQUuf8HjPr98j uSCpw7ze3IRCLvqFw1WI8kaQpxsNelfxFTRShvrc9J6KG2K4A8yKGDw2Dt0dOIzZzCLM uhHg== 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; bh=gqg3yeK602FUlMX+8iEMEdXEEGeU5MkoopM5IGjywGA=; b=qJAH7xnCHb3OVUZ4Ncdsb4mIWDKaM7rnKqd3LV/zNXdUSeqROTPQagXrD2WN5qp/Iw +gO2Woz5e3+vINVWbzB1robUnNbc7B9ziWipiPwMojPVC8nYP5czJBo8Ak4+6wfnlOm5 8IVCvML4S889zR5OQjYV0WAELoPRo5Vzrj4gycXTlhwXxIODjTeVzoHUQXwcRiBF3KbA IMH57jPJ07q28IIr3luv6GR2EkP+2crl8DbMneGlZFqmYzFWme3p9nhoUpp659zVC8G9 Rm8ZMeU/YwTxb09dI6UwOyV5jp3eYDhzQFb5PE9PlgMAM2SIaaeFF2kzveI31XmBqFJj URBQ== X-Gm-Message-State: AKS2vOz09KHbCrC4djpGddudFOeiDFvPrTG5mOCQL/UxGxC+m1cK6zcc JZA1l3CpSoXJyN1vGuJgv1ZK8R8dk/6B X-Received: by 10.28.210.15 with SMTP id j15mr3237442wmg.48.1497968846470; Tue, 20 Jun 2017 07:27:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Tue, 20 Jun 2017 07:27:25 -0700 (PDT) In-Reply-To: References: <201706200605.v5K65g8E000929@idle.juniper.net> From: Andy Bierman Date: Tue, 20 Jun 2017 07:27:25 -0700 Message-ID: To: Kent Watsen Cc: Phil Shafer , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114722d8fa97890552650c14" Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 14:27:30 -0000 --001a114722d8fa97890552650c14 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 20, 2017 at 4:32 AM, Kent Watsen wrote: > > Regarding the suggestion to add this text: > > > Guidelines for > > moving existing data modules to the NMDA are defined in > > [I-D.dsdt-nmda-guidelines]. > > I'm hoping that we do not progress the guidelines doc. Ideally 6087bis > can just state what people should do, without providing a formula for > transitioning. > > I thought 6087bis is supposed to point people to the NMDA guidelines. That is why 6087bis has been held back for so long, even though it was supposed to be published with YANG 1.1. We waste a lot of time refactoring drafts and re-reviewing them. IMO the RD guidelines should be in the RD draft. > Kent (any hat) Andy --001a114722d8fa97890552650c14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 20, 2017 at 4:32 AM, Kent Watsen <kwatsen@juniper.net> wrote:

Regarding the suggestion to add this text:

> Guidelines for
>=C2=A0 moving existing data modules to the NMDA are defined in
>=C2=A0 [I-D.dsdt-nmda-guidelines].

I'm hoping that we do not progress the guidelines doc.=C2=A0 Ideally 60= 87bis can just state what people should do, without providing a formula for= transitioning.


I thought 6087bis is supposed to point= people to the NMDA guidelines.
That is why 6087bis has been held back f= or so long, even though it was
supposed to be published with YANG= 1.1.

We waste a lot of time refactoring drafts an= d re-reviewing them.
IMO the RD guidelines should be in the RD dr= aft.


=C2=A0
Kent (any hat)

Andy<= /div>

--001a114722d8fa97890552650c14-- From nobody Tue Jun 20 08:25:11 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED531314F6 for ; Tue, 20 Jun 2017 08:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 Nb32Ns5e1toE for ; Tue, 20 Jun 2017 08:25:04 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0091.outbound.protection.outlook.com [104.47.36.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824B8131493 for ; Tue, 20 Jun 2017 08:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UBm8oidmCxiXVow6lmurMfdgVIcOfAZeTqTiahHSq+A=; b=k3Xx+1y0SO4pESyP+ZXdYPR86xmt/akJRrkBKzF3tgLCEMeYTvCyGryBFDKC0Zctz1SBZ1yZOJhTbVZSBZxme6j4IEvLIMglw8u9ElLaeS0SH//RJA6pRI6YjVniYWwJCqu9W0r8Pa3P+zkGCLG6XI4H+DjEgmzOj6KaHbs+iao= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1457.namprd05.prod.outlook.com (10.160.117.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Tue, 20 Jun 2017 15:20:38 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1199.012; Tue, 20 Jun 2017 15:20:38 +0000 From: Kent Watsen To: Andy Bierman CC: Phil Shafer , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt Thread-Index: AQHS6Lgfzle4Y3AsJk+Wlj3X4chBs6Is3PWAgABoGQCAAFtSK4AAMNyA///LywA= Date: Tue, 20 Jun 2017 15:20:38 +0000 Message-ID: <42BAB734-C9B5-412A-8E53-E074F198654A@juniper.net> References: <201706200605.v5K65g8E000929@idle.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1457; 7:hYB/Mpyq3MJSnK6LzEcD7ehiZdFqktP3Db7inNcn6+x/ukf/DQp/bunU8d+I9j4D4ny0RTkXv5OhbMFVc2ktUmVT2bn/SgB2fhUzGBt/eG4BEIYHF+AqB6D5AHbbeQJgZUCzz4knqFYPAQNl4xQnq3+4N9+a/mhLGcytdhSSBNw5LAx34XhfA6Hl+jj+Xz2GDuWmd7rDn3i0KbeTg+jzdcHMG/LbGJnYxjsJWpKc07r7mHfRExCxOcFh+dpPZayChWgguF2J0WwKlcF5fv1NgM/kmaoOFKTg7W78P7hus49M2shSSf4m5avP9Bih6gXwr0V82NfP4vwrs5Tn02DbT8hfN5CvvFCFR0KTTaig6A0ueY39as5Gz9FZVk+Tfso0LBMvvOYgDNytC1+3LMJPPNePf/i09ZnMniRITwRjjHh+m6OCeHBYh9kvyRs2q425Zvo5a7f10vUoaK92SXHycF913nYufeDybL685bUw4G/hGgRyJGVDZbes9ByuEZSEA21JeLcLlO470ucE+rSYlVSjpUGoAWAUYW4rZRZRf2iQHZ7yxlgAWlaWobf+YFOjayRW/A0KkXAX9F3qumHDXhJVtgUMD4EKQyO/TIrrHQhOsnoY2x5pD35niixF3gMqIfEMfWyfyr50oKmJUhnsrNV8MmmGzUOL587t8Kpv8Z6X0KFGOKXU0QzCYutHdrP2B3IeLVrjxwmN6QLZKyY3idSzup1sXKiNm6EEGPsjMHeXqBbZkbu3or0nqRT/LXNACU90goH506UFN4eGxAyneTGWDyrKfEe3mGkGDRt1hx0= x-ms-office365-filtering-correlation-id: 7444a900-69c6-4464-405d-08d4b7efe7f6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(300000502055)(300135100095)(22001)(2017030254075)(300000503055)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:BN3PR0501MB1457; x-ms-traffictypediagnostic: BN3PR0501MB1457: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1457; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1457; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39400400002)(39410400002)(39850400002)(39450400003)(39840400002)(54896002)(53936002)(6306002)(99286003)(54906002)(6512007)(36756003)(6486002)(5660300001)(33656002)(4326008)(6436002)(230783001)(54356999)(50986999)(76176999)(229853002)(77096006)(3660700001)(3280700002)(2906002)(93886004)(6506006)(102836003)(3846002)(6116002)(66066001)(7736002)(6916009)(2950100002)(2900100001)(6246003)(110136004)(81166006)(122556002)(8676002)(86362001)(478600001)(83506001)(8936002)(83716003)(14454004)(4001350100001)(966005)(189998001)(82746002)(38730400002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1457; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_42BAB734C9B5412A8E53E074F198654Ajunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2017 15:20:38.2043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1457 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 15:25:10 -0000 --_000_42BAB734C9B5412A8E53E074F198654Ajunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNClJlZ2FyZGluZyB0aGUgc3VnZ2VzdGlvbiB0byBhZGQgdGhpcyB0ZXh0Og0KDQo+IEd1aWRl bGluZXMgZm9yDQo+ICBtb3ZpbmcgZXhpc3RpbmcgZGF0YSBtb2R1bGVzIHRvIHRoZSBOTURBIGFy ZSBkZWZpbmVkIGluDQo+ICBbSS1ELmRzZHQtbm1kYS1ndWlkZWxpbmVzXS4NCg0KSSdtIGhvcGlu ZyB0aGF0IHdlIGRvIG5vdCBwcm9ncmVzcyB0aGUgZ3VpZGVsaW5lcyBkb2MuICBJZGVhbGx5IDYw ODdiaXMgY2FuIGp1c3Qgc3RhdGUgd2hhdCBwZW9wbGUgc2hvdWxkIGRvLCB3aXRob3V0IHByb3Zp ZGluZyBhIGZvcm11bGEgZm9yIHRyYW5zaXRpb25pbmcuDQoNCkkgdGhvdWdodCA2MDg3YmlzIGlz IHN1cHBvc2VkIHRvIHBvaW50IHBlb3BsZSB0byB0aGUgTk1EQSBndWlkZWxpbmVzLg0KVGhhdCBp cyB3aHkgNjA4N2JpcyBoYXMgYmVlbiBoZWxkIGJhY2sgZm9yIHNvIGxvbmcsIGV2ZW4gdGhvdWdo IGl0IHdhcw0Kc3VwcG9zZWQgdG8gYmUgcHVibGlzaGVkIHdpdGggWUFORyAxLjEuDQoNCldlIHdh c3RlIGEgbG90IG9mIHRpbWUgcmVmYWN0b3JpbmcgZHJhZnRzIGFuZCByZS1yZXZpZXdpbmcgdGhl bS4NCklNTyB0aGUgUkQgZ3VpZGVsaW5lcyBzaG91bGQgYmUgaW4gdGhlIFJEIGRyYWZ0Lg0KDQoN CjxLRU5UPiBJIHRob3VnaHQgdGhhdCB0aGlzIHdhcyBzZXR0bGVkIGJlZm9yZSAobWF5YmUgbm90 KTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRtb2QvcERMRG04Z2RJ Qnd3eUd5ZmFfYWNWS0h0dV9RDQoNCg0KDQoNCg== --_000_42BAB734C9B5412A8E53E074F198654Ajunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <97801556CEAA5948A11E5972078DE309@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5SZWdhcmRpbmcgdGhlIHN1Z2dlc3Rpb24gdG8gYWRkIHRoaXMg dGV4dDo8YnI+DQo8YnI+DQomZ3Q7IEd1aWRlbGluZXMgZm9yPGJyPg0KJmd0OyZuYnNwOyBtb3Zp bmcgZXhpc3RpbmcgZGF0YSBtb2R1bGVzIHRvIHRoZSBOTURBIGFyZSBkZWZpbmVkIGluPGJyPg0K Jmd0OyZuYnNwOyBbSS1ELmRzZHQtbm1kYS1ndWlkZWxpbmVzXS48YnI+DQo8YnI+DQpJJ20gaG9w aW5nIHRoYXQgd2UgZG8gbm90IHByb2dyZXNzIHRoZSBndWlkZWxpbmVzIGRvYy4mbmJzcDsgSWRl YWxseSA2MDg3YmlzIGNhbiBqdXN0IHN0YXRlIHdoYXQgcGVvcGxlIHNob3VsZCBkbywgd2l0aG91 dCBwcm92aWRpbmcgYSBmb3JtdWxhIGZvciB0cmFuc2l0aW9uaW5nLjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aG91Z2h0IDYw ODdiaXMgaXMgc3VwcG9zZWQgdG8gcG9pbnQgcGVvcGxlIHRvIHRoZSBOTURBIGd1aWRlbGluZXMu PGJyPg0KVGhhdCBpcyB3aHkgNjA4N2JpcyBoYXMgYmVlbiBoZWxkIGJhY2sgZm9yIHNvIGxvbmcs IGV2ZW4gdGhvdWdoIGl0IHdhczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+c3VwcG9zZWQgdG8gYmUgcHVibGlzaGVkIHdpdGggWUFORyAxLjEuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHdh c3RlIGEgbG90IG9mIHRpbWUgcmVmYWN0b3JpbmcgZHJhZnRzIGFuZCByZS1yZXZpZXdpbmcgdGhl bS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklN TyB0aGUgUkQgZ3VpZGVsaW5lcyBzaG91bGQgYmUgaW4gdGhlIFJEIGRyYWZ0LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtLRU5UJmd0 OyBJIHRob3VnaHQgdGhhdCB0aGlzIHdhcyBzZXR0bGVkIGJlZm9yZSAobWF5YmUgbm90KTogaHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRtb2QvcERMRG04Z2RJQnd3eUd5 ZmFfYWNWS0h0dV9RPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_42BAB734C9B5412A8E53E074F198654Ajunipernet_-- From nobody Tue Jun 20 08:29:53 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B96A1314C7 for ; Tue, 20 Jun 2017 08:29:51 -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, 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=yumaworks-com.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 v3_fg5ptSPb9 for ; Tue, 20 Jun 2017 08:29:49 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A5D131A8E for ; Tue, 20 Jun 2017 08:27:31 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id c11so40122937wrc.3 for ; Tue, 20 Jun 2017 08:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jsvDc8sbKqXUv/IFEriZvzTB6Ar5uXDo/sx0hCbs2y8=; b=ouM9abLnZyCnVs6N2u5vKyBmSQ5i7fWPmbntc2XCk5QMVT6aufEzGNYPJ9g9civt3+ bPxBLZVdeVd+r0pZauQZeSFAGu4zTD//r3bmzDv9WGIAyvi5RLQTFCnaHVA2rhc9KawO ftXyr5wExFj3IvkdqEZRzHbk5WGU5sGsFCuo61w/8Mc22COStzVWCb9yOWjAzVZGDXXw ykUU7PabFn+Y83RV7dqS06nqfHg9PfPiKyCu7BuSO6lVmPNY7uBxTaRnTWNqLvqPyhYS EyoZlQ+znTLynqHx+dxty+NEjiKmuZ60l2KkN+5VOHtbloD3YjW2Wp2hrbWNsFZlwxQ0 tZNg== 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; bh=jsvDc8sbKqXUv/IFEriZvzTB6Ar5uXDo/sx0hCbs2y8=; b=jd2+7aDZ+Y1UgGoleMWuazgKz2EcCeniRnIYtVQ+gIbPyBLo+4cUqwpkYx+1rfmNWY TkhU2ODRvxf/9wRCj3GeUoi9+tDgFllnVwlEPwIZ9om9XR4RNV1c4u/pbVYMNlB4FPsG 9IzPwmZn/e9dwQ9e17ZWRiGiR+60Xfoiu+I8246GAmS+3Tqb8eQRYmEDot/4tRmOaUjk IKm2UJXKMtbsGGfpvKe0Lw0MOzfWJMCZvXfM7hHbiaSs7RD6RmOHWgnJjJ7UvTtN3+rh 8xGoZRp+AJqMcs/xCB/zokoopW61A8pIlkEeC6B3sQFZDyVzkqkw/jkkJMaPb+eHRrSt qFQw== X-Gm-Message-State: AKS2vOzjU8frdgFQOuyTEZwyAF5Ypg+1Z/UpMIY3+hD6kTeDWhDXTdiN mnpNux40Emkn2q8AYJb816Ahhnil3eDMOdQ= X-Received: by 10.28.151.207 with SMTP id z198mr3365629wmd.48.1497972449588; Tue, 20 Jun 2017 08:27:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Tue, 20 Jun 2017 08:27:28 -0700 (PDT) In-Reply-To: <42BAB734-C9B5-412A-8E53-E074F198654A@juniper.net> References: <201706200605.v5K65g8E000929@idle.juniper.net> <42BAB734-C9B5-412A-8E53-E074F198654A@juniper.net> From: Andy Bierman Date: Tue, 20 Jun 2017 08:27:28 -0700 Message-ID: To: Kent Watsen Cc: Phil Shafer , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a1144ea2abdcfc5055265e3a5" Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 15:29:51 -0000 --001a1144ea2abdcfc5055265e3a5 Content-Type: text/plain; charset="UTF-8" Hi, I rewrote 6.23 and it points at the NMDA guidelines. The drafts will get published together so the references will be to RFCs, not I-Ds. That is usually what is meant by the comment below I think > I don't expect the guidelines doc is going to progress independently. Agreed. Andy On Tue, Jun 20, 2017 at 8:20 AM, Kent Watsen wrote: > > > > > Regarding the suggestion to add this text: > > > Guidelines for > > moving existing data modules to the NMDA are defined in > > [I-D.dsdt-nmda-guidelines]. > > I'm hoping that we do not progress the guidelines doc. Ideally 6087bis > can just state what people should do, without providing a formula for > transitioning. > > > > I thought 6087bis is supposed to point people to the NMDA guidelines. > That is why 6087bis has been held back for so long, even though it was > > supposed to be published with YANG 1.1. > > > > We waste a lot of time refactoring drafts and re-reviewing them. > > IMO the RD guidelines should be in the RD draft. > > > > > > I thought that this was settled before (maybe not): > https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q > > > > > > > > > --001a1144ea2abdcfc5055265e3a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I rewrote 6.23 and it points at the= NMDA guidelines.
The drafts will get published together so the r= eferences will
be to RFCs, not I-Ds.=C2=A0 That is usually what i= s meant by the comment below I think



> I don't expect the guidelines doc is going to progress independent=
ly.
Agreed.

Andy

=
On Tue, Jun 20, 2017 at 8:20 AM, Kent Watsen <kwatsen@juniper.net> wrote:

=C2=A0=

=C2=A0=

Regarding the suggest= ion to add this text:

> Guidelines for
>=C2=A0 moving existing data modules to the NMDA are defined in
>=C2=A0 [I-D.dsdt-nmda-guidelines].

I'm hoping that we do not progress the guidelines doc.=C2=A0 Ideally 60= 87bis can just state what people should do, without providing a formula for= transitioning.

=C2=A0

I thought 6087bis is supposed to point people to the= NMDA guidelines.
That is why 6087bis has been held back for so long, even though it was

supposed to be published with YANG 1.1.

=C2=A0

We waste a lot of time refactoring drafts and re-rev= iewing them.

IMO the RD guidelines should be in the RD draft.<= /u>

=C2=A0

=C2=A0

<KENT> I thought that this was settled before = (maybe not): https://mailarchive.ietf.org/= arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--001a1144ea2abdcfc5055265e3a5-- From nobody Tue Jun 20 09:40:00 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F305131BC1 for ; Tue, 20 Jun 2017 09:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 i7Gc-BEdT69P for ; Tue, 20 Jun 2017 09:39:56 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10129.outbound.protection.outlook.com [40.107.1.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1DE131B9D for ; Tue, 20 Jun 2017 09:39:55 -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=lFtdvvYt8RkQna9rAbEawL7rE6LJ3DdO38ay1Zj9RbA=; b=Si+QBg8ndBotNwWq0y2sjNS44mWMFZBi6Fy/oRS6cbYhZ/KfQcme2wUF0NJRilIBaHQIxJ32Eb7QWwRjHOMG1TdifOlVhScvwz46XmxH+U8n2/EbuJIRSxbvHgyzmUu1/+KvxZLztepePYNHBuO1TbIOwEeT0i2TIVzi1ykQiqI= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by DB6PR0701MB2999.eurprd07.prod.outlook.com (2603:10a6:4:73::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Tue, 20 Jun 2017 16:39:52 +0000 Message-ID: <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Robert Wilton" Cc: References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> Date: Tue, 20 Jun 2017 17:36:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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.169.157.161] X-ClientProxiedBy: DB6PR0202CA0023.eurprd02.prod.outlook.com (2603:10a6:4:29::33) To DB6PR0701MB2999.eurprd07.prod.outlook.com (2603:10a6:4:73::9) X-MS-Office365-Filtering-Correlation-Id: 8c7496f2-34a0-4ab2-cb5d-08d4b7faf9b7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 3:26w9H+k6j/RANDYkbwNP+zWD14CDqK7bdhRB63QyoNo4CYJTgeWy/qIfe4pRwqQjvnKCUzS16G8H3LaSC7HQxVzN+rr/a8y/vpxQjZxF0m5LOFfEYk2M0Y18rYg7nNOPZ07XodddCYMEkwAOtJNS6+ZhPLsgJZl/OnwtF1doscuxoj+LJSVFPV40VuxyQki5LCKYA1pFwpgakRH63j/I7ciVGsB6a0XNak/Lf2QnzaWeC0VNJsP+4IVXF08Oy0AxY3zsWVJAW4ddQMc++R2lAvTs9MGECYKZOsSPADEdMGGG5CiNcu1/nC9KfdtsyGYSNfrDvYQLoMKCi/kgjyIS8g== X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB6PR0701MB2999: X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 25:k8lWRZGmtcfNASQW4ZflSWXaz8fQ8q4IDPFIOTASUL6zw1DZjOLxvoBeqtrJmRgOWk3YLscvGuyPFD1IyNgsnD+5pc57H0QSpF3CB50mP6ZbGMuIsJoizutEF0i1ntKDqLvhKziUaQEmHkkL34JAG6kBZdDWZpGc3+79N3szc32IrQAuRKd1zjXqmkzex5iTkqqFz7Ho7VVzRId7+YSu3Jrf/Iekuq6J7uLZsgQiGIWsuhVWKj82Uwa6ujaCKTw4Aow0GsHxEeJOUmsWJfxl+51G7gWvytRTfOEii+ZFwX5F0dbReQ4sjqOy+Gpkrrp0L26SEzTKsrd4zHtOOUgBTMMlaP6XPdXRNWdQKqyRBm69Fp/QgemE7GK6OvI5RAR7Jbw6HHOSJxLDE6juW7y/bpCz3j5EbMAYH1H31tIH7rrNpO6qtAQZrt/+b8Q8QK4Y2eIUuYDqN3PxfdcnxUatqgPqtOrsTZ2akytKa+yJ9S1DFXsqUyj2EKqXHsVhuQd9tI5T3Q69RqwNJRkCCRvRR9p2eYoHP+ObUcSTFPw4FexVk9r6TzAhOYKdhFbKcs8dDM9X/lNJ2dxsLw9HF5wgKHDuAr2RDYXcuiupmxFNuM4VGGrrL3b/CIKlQFS3msl2A7FK70zS5PbOImiaGfDQasN7eJQ0vSpvOTENvjRpg+ufMOmaPtIWqwCIeQ78el5uYcZU/2Zf2EK6Yxv6CQEHdNOyg1UpanXP7FlgDz91CPzQDaORaWESXtO4P+Y66kP9tv4hG70hsAtn78XtmXXACrYzAbUFnGqmRuclv+iJegz0AaKqyrIFFEJhkdL3VaSLByDHRbTAkO1wQpBpLR93gZh4ARfG6KIns3Ye/fZlDno+3uPqej2K6O47BsbFkKk+x/9eDOLfmSTNtTxqasr5vsos+t29IUK2SdQcnDJIrJ0= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 31:MP+Y+t7Qi6vuCO690WRLFqPctEt0zp9HeXACLh1FYI6Dx/LTbYHcRUPV3QlduE8m/W3nUbJxtF+NbVXSynfkoWGtTmnPv0I5OkauwOVttTTJTkLPwjtOBfxfRVYVJpN4VCrvYwG0F3yjKeiWuoWb7C3kYKpN3IwAbLrzVxJy5sJpRIq2vmrUdpjCqDnhqlrYZosgIFTqL5V6UGqjjEnEn7cZueWLgbpg+9t8zraVcvwtLHe8fNksSPqUcYKRBEWrp72o4M4FAT+Y4YzS3bpYNoAqg/27Dr8OV/FLIoEmJroZDRMMLeiYxjepoPi/vDDGWnPHO2/pKqWJiSh6RB2ClRfyAn1HyDxkBOaxgndDQG24DUzNDBOJOoLJMHv5k1HOOshnu6qb4Pgo5q7C73W/clz8W/Rlmhv8C1RUIFAsoCY0v7P0FF1XZiaXLGmHCt7PIs6rhPp5X+7hA1bRVNNO7QxfcdAKELWtzSkvPVZkMJHizwnRw7lUjGyTGdotGU5O+oXKLHY3gXvsXEDptga+4RwlyxmnAb9E7aiihSKoElgx3UirJ1YyWgEZyXqnuyPUASFH1Qs12NewUVvI74tFVGJkcEmMi+HOW/UnBr9LBgq/EdB94LehNgfneQJADHYNWbnQeu8GqmLHVJ7C0pQcpriu33cWe9jqrLecdkLLMt1GfE/J0siDIYh+lrz5iDR89rL15Fj5bAkT6sssBS1/rw==; 20:ogxE4NdLzqSPhqGP11HKVoBZu3sdeDxGTxwu6RV6lWXLM0l5xXagz7njFEBJEjXi/4qGDHinieOT/VxgcgBFrtIBnYBz7S1QI6yHbvCT7FRBotGfMOlyIFWWO0J8g1c2mIytTmoYVBzNlvCHvAVjzuwrTpLJ6sulK/WorJfgbWI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2999; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DB6PR0701MB2999; 4:vwUB2FTdBpfbxMywHRRP5gNngABl/z3tm5B1?= =?Windows-1252?Q?xBuhdFTkAcTaFrklCCQ9ARGrldVt75k6xy8wPuaIvxsPPU7U6OfLQzqe?= =?Windows-1252?Q?jNedmGIqV5SAEWzy86thiITTDW/M6LvWX6laciX1wS2ccujBLoI3VN+0?= =?Windows-1252?Q?swnLMOzsojCiU9Yq8IKANlv1zcSbiuXaQq7HmvpKYKsGpsPiXAsWXX9J?= =?Windows-1252?Q?OnQrcFFNBT3kQ7QD6lnB6HGCPsrhmj8oSOX8bOlp9EnCpqfIsMzHI1D7?= =?Windows-1252?Q?0wsiTE10Fch7J9MLS7FyZJ88EEmFP9ng0LVb/1A3OPDilEipuNtGD8Ne?= =?Windows-1252?Q?tq64I4oiKKnJDJ7hgTgybX5Y4yK7IJr+GK2FF4+RqU29LSsgBGJHQ/Q9?= =?Windows-1252?Q?gQiuQnzxGXj5wAf94HU4CPCIcDNYG3mrURdyJyH3R+1MX2azIar6bGrv?= =?Windows-1252?Q?OAngi/domwhLXea0VvywggwSukofiL6tK4M034IO1G69ej1++It5boz+?= =?Windows-1252?Q?A/Rcp0AWqIOIIpgiVDGXrN3aee+v8L2wg6huZ9hj9LYAOLQDGRE6BmJ0?= =?Windows-1252?Q?UrTbWIgJJ68/C3sfpfZMjOz91EYFzyUdEwdWwxYHsM5kSErYKDCU0mwy?= =?Windows-1252?Q?dE5uDRxaFeZ0OOYZIJgDCkLV61rGAe+xfIKQiSMp35lCBkNqpzGT2qcW?= =?Windows-1252?Q?97aIJqkNfRTbJVL5id7WFFXd9R6Ba602dOM83mS33R0Aaltg9+9jdz2M?= =?Windows-1252?Q?Vs5II3BIqa+aRAlyNHOeO1bP8Yvh8KtnQYYIAibfheNtB9YvyF86UXa8?= =?Windows-1252?Q?gYHUFE7w5G48IE3ZWFxJm8FBsrXLzA+b00hn7UbVEsXmdaWbGv6djMPI?= =?Windows-1252?Q?HQBIi7VgNwkmALxi4fBtGFFvNxUkhWqF39R4V8UCdvTdTDr+yqigevL7?= =?Windows-1252?Q?eh0QwixXfl2391jIy6QOKD91dG1+FaShbPIYHqO5w37oW8jLvkyvOkPN?= =?Windows-1252?Q?9a/1tMfrsPVhHIXRBw16HQyAHZrl5u5wdw0/JeCYYGw8siDtDZM95Zcv?= =?Windows-1252?Q?e0xomJR+eOy5BoOhF/aWrorvhmzCjx1Dr2iMcoAQNE8QQTaJYxAmgHv+?= =?Windows-1252?Q?ZfmUYAkD8rg32TvGIDMzNMQucrtGVLEhBkjrPgDDKmB+ONWPb+uwBHd0?= =?Windows-1252?Q?Msq1XCS8/tKNWRxiLlkWd84lRdXJJEMINN8YFL5wcdcqIDlgzVir+wzX?= =?Windows-1252?Q?lQQ6fKaTlJ9TobovmyePwbQCstQ6nPlOSBZLglrzv+usb5DKiKgJG9ZL?= =?Windows-1252?Q?qKU/NCBfvg+D3w7W0mr+IgXOeg=3D=3D?= X-Forefront-PRVS: 03449D5DD1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39400400002)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(13464003)(24454002)(377454003)(3846002)(81686999)(81166006)(9686003)(14496001)(230783001)(50986999)(42186005)(6496005)(25786009)(50226002)(305945005)(966005)(76176999)(7736002)(53546009)(6116002)(53936002)(6666003)(478600001)(2906002)(38730400002)(5660300001)(110136004)(84392002)(8676002)(4326008)(33646002)(4720700003)(81816999)(44736005)(230700001)(6916009)(6486002)(189998001)(86362001)(23746002)(66066001)(44716002)(62236002)(50466002)(6306002)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2999; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DB6PR0701MB2999; 23:A6whiSy/Ul4glfScxu3d5urUiiDNK8WEXhB?= =?Windows-1252?Q?klqc9gAu96fEBqcBWChNZeaAiNMSj2pQ/6fOlCLGCxg5awiG7mIKkW3t?= =?Windows-1252?Q?qmU3QM8knrDk9UEidReyz4/dBhCJhmO16q9XUBB3FaNf2XzIgWsM5ows?= =?Windows-1252?Q?bWPcvoXLwszpOD6mOz4CStnAsUA2c+dcxON6JNRPQCm39bmsLhPLlXFJ?= =?Windows-1252?Q?04RSsDjCQ9P9Ths4+F08ymNGBfyqEaWpK2AFWwP8zU1w1TseQM+1TDbp?= =?Windows-1252?Q?pHvsE1stikGJmRX+z/jru+tJNCEimwz0TDKYR6J+iaZtAvKtgXtmgOGc?= =?Windows-1252?Q?xXlNC6k6im/hHmw0hsZqPOhIN88MMt3amcdkUp4JWs30F6IG8lkjppjW?= =?Windows-1252?Q?SqBdIXZFwIf9mFVcmrOdhMNkO5KXO5bYW9wFopEqdgJtfVnKAKIaQ/M/?= =?Windows-1252?Q?Q6X7grW5p9nB7dmz+RqSW+mucZN/bW06QV9KXuyCi3/y8Citnqg9elgx?= =?Windows-1252?Q?okK+0eQHJ7yRoJ4NzksuCsM81+UeW6GAZpCZtO5QLdUasSYRYxhPxoAV?= =?Windows-1252?Q?RL1pQSmSryvqIsq+C/AClxCxFmVL2KBsD1rp/5QFgC4KJ4vLFdaiQkWx?= =?Windows-1252?Q?yx3YAJcO4xv/SFSIYiPgYc/ueeN0mxfxE3JxBMMKYJtX5O6JF9UtHRdW?= =?Windows-1252?Q?p3ugtoeSY3YHV/urn06l6wQWdUM5MUkmzoTLd6hQLTZRWqB5rYx8guTE?= =?Windows-1252?Q?QfkabCAUB7y3RHz+wOGhiIndmHelSnG7Ze1r+6xrOECA2LLE+T5Qm/iu?= =?Windows-1252?Q?XGkXw5jRXg99gZXmIzNT0P8qfBrPyTQ19I9mxVDEV1TaR7JMzkZpYq58?= =?Windows-1252?Q?XYN/Btl+ezxpWSO3l/YZWureiMPWemw4ynCoMDPXuBaIo3EKsj4AkENN?= =?Windows-1252?Q?Kb6BAnVrfSHSr7wGgHahboLjrTMnXQ8qy00UOcf3nTYyqWKISt0luWIM?= =?Windows-1252?Q?kRJoRKVzuZzlKZNL3LzxwzNBfW+TQa6af+RIhPKENIFzrau+192S0skp?= =?Windows-1252?Q?1iAe2j9AY8jpvJ8sWW7nkO23g3JAyIJyPu419O+gJImkC6GkzW2Ian64?= =?Windows-1252?Q?yFw8VUt89iGMWLKt1pHj8E9YQaauMBFLaW4nSQNRJEXduuQREuQsKLhO?= =?Windows-1252?Q?Z6n/64iSAO6XPdFr5d2WW5uyhBbjwSfhpLUr4hPESiSm/F6Tc9hfwP7+?= =?Windows-1252?Q?Auhc97lgZSYU8lKpYWb2rfEXO+qvsa2yYTFiAHKPRQHEcua0HNXeV6Re?= =?Windows-1252?Q?2H1C/oMVtypFSzzd59fQbdkmIoZNWUYRQVyg7x0YOchDlE4TcXhKZY1y?= =?Windows-1252?Q?nuwIt3VsmLO6OyW3zxHN+T2UZDQCYWkdaxWFnr72T4YJjSeOQaXJFiiY?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DB6PR0701MB2999; 6:xh4npU3sEJPk+GkkZiOQbYJCPNIoIc7dbk/i?= =?Windows-1252?Q?A0L70MnnUqc06outkiHf3nhxiHJRTwuNl7kONw4js3z1FNjbNCnsRUuK?= =?Windows-1252?Q?OlA6O1vbOPNoIpMiWPPS892SI/GJ1xhvpJuTHiAWXv5paxCdFKvD4wwq?= =?Windows-1252?Q?ypLb27PyzJkaDE/F1GcngEDXt82K+i70R9AW95x6Sd7p5YnFbZks3nTy?= =?Windows-1252?Q?3/z+hpERYcpKFLEyUYWKP34/FffcG/aU3Nkv5FmlI1ufKd/02veQUq7D?= =?Windows-1252?Q?/8CZ749iWexX5VXcg7bpe2on7G9+TLL4xsVt58o7xv3R50UKoSxR5+SF?= =?Windows-1252?Q?1nba10RED0jPxka73F/+WmT12KVH7IIVdjjuGCkLoOGsL3qI4LTf8mOu?= =?Windows-1252?Q?d7PzvrER8xjQl7PoprtFHqlJ43cM5oj9AnSfN/Q372Y+9U18mzm/P3Wq?= =?Windows-1252?Q?AN8XLN0ZvVq3hKg3KUwePPr13IFSEOYUiqj0ldODJwTf4AnVYCpTvmFc?= =?Windows-1252?Q?HPTM+fZEyqDynrCkAXQ16gh4zq8UlsJI8t0Oj/GH4BeO1++SnI8st1PA?= =?Windows-1252?Q?JLVmudcK7hJh+BCzzEyQwDExv5l05G6pYOLDjW8snibD2Wk496M6/U6A?= =?Windows-1252?Q?mLr/uG2+bVaBx9YIM0luh+1R2ckT+/4fhdWHC+wPbJbgYVCySVgOcaNq?= =?Windows-1252?Q?6Q5TIZDA2BHn+vzpwJUUEFouAz9dGsJOxd5ULTbfts9wUIGdt6F+e6Tx?= =?Windows-1252?Q?bquNQB1xxuendQlouNaavC+s66I4pdkrfghTGqk4o3C577B+0VyOypUB?= =?Windows-1252?Q?k3abaK2wEntVQKnQM1VJ22Da4EH6Y/InBlaexi3NGSdPxu1W0+EtYRpX?= =?Windows-1252?Q?FeuqyPlUKe9bpVtU5odDwdyqNq6yKqHBlkL3F1dBYoYsQtPsU16klD7l?= =?Windows-1252?Q?IJWfGVRB7e7hh0vtvnjD8uLIByIjEgx9O/N9QFco5OWB9NnM+GEecv+o?= =?Windows-1252?Q?QoJyOHPkGJToGRrUKYIdpNXi48AmTfMVs71QB8lKzrJ/xppgl/TPeBhP?= =?Windows-1252?Q?3WgmaSLv4JI7MOc=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 5:a+uyFaKAxUtGzRLveN77wsFnDABLgbQRHty5DjvArWm+zxS3P46FO8xD+Db7O2iQasb3Zw7bndZDsKLmlvzlarynry6o1akTSRzNPZlpOYjGeKipze9scauBxAjMyAwsknA2rl+5p1QLZmzspELoEK3qNDeOCMvm19D9rlDri5mbmjhBwiz1jRrJHVQSEEvMz1cEEE/EDrAUQIDGOapWMrIJ9vsiTJ0A36L6ULb+GWJCxqoDocR3++1DNl0u2ue1TcvB4cCQdhttjXeCQo9yxf86NCnGC9/cPQFyYUcGgWe3ZOSzHjIwJC1hgvNoxtgreUVSNAgCZ1qbMAQ6YCOjM0plY1i9M9PUoOlbzhl/RL+DjqU0xEIB/iFTVBUfi8hli9VadcZWQPCjkOGV5h6XI3psPxBnm/SfJfhSYnpszTcUYi2BaFqFtm0SQ6KX1JphOdAVUu44gvm2x/ATGsJFdMsrFMDHy9mp1FTzH3hqkBnYSG66nnU2ppXF6l6wcCl2; 24:tqEF/HQLhRRNm2MMTktNJsldLycAXS7SSB9zY3HyVuYIiQaDIjeIYNw3eNnvR5FhJGhuSvyRxwkQOp3PXSZ3D/BHvtPQ6CNgX8twovkwnSo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 7:/FjFbT7AnztclIM2Dv2K47k1lJY/+toNhJQMk0iTD27PIHyvOw6iveWyomt/JuoQuQ/7YViabrnLB7r6xNhp+JxB3/Zdf3iR0cGw7wZTFCgRwJ9C2k2/uaU7422YgbzjuHrKnmX1iUai++c5cGzHnr7wjY3e2kpmCsWFLcH9OPrOodYlkYflGfwiTxLglo20tjfhfhVhNwz9nMTpbeniNETppIfsnejq92i/7AijfhV0FBdF1WBqRJRBBXureaJwqbEzXYPd9T/8Z2juns37OGXuffJ+/ND63wRgKXTTIAvCH3ggVOsbmpYfzeJ1WvNetjNQoGneJDnVS/tZPSVBLshWqenkDycs5klLGodqOJ7qIY9GV1ybAMqfsEFqWJ6jztTfxco7W2NvNw34Sx4O+y3Qabf5SX7LijoQ3XE+C/sJTaEf7tvsGCFOmVCE9rnRnyxp0Ma99DYHwWDAC6KS7NHO0m8BmzEo72vsDN1NrUP3bTGXDfEysQ2ycDqwxFto9jFFLEJEzJVVn+ORwQgYHYjpTzqp3kgJcsCeQlTKOUkpINvBHF/XxIKK46i1c0JpKbnmrI1IImlNqxj9lZAYu8r5hZUrpEAdm3L/aoqnpZ2rgRAdrMIPdLzwon2hRiWEQ2Q5vdFUyVHdchr97wItxabY118GfXdoUhX8uhG37eabJvxssV15vWWPdth88Vr0ORGvy7qC+wZmerCZZVw/Wrtqcpnw5KpBiEqH/vSAg6h2CL2YY69FondBstUUXWps9lSf2fHw22V2e7eOQfhJLSeJ7L9ij9vSm5DBzUE0C14= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2017 16:39:52.2705 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2999 Archived-At: Subject: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 16:39:59 -0000 ----- Original Message ----- From: "Robert Wilton" Sent: Tuesday, June 20, 2017 1:35 PM > Hi Tom, > > On 20/06/2017 12:39, t.petch wrote: > > --- Original Message ----- > > From: "Phil Shafer" > > Sent: Tuesday, June 20, 2017 7:05 AM > > > >> Andy Bierman writes: > >>> This draft addresses all remaining open issues, include the rewrite > > of the > >>> opstate section. > >>>> In YANG, any data that has a "config" statement value of "false" > >>>> could be considered operational data. The relationship between > >>>> configuration (i.e., "config" statement has a value of "true") and > >>>> operational data can be complex. > >> The NMDA draft includes the following in its terminology section: > >> > >> - configuration: Data that determines how a device behaves. This > >> data is modeled in YANG using "config true" nodes. Configuration > >> can originate from different sources. > >> > >> - operational state: The combination of applied configuration and > >> system state. > >> > >> It would be nice to use matching terms, either by importing the > >> NMDA terms directly, or by mimicing them in this draft. If your > >> "operational data" means "config false" and NMDA's "operational state" > >> means both config true and config false, readers will be confused. > > Phil > > > > Well, it would if the definitions in NMDA brought clarity but I think > > the opposite. > > > > 'Data that determines how a device behaves' seems clear until you read > > on and find that this excludes data learnt from the system or data > > learnt from routing protocols. > Please can you clarify. The text that you are quoting above is from the > NMDA definition of "configuration". > > Data learned from the system or routing protocols (for YANG config true > nodes) would be classified as "system configuration" or "learned > configuration", which are sub categories of "configuration", and hence > are not excluded from the more general definition of "configuration". Robert The definition of 'configuration' in netmod-revised-datastores-02 is very different from what has gone before in NETCONF and NETMOD. You start with 'Data that determines how a device behaves. ' which is how I would have defined configuration before the days of NETCONF and which I imagine is how many who have not been exposed to NETCONF would still do. NETCONF narrowed the definition a lot; 'Data that determines how a device behaves' opens it up again. You add the qualification 'using "config true" nodes' which doesn't really mean anything in this context, unless you already know some YANG models, and know what is modelled in this way and what is not and so can work it out, reverse engineering. Coming to netmod-revised-datastores-02 with an innocent eye, knowing that the ground has moved, that some of my assumptions of the past 10 years are no longer valid, then these definitions convey to me that configuration acquired from the system or from routing protocols, to take two common examples, will now always be modelled 'config true', that is the first sentence is the definition and the second - 'config true' - is the consequence thereof. Of course, if you come to the I-D knowing otherwise, then you may find a different interpretation but I do not think that that is the obvious interpretation. Tom Petch > Thanks, > Rob > > > > > > I find the idea that the behaviour of a device is not determined by > > routing protocols or a hot-plugged card an odd one. > > > > This definition is rather different to that in NETCONF and seems > > unlikely to bring clarity so I think it would be a mistake to > > incorporate it in rfc6087bis.. > > > > Tom Petch > > > > > >> Also you say "operational state and other data such as statistics" > >> which inconsisent. Under either set of terms, statistics are > >> part of operational state. > >> > >>>> The original set of datastores defined in NETCONF (i.e., candidate, > >>>> unning, and startup) are not sufficient to fully manage a device > >>>> ith multiple sources of configuration data. In additional, a > >>>> separate datastore is needed to store operational state and other > >>>> data such as statistics. Refer to > >>>> [I-D.ietf-netmod-revised-datastores] for details on this new > > "revised > >>>> datastore" architecture. Guidelines for usage of the new datastores > >>>> (including the operational datastore) is defined in > >>>> [I-D.dsdt-nmda-guidelines]. > >> "not sufficient to fully manage" is too broad a claim. Can I suggest > >> a more positive spin: > >> > >> The Network Management Datastore Architecture (NMDA) defines a > >> new set of datastores that improve visibility into the device, > >> both in terms of the "intended" configurations values and the > >> true operationally "in use" values. Refer to > >> [I-D.ietf-netmod-revised-datastores] for details. Guidelines for > >> moving existing data modules to the NMDA are defined in > >> [I-D.dsdt-nmda-guidelines]. > >> > >> Thanks, > >> Phil > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > From nobody Tue Jun 20 10:51:37 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4653313156A for ; Tue, 20 Jun 2017 10:51:36 -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, RP_MATCHES_RCVD=-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 83vkMDn-ndgZ for ; Tue, 20 Jun 2017 10:51:33 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B819912ECB7 for ; Tue, 20 Jun 2017 10:51:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7FEB53C; Tue, 20 Jun 2017 19:51:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id A0u6MMq4sck2; Tue, 20 Jun 2017 19:51:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 20 Jun 2017 19:51:14 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 364F620091; Tue, 20 Jun 2017 19:51:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Hi5UWnV-foRe; Tue, 20 Jun 2017 19:51:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BBEB2009B; Tue, 20 Jun 2017 19:51:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 89B9B3FCB393; Tue, 20 Jun 2017 19:51:13 +0200 (CEST) Date: Tue, 20 Jun 2017 19:51:13 +0200 From: Juergen Schoenwaelder To: "t.petch" Cc: Robert Wilton , netmod@ietf.org Message-ID: <20170620175113.GA2280@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "t.petch" , Robert Wilton , netmod@ietf.org References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 17:51:36 -0000 On Tue, Jun 20, 2017 at 05:36:12PM +0100, t.petch wrote: > > Robert > > The definition of 'configuration' in netmod-revised-datastores-02 is > very different from what has gone before in NETCONF and NETMOD. > > You start with > 'Data that determines how a device behaves. ' > which is how I would have defined configuration before the days of > NETCONF and which I imagine is how many who have not been exposed to > NETCONF would still do. NETCONF narrowed the definition a lot; 'Data > that determines how a device behaves' opens it up again. > > You add the qualification 'using "config true" nodes' which doesn't > really mean anything in this context, unless you already know some YANG > models, and know what is modelled in this way and what is not and so can > work it out, reverse engineering. > > Coming to netmod-revised-datastores-02 with an innocent eye, knowing > that the ground has moved, that some of my assumptions of the past 10 > years are no longer valid, then these definitions convey to me that > configuration acquired from the system or from routing protocols, to > take two common examples, will now always be modelled 'config true', > that is the first sentence is the definition and the second - 'config > true' - is the consequence thereof. > > Of course, if you come to the I-D knowing otherwise, then you may find a > different interpretation but I do not think that that is the obvious > interpretation. > Is your proposal to take out "This data is modeled in YANG using "config true" nodes."? Note that the NMDA document further defines o conventional configuration: Configuration that is stored in any of the conventional configuration datastores. o dynamic configuration: Configuration obtained via a dynamic datastore. o learned configuration: Configuration that has been learned via protocol interactions with other systems that is not conventional or dynamic configuration. o system configuration: Configuration that is supplied by the device itself. o default configuration: Configuration that is not explicitly provided but for which a value defined in the data model is used. There are corresponding origin attribute definitions. (With the minore caveat that the origin value for conventional configuration is intended since this is the datastore conventional configuration finally originates from.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 20 11:19:41 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2C312947F for ; Tue, 20 Jun 2017 11:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 Vp9SJbhTiWvH for ; Tue, 20 Jun 2017 11:19:37 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 3FE121315C6 for ; Tue, 20 Jun 2017 11:19:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 26B3F46952A; Tue, 20 Jun 2017 11:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1497982775; bh=h6gimQkaXoEoNxUEPQB7ci7y2MnvOlgDMi/slH/9VnE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ncF1qojVWDnFRu7YKuytlrktW46QgTY7ECiAVlgVzQ1czyYa/NeMAC8BYgq+DpFWC KevyWiZE8KavmTtatz/4Pz1HH+iLuA7T55RH9v+9qNiziK2sakX3XyM0KalIqzP0Uw aWhZ0EjOsCrpbqtJgpAS7P12Or7umsYH2w8hwKK4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2591E469463; Tue, 20 Jun 2017 11:19:34 -0700 (PDT) To: "t.petch" , Robert Wilton , netmod@ietf.org References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> <20170620175113.GA2280@elstar.local> From: "Joel M. Halpern" Message-ID: <5b9f1ec3-9adf-c465-f38e-5ee11a2612b3@joelhalpern.com> Date: Tue, 20 Jun 2017 14:19:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170620175113.GA2280@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 18:19:39 -0000 I was going to just watch this, but I can't. To call protocol negotiated values "configuration" is to create a usage which will confuse MANY people. Even worse, configuring protocol learned values is liable to break things. To use one example, many protocols negotiate timers. The value that a given systems starts with is the configured value. The value that it learns from the protocol exchange is the operational value. In fact, you better not try to configure that value or you are liable to break the protocol. Yours, Joel On 6/20/17 1:51 PM, Juergen Schoenwaelder wrote: > On Tue, Jun 20, 2017 at 05:36:12PM +0100, t.petch wrote: >> >> Robert >> >> The definition of 'configuration' in netmod-revised-datastores-02 is >> very different from what has gone before in NETCONF and NETMOD. >> >> You start with >> 'Data that determines how a device behaves.' >> which is how I would have defined configuration before the days of >> NETCONF and which I imagine is how many who have not been exposed to >> NETCONF would still do. NETCONF narrowed the definition a lot; 'Data >> that determines how a device behaves' opens it up again. >> >> You add the qualification 'using "config true" nodes' which doesn't >> really mean anything in this context, unless you already know some YANG >> models, and know what is modelled in this way and what is not and so can >> work it out, reverse engineering. >> >> Coming to netmod-revised-datastores-02 with an innocent eye, knowing >> that the ground has moved, that some of my assumptions of the past 10 >> years are no longer valid, then these definitions convey to me that >> configuration acquired from the system or from routing protocols, to >> take two common examples, will now always be modelled 'config true', >> that is the first sentence is the definition and the second - 'config >> true' - is the consequence thereof. >> >> Of course, if you come to the I-D knowing otherwise, then you may find a >> different interpretation but I do not think that that is the obvious >> interpretation. >> > > Is your proposal to take out "This data is modeled in YANG using > "config true" nodes."? > > Note that the NMDA document further defines > > o conventional configuration: Configuration that is stored in any of > the conventional configuration datastores. > > o dynamic configuration: Configuration obtained via a dynamic > datastore. > > o learned configuration: Configuration that has been learned via > protocol interactions with other systems that is not conventional > or dynamic configuration. > > o system configuration: Configuration that is supplied by the device > itself. > > o default configuration: Configuration that is not explicitly > provided but for which a value defined in the data model is used. > > There are corresponding origin attribute definitions. (With the minore > caveat that the origin value for conventional configuration is > intended since this is the datastore conventional configuration > finally originates from.) > > /js > From nobody Tue Jun 20 12:06:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85931315FD for ; Tue, 20 Jun 2017 12:06:44 -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, HTML_MESSAGE=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=yumaworks-com.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 XH5caBRkBok4 for ; Tue, 20 Jun 2017 12:06:42 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 80F331315F6 for ; Tue, 20 Jun 2017 12:06:41 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id c11so48113286wrc.3 for ; Tue, 20 Jun 2017 12:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G3xIR/bsfgzm1D2nkeQjFoDnUFht57W5v2orJ9IXiNw=; b=ka2AD49iK3wWsvLxmv90vGjGcPL3p9t6Aw7RemqTZ/yQDdqDBw9HRqkspeuksnldxJ 7LqtSFlDpLpuXSFzSzlN7yYcU06eFApXD44c6ik/UrBS3FvEasz77+gE+cRWXRVETA2D wOsFJDUwMBC2HKis6Wt0u+2BN96B/RJUd2Jpunu/nehso3d5DVxPTGkbvzL+9xFE/MTb 06rETCXUetbuc7QdhxHrPw1uuTKphxOz5JXIHXXw8kv6mSAUfZ0YRnf1ASocWJpH5w70 Q4uEHFGBIqqP90reCqeO26ugQspdhzd0lsMrUy/9w7EfIX6ZpS84aApvXPqgvG1g+HJi D1cw== 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; bh=G3xIR/bsfgzm1D2nkeQjFoDnUFht57W5v2orJ9IXiNw=; b=tKQqAM+OF3p5BkO4DNAqKaALsxyqV5+nEIEWw1daM+QSsYawC6PQsK+UGnZ7e1Do0Z oBIhKjlhwnxRTfix7J4PLClihzMDaFdEaG6JhXkQOdPEseWZfVkr4aUxbnafOyhqEp6S /AI3XoUZZD1o5vALeslTN/A+g501h0BcipWASUn3B2jESz4BXg1pAZ5R+abiu0Bd5WJR YdWv9W9njuFQ7XBuEh+EXIgbdYQYfMxkBP/x+yntUjjkFLUI3JYerVg1p2KRP8kLWIXH wTmQTz1m1Eb0b3Cv3qbBMCw/W6t1UmUMr0zrLwjoXnETFG5OBCYrj8Bcj44G4vzSVO6N Ju2g== X-Gm-Message-State: AKS2vOyua/OatYjwypFFAjCk4AYa56zsBPkgW/d/vOruhKE/1vDXpXAP ycytsD+5GFTyYdgwALf8S6dCh2G/qhAc X-Received: by 10.28.30.3 with SMTP id e3mr3750388wme.60.1497985599941; Tue, 20 Jun 2017 12:06:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Tue, 20 Jun 2017 12:06:39 -0700 (PDT) In-Reply-To: <5b9f1ec3-9adf-c465-f38e-5ee11a2612b3@joelhalpern.com> References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> <20170620175113.GA2280@elstar.local> <5b9f1ec3-9adf-c465-f38e-5ee11a2612b3@joelhalpern.com> From: Andy Bierman Date: Tue, 20 Jun 2017 12:06:39 -0700 Message-ID: To: "Joel M. Halpern" Cc: "t.petch" , Robert Wilton , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114b3508904975055268f377" Archived-At: Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:06:45 -0000 --001a114b3508904975055268f377 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 20, 2017 at 11:19 AM, Joel M. Halpern wrote: > I was going to just watch this, but I can't. > > To call protocol negotiated values "configuration" is to create a usage > which will confuse MANY people. Even worse, configuring protocol learned > values is liable to break things. To use one example, many protocols > negotiate timers. The value that a given systems starts with is the > configured value. The value that it learns from the protocol exchange is > the operational value. In fact, you better not try to configure that value > or you are liable to break the protocol. > > Maybe confusing, maybe clarifying, maybe some of both. If you look at running-config and ephemeral datastores as sibling configuration datastores, and the operational datastore as the outcome of the system resolving all possible configuration sources, then the terms make more sense. At the NYC NETMOD interim, we convinced ourselves of at least 2 things, maybe neither is still true 1) it could be an operator deployment decision to use any running-config data model in the ephemeral datastore 2) the values in the ephemeral datastore are always higher priority than corresponding values from running (intended) In this system, a configured value would just get ignored and the protocol negotiated timer would get used instead. > Yours, > Joel > > Andy > > On 6/20/17 1:51 PM, Juergen Schoenwaelder wrote: > >> On Tue, Jun 20, 2017 at 05:36:12PM +0100, t.petch wrote: >> >>> >>> Robert >>> >>> The definition of 'configuration' in netmod-revised-datastores-02 is >>> very different from what has gone before in NETCONF and NETMOD. >>> >>> You start with >>> 'Data that determines how a device behaves.' >>> which is how I would have defined configuration before the days of >>> NETCONF and which I imagine is how many who have not been exposed to >>> NETCONF would still do. NETCONF narrowed the definition a lot; 'Data >>> that determines how a device behaves' opens it up again. >>> >>> You add the qualification 'using "config true" nodes' which doesn't >>> really mean anything in this context, unless you already know some YANG >>> models, and know what is modelled in this way and what is not and so can >>> work it out, reverse engineering. >>> >>> Coming to netmod-revised-datastores-02 with an innocent eye, knowing >>> that the ground has moved, that some of my assumptions of the past 10 >>> years are no longer valid, then these definitions convey to me that >>> configuration acquired from the system or from routing protocols, to >>> take two common examples, will now always be modelled 'config true', >>> that is the first sentence is the definition and the second - 'config >>> true' - is the consequence thereof. >>> >>> Of course, if you come to the I-D knowing otherwise, then you may find a >>> different interpretation but I do not think that that is the obvious >>> interpretation. >>> >>> >> Is your proposal to take out "This data is modeled in YANG using >> "config true" nodes."? >> >> Note that the NMDA document further defines >> >> o conventional configuration: Configuration that is stored in any of >> the conventional configuration datastores. >> >> o dynamic configuration: Configuration obtained via a dynamic >> datastore. >> >> o learned configuration: Configuration that has been learned via >> protocol interactions with other systems that is not conventional >> or dynamic configuration. >> >> o system configuration: Configuration that is supplied by the device >> itself. >> >> o default configuration: Configuration that is not explicitly >> provided but for which a value defined in the data model is used. >> >> There are corresponding origin attribute definitions. (With the minore >> caveat that the origin value for conventional configuration is >> intended since this is the datastore conventional configuration >> finally originates from.) >> >> /js >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114b3508904975055268f377 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 20, 2017 at 11:19 AM, Joel M. Halpern <= ;jmh@joelhalpern.c= om> wrote:
I was going to j= ust watch this, but I can't.

To call protocol negotiated values "configuration" is to create a= usage which will confuse MANY people.=C2=A0 Even worse, configuring protoc= ol learned values is liable to break things.=C2=A0 To use one example, many= protocols negotiate timers.=C2=A0 The value that a given systems starts wi= th is the configured value.=C2=A0 The value that it learns from the protoco= l exchange is the operational value.=C2=A0 In fact, you better not try to c= onfigure that value or you are liable to break the protocol.



Maybe confusing, maybe = clarifying, maybe some of both.

If you look at run= ning-config and ephemeral datastores as sibling configuration datastores,
and the operational datastore as the outcome of the system resolvi= ng all possible configuration
sources, then the terms make more s= ense.

At the NYC NETMOD interim, we convinced ours= elves of at least 2 things,
maybe neither is still true

=C2=A0 =C2=A01) it could be an operator deployment decision= to use any running-config data model
=C2=A0 =C2=A0 =C2=A0 =C2=A0= in the ephemeral datastore

=C2=A0 =C2=A02) the va= lues in the ephemeral datastore are always higher priority than correspondi= ng
=C2=A0 =C2=A0 =C2=A0 =C2=A0values from running (intended)

In this system, a configured value would just get igno= red and the protocol
negotiated timer would get used instead.

=C2=A0
Yours,
Joel



Andy

=C2=A0

On 6/20/17 1:51 PM, Juergen Schoenwaelder wrote:
On Tue, Jun 20, 2017 at 05:36:12PM +0100, t.petch wrote:

Robert

The definition of 'configuration' in netmod-revised-datastores-02 i= s
very different from what has gone before in NETCONF and NETMOD.

You start with
'Data that determines how a device behaves.'
which is how I would have defined configuration before the days of
NETCONF and which I imagine is how many who have not been exposed to
NETCONF would still do.=C2=A0 NETCONF narrowed the definition a lot; 'D= ata
that determines how a device behaves' opens it up again.

You add the qualification 'using "config true" nodes' whi= ch doesn't
really mean anything in this context, unless you already know some YANG
models, and know what is modelled in this way and what is not and so can work it out, reverse engineering.

Coming to netmod-revised-datastores-02=C2=A0 with an innocent eye, knowing<= br> that the ground has moved, that some of my assumptions of the past 10
years are no longer valid, then these definitions convey to me that
configuration acquired from the system or from routing protocols, to
take two common examples, will now always be modelled 'config true'= ,
that is the first sentence is the definition and the second - 'config true' - is the consequence thereof.

Of course, if you come to the I-D knowing otherwise, then you may find a different interpretation but I do not think that that is the obvious
interpretation.


Is your proposal to take out "This data is modeled in YANG using
"config true" nodes."?

Note that the NMDA document further defines

=C2=A0 =C2=A0 o=C2=A0 conventional configuration: Configuration that is sto= red in any of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the conventional configuration datastores.

=C2=A0 =C2=A0 o=C2=A0 dynamic configuration: Configuration obtained via a d= ynamic
=C2=A0 =C2=A0 =C2=A0 =C2=A0datastore.

=C2=A0 =C2=A0 o=C2=A0 learned configuration: Configuration that has been le= arned via
=C2=A0 =C2=A0 =C2=A0 =C2=A0protocol interactions with other systems that is= not conventional
=C2=A0 =C2=A0 =C2=A0 =C2=A0or dynamic configuration.

=C2=A0 =C2=A0 o=C2=A0 system configuration: Configuration that is supplied = by the device
=C2=A0 =C2=A0 =C2=A0 =C2=A0itself.

=C2=A0 =C2=A0 o=C2=A0 default configuration: Configuration that is not expl= icitly
=C2=A0 =C2=A0 =C2=A0 =C2=A0provided but for which a value defined in the da= ta model is used.

There are corresponding origin attribute definitions. (With the minore
caveat that the origin value for conventional configuration is
intended since this is the datastore conventional configuration
finally originates from.)

/js


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

--001a114b3508904975055268f377-- From nobody Tue Jun 20 12:40:38 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4331713160E for ; Tue, 20 Jun 2017 12:40:36 -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, RP_MATCHES_RCVD=-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 e7QgK5rByKVs for ; Tue, 20 Jun 2017 12:40:34 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB92313161D for ; Tue, 20 Jun 2017 12:40:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 93B187E; Tue, 20 Jun 2017 21:40:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id k3GUzUxfkVAL; Tue, 20 Jun 2017 21:40:19 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 20 Jun 2017 21:40:20 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72E4F2009B; Tue, 20 Jun 2017 21:40:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7mISAJc7NHZU; Tue, 20 Jun 2017 21:40:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC06320091; Tue, 20 Jun 2017 21:40:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C80513FCB60A; Tue, 20 Jun 2017 21:40:19 +0200 (CEST) Date: Tue, 20 Jun 2017 21:40:19 +0200 From: Juergen Schoenwaelder To: "Joel M. Halpern" Cc: "t.petch" , Robert Wilton , netmod@ietf.org Message-ID: <20170620194019.GA2432@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Joel M. Halpern" , "t.petch" , Robert Wilton , netmod@ietf.org References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> <20170620175113.GA2280@elstar.local> <5b9f1ec3-9adf-c465-f38e-5ee11a2612b3@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5b9f1ec3-9adf-c465-f38e-5ee11a2612b3@joelhalpern.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:40:36 -0000 On Tue, Jun 20, 2017 at 02:19:32PM -0400, Joel M. Halpern wrote: > I was going to just watch this, but I can't. > > To call protocol negotiated values "configuration" is to create a usage > which will confuse MANY people. There are people who have a broad concept of configuration and there are people who have a narrow concept of configuration. There is not way to resolve this. All we can do is come up with a terminology that is consistent and can be used consistently. > Even worse, configuring protocol learned > values is liable to break things. To use one example, many protocols > negotiate timers. The value that a given systems starts with is the > configured value. The value that it learns from the protocol exchange is > the operational value. In fact, you better not try to configure that value > or you are liable to break the protocol. Nobody proposed this, please take a look at the figure in the document to understand the information flow and where the distinction is made. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 20 19:17:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100911292CE for ; Tue, 20 Jun 2017 19:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3c_a6WmNBlv for ; Tue, 20 Jun 2017 19:17:46 -0700 (PDT) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538541296C9 for ; Tue, 20 Jun 2017 19:17:45 -0700 (PDT) From: Alex Campbell To: "Joel M. Halpern" CC: "netmod@ietf.org" Thread-Topic: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt Thread-Index: AQHS6ePvPxITcPwHOkmvxNS32Zk+16IufS6AgAAH6QCAAAx98Q== Date: Wed, 21 Jun 2017 02:17:43 +0000 Message-ID: <1498011463160.83931@Aviatnet.com> References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> <20170620175113.GA2280@elstar.local>, <5b9f1ec3-9adf-c465-f38e-5ee11a2612b3@joelhalpern.com> In-Reply-To: <5b9f1ec3-9adf-c465-f38e-5ee11a2612b3@joelhalpern.com> Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 02:17:48 -0000 There are many different layers and all, or none of them could be called co= nfiguration depending on your perspective.=0A= Consider the current set of routes on a router. I think we can all agree th= at from the point of view of the Linux kernel, or a hardware routing chip, = this is configuration data.=0A= But from the point of view of an OSPF process it is operational data. OSPF = will reconfigure Linux every time the routes change.=0A= Even *static* routes may be considered operational data at an even higher l= evel (such as a network monitoring system).=0A= =0A= ________________________________________=0A= From: netmod on behalf of Joel M. Halpern =0A= Sent: Wednesday, 21 June 2017 6:19 a.m.=0A= To: t.petch; Robert Wilton; netmod@ietf.org=0A= Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-ne= tmod-rfc6087bis-13.txt=0A= =0A= I was going to just watch this, but I can't.=0A= =0A= To call protocol negotiated values "configuration" is to create a usage=0A= which will confuse MANY people. Even worse, configuring protocol=0A= learned values is liable to break things. To use one example, many=0A= protocols negotiate timers. The value that a given systems starts with=0A= is the configured value. The value that it learns from the protocol=0A= exchange is the operational value. In fact, you better not try to=0A= configure that value or you are liable to break the protocol.=0A= =0A= Yours,=0A= Joel=0A= =0A= =0A= On 6/20/17 1:51 PM, Juergen Schoenwaelder wrote:=0A= > On Tue, Jun 20, 2017 at 05:36:12PM +0100, t.petch wrote:=0A= >>=0A= >> Robert=0A= >>=0A= >> The definition of 'configuration' in netmod-revised-datastores-02 is=0A= >> very different from what has gone before in NETCONF and NETMOD.=0A= >>=0A= >> You start with=0A= >> 'Data that determines how a device behaves.'=0A= >> which is how I would have defined configuration before the days of=0A= >> NETCONF and which I imagine is how many who have not been exposed to=0A= >> NETCONF would still do. NETCONF narrowed the definition a lot; 'Data=0A= >> that determines how a device behaves' opens it up again.=0A= >>=0A= >> You add the qualification 'using "config true" nodes' which doesn't=0A= >> really mean anything in this context, unless you already know some YANG= =0A= >> models, and know what is modelled in this way and what is not and so can= =0A= >> work it out, reverse engineering.=0A= >>=0A= >> Coming to netmod-revised-datastores-02 with an innocent eye, knowing=0A= >> that the ground has moved, that some of my assumptions of the past 10=0A= >> years are no longer valid, then these definitions convey to me that=0A= >> configuration acquired from the system or from routing protocols, to=0A= >> take two common examples, will now always be modelled 'config true',=0A= >> that is the first sentence is the definition and the second - 'config=0A= >> true' - is the consequence thereof.=0A= >>=0A= >> Of course, if you come to the I-D knowing otherwise, then you may find a= =0A= >> different interpretation but I do not think that that is the obvious=0A= >> interpretation.=0A= >>=0A= >=0A= > Is your proposal to take out "This data is modeled in YANG using=0A= > "config true" nodes."?=0A= >=0A= > Note that the NMDA document further defines=0A= >=0A= > o conventional configuration: Configuration that is stored in any of= =0A= > the conventional configuration datastores.=0A= >=0A= > o dynamic configuration: Configuration obtained via a dynamic=0A= > datastore.=0A= >=0A= > o learned configuration: Configuration that has been learned via=0A= > protocol interactions with other systems that is not conventional= =0A= > or dynamic configuration.=0A= >=0A= > o system configuration: Configuration that is supplied by the device= =0A= > itself.=0A= >=0A= > o default configuration: Configuration that is not explicitly=0A= > provided but for which a value defined in the data model is used.= =0A= >=0A= > There are corresponding origin attribute definitions. (With the minore=0A= > caveat that the origin value for conventional configuration is=0A= > intended since this is the datastore conventional configuration=0A= > finally originates from.)=0A= >=0A= > /js=0A= >=0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Wed Jun 21 02:03:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC9E131BFC for ; Wed, 21 Jun 2017 02:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ot7-f8VoUBvZ for ; Wed, 21 Jun 2017 02:03:26 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8EC131BFE for ; Wed, 21 Jun 2017 02:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6912; q=dns/txt; s=iport; t=1498035806; x=1499245406; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=1Hg+JqNS/KQ/bwDXIf+uEfVqigLJ6SvcgnTWhWxt5Gc=; b=Gy1ZbHrdzkLNuqMnxBQF9oL1u4BzPLWi/PkWTpFpyvb74Z/8+RD8dteV VwPzmKaFB6e4lOs626a+vCLFRjnrdq1/GjAq77OrpF8vyvZd05bJx4cZe oAIRfGX0bgAH0Fgw+XtbTtlodmsYcZCOaiSpF1ng/I4TqIOfa5DkJu31k 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAABaNUpZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqBDY4Fc5EOlXiCESELhS5KAoMtGAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgEBATY2BAcMBAsSAwECLiciDgYNBgIBAYogCBCsH4tcAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGAWGbYFgK4J5il0BBJ5ik2KCCIVIg0sjhlCMSohHHziBCjAhCBs?= =?us-ascii?q?VSYcQPzaJagEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,368,1493683200"; d="scan'208";a="695301226" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 09:03:21 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v5L93LoX014782; Wed, 21 Jun 2017 09:03:21 GMT To: "t.petch" References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> Cc: netmod@ietf.org, "j.schoenwaelder@jacobs-university.de" From: Robert Wilton Message-ID: <9f2823af-51a3-6b38-89a0-72cf521f62ee@cisco.com> Date: Wed, 21 Jun 2017 10:03:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 09:03:29 -0000 Tom, Thanks for the comments, please see inline ... On 20/06/2017 17:36, t.petch wrote: > ----- Original Message ----- > From: "Robert Wilton" > Sent: Tuesday, June 20, 2017 1:35 PM > > >> Hi Tom, >> >> On 20/06/2017 12:39, t.petch wrote: >>> --- Original Message ----- >>> From: "Phil Shafer" >>> Sent: Tuesday, June 20, 2017 7:05 AM >>> >>>> Andy Bierman writes: >>>>> This draft addresses all remaining open issues, include the > rewrite >>> of the >>>>> opstate section. >>>>>> In YANG, any data that has a "config" statement value of "false" >>>>>> could be considered operational data. The relationship between >>>>>> configuration (i.e., "config" statement has a value of "true") > and >>>>>> operational data can be complex. >>>> The NMDA draft includes the following in its terminology section: >>>> >>>> - configuration: Data that determines how a device behaves. > This >>>> data is modeled in YANG using "config true" nodes. > Configuration >>>> can originate from different sources. >>>> >>>> - operational state: The combination of applied configuration > and >>>> system state. >>>> >>>> It would be nice to use matching terms, either by importing the >>>> NMDA terms directly, or by mimicing them in this draft. If your >>>> "operational data" means "config false" and NMDA's "operational > state" >>>> means both config true and config false, readers will be confused. >>> Phil >>> >>> Well, it would if the definitions in NMDA brought clarity but I > think >>> the opposite. >>> >>> 'Data that determines how a device behaves' seems clear until you > read >>> on and find that this excludes data learnt from the system or data >>> learnt from routing protocols. >> Please can you clarify. The text that you are quoting above is from > the >> NMDA definition of "configuration". >> >> Data learned from the system or routing protocols (for YANG config > true >> nodes) would be classified as "system configuration" or "learned >> configuration", which are sub categories of "configuration", and hence >> are not excluded from the more general definition of "configuration". > Robert > > The definition of 'configuration' in netmod-revised-datastores-02 is > very different from what has gone before in NETCONF and NETMOD. > > You start with > 'Data that determines how a device behaves.' > which is how I would have defined configuration before the days of > NETCONF and which I imagine is how many who have not been exposed to > NETCONF would still do. NETCONF narrowed the definition a lot; 'Data > that determines how a device behaves' opens it up again. > > You add the qualification 'using "config true" nodes' which doesn't > really mean anything in this context, unless you already know some YANG > models, and know what is modelled in this way and what is not and so can > work it out, reverse engineering. > > Coming to netmod-revised-datastores-02 with an innocent eye, knowing > that the ground has moved, that some of my assumptions of the past 10 > years are no longer valid, then these definitions convey to me that > configuration acquired from the system or from routing protocols, to > take two common examples, will now always be modelled 'config true', > that is the first sentence is the definition and the second - 'config > true' - is the consequence thereof. OK, I can see how one could take that interpretation, but I don't think that is the author's intention. We found that trying to define what "configuration is, or isn't", is hard, but still regard having a definition is important. In the end, I see that the real core of the definition is actually the config true sentence. I.e. the intention of the draft is to define configuration as the nodes in the YANG schema that are labelled as config true, and hence it is the marking of the node as config true that actually makes it configuration (at least in the context of this draft and NETCONF/YANG). So, do you think that it would help if the definition text was reordered to make the binding to YANG config true first and foremost? E.g. Old: o configuration: Data that determines how a device behaves. This data is modeled in YANG using "config true" nodes. Configuration can originate from different sources. New: configuration: All data that is modelled in YANG using "config true" nodes. Configuration is used to instruct how a device behaves. Configuration can originate from different sources. Thanks, Rob > > Of course, if you come to the I-D knowing otherwise, then you may find a > different interpretation but I do not think that that is the obvious > interpretation. > > Tom Petch > >> Thanks, >> Rob >> >> >>> I find the idea that the behaviour of a device is not determined by >>> routing protocols or a hot-plugged card an odd one. >>> >>> This definition is rather different to that in NETCONF and seems >>> unlikely to bring clarity so I think it would be a mistake to >>> incorporate it in rfc6087bis.. >>> >>> Tom Petch >>> >>> >>>> Also you say "operational state and other data such as statistics" >>>> which inconsisent. Under either set of terms, statistics are >>>> part of operational state. >>>> >>>>>> The original set of datastores defined in NETCONF (i.e., > candidate, >>>>>> unning, and startup) are not sufficient to fully manage a device >>>>>> ith multiple sources of configuration data. In additional, a >>>>>> separate datastore is needed to store operational state and other >>>>>> data such as statistics. Refer to >>>>>> [I-D.ietf-netmod-revised-datastores] for details on this new >>> "revised >>>>>> datastore" architecture. Guidelines for usage of the new > datastores >>>>>> (including the operational datastore) is defined in >>>>>> [I-D.dsdt-nmda-guidelines]. >>>> "not sufficient to fully manage" is too broad a claim. Can I > suggest >>>> a more positive spin: >>>> >>>> The Network Management Datastore Architecture (NMDA) defines a >>>> new set of datastores that improve visibility into the device, >>>> both in terms of the "intended" configurations values and the >>>> true operationally "in use" values. Refer to >>>> [I-D.ietf-netmod-revised-datastores] for details. Guidelines > for >>>> moving existing data modules to the NMDA are defined in >>>> [I-D.dsdt-nmda-guidelines]. >>>> >>>> Thanks, >>>> Phil >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> > . > From nobody Wed Jun 21 05:32:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB0A129AB0 for ; Wed, 21 Jun 2017 05:32:54 -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, RP_MATCHES_RCVD=-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 GNOOM8T8BrGa for ; Wed, 21 Jun 2017 05:32:53 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48FE1294C9 for ; Wed, 21 Jun 2017 05:32:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 725A9F78; Wed, 21 Jun 2017 14:32:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id FquLHRH8reil; Wed, 21 Jun 2017 14:32:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 Jun 2017 14:32:51 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 481802009D; Wed, 21 Jun 2017 14:32:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1Cc58KijEFe4; Wed, 21 Jun 2017 14:32:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8A262009B; Wed, 21 Jun 2017 14:32:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EF89D3FCCCEC; Wed, 21 Jun 2017 14:32:47 +0200 (CEST) Date: Wed, 21 Jun 2017 14:32:47 +0200 From: Juergen Schoenwaelder To: Robert Wilton Cc: "t.petch" , netmod@ietf.org Message-ID: <20170621123247.GC367@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , "t.petch" , netmod@ietf.org References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> <9f2823af-51a3-6b38-89a0-72cf521f62ee@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f2823af-51a3-6b38-89a0-72cf521f62ee@cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 12:32:55 -0000 On Wed, Jun 21, 2017 at 10:03:21AM +0100, Robert Wilton wrote: > > We found that trying to define what "configuration is, or isn't", is hard, > but still regard having a definition is important. > > In the end, I see that the real core of the definition is actually the > config true sentence. I.e. the intention of the draft is to define > configuration as the nodes in the YANG schema that are labelled as config > true, and hence it is the marking of the node as config true that actually > makes it configuration (at least in the context of this draft and > NETCONF/YANG). > > So, do you think that it would help if the definition text was reordered to > make the binding to YANG config true first and foremost? > > E.g. > > Old: > o configuration: Data that determines how a device behaves. This > data is modeled in YANG using "config true" nodes. Configuration > can originate from different sources. > > New: > configuration: All data that is modelled in YANG using "config > true" nodes. Configuration is used to instruct how a device behaves. > Configuration can originate from different sources. > I think this was true at some point of the internal discussions but I think it is not true any longer. I believe the fix is this (moving the config true statement to the definition of conventional configuration): NEW: o configuration: Data that determines how a device behaves. Configuration can originate from different sources. o conventional configuration: Configuration that is stored in any of the conventional configuration datastores. This data is modeled in YANG using "config true" nodes. ---8<--- snip ---8<--- In the current NMDA draft, configuration is a combination of conventional configuration, dynamic configuration, learned configuration, system configuration, and default configuration. Perhaps we need to create more figures: configuration | + conventional configuration (origin intended) + dynamic configuration (origin dynamic) + learned configuration (origin learned) + system configuration (origin system) + default configuration (origin default) I am not sure whether dynamic configuration (e.g., coming from an I2RS subsystem) or system configuration is necessarily restricted to config true nodes. By moving the config true statement to the definition of the term conventional configuration, we state something where we are sure the statement is correct. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jun 21 10:20:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7ED128B38 for ; Wed, 21 Jun 2017 10:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=yumaworks-com.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 CxbB7Kqiuda5 for ; Wed, 21 Jun 2017 10:20:43 -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 08E651289B0 for ; Wed, 21 Jun 2017 10:20:43 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id 77so143750866wrb.1 for ; Wed, 21 Jun 2017 10:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=S6Zjj0hnQGed5Iumh5ysk8c7bh7GsncTVSkBnF92FaI=; b=i0JHPxS8JUnVbE7m4YfeW3wa0yQY8vbX18K7p1kHjjAGWZb6VtWSBVgfDQdYhD9X2I W+kKFAXuNaWqlkeVMr6daXGwrVhlXHuJdi5GGJ2krbC562ryydkLtVMVZuvQMq/1r1rt CSGz7LhdiG8jDi3CwlnZvXuxKZg+UBgErDRnj+qbxEvmWDquee5PNOe5dn9I/K2dsaiq 5oV4J5X0Sx57YEo6h98pzIZ4oB23+SKAMAYbgIrFvbGYW3fu/EzZn1rFockobXDMIKW+ eWHoKrcu9o7FigpRX1QFsgmBFRRY2cURm89PSbymMYmuZ8xuR+nQxgycjWdIJuGG20sr j/Kw== 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; bh=S6Zjj0hnQGed5Iumh5ysk8c7bh7GsncTVSkBnF92FaI=; b=QqPP8HEhsN9DCnLdmnVnqTlgKGybVXxbEAZHomf2m9X0SNd+BF89b+fSxLei/fHnrz dCLDqX+26anEY1iMmFgKOJY/IOUv+Z/6bOABQQa/xjt55m8Ev5KLWz7a5lM2omhMzOxk W+cqxBxZi1Pys8+0V/BDJhbnDUujb9DRn6AcSPTGuDZnVVqJ9G+qonKkc/teVG/wiiGd RMKg8ldLIDI6gquRuVmquEGd5juTr5XXSm0EHnXX1a9azkjLFAlHJKuGxX7hoNSIm87z VBb5K4m3c8zZf7tiF2WW945CUctht+Y0h4Goxwn0PHfkbZ6IBZRoWtQkLAlW6ikrroZn zIjA== X-Gm-Message-State: AKS2vOzYsKc8IjypYrSSOgwyxDY+1uKhZkYZDBL/CazPntO06NWL7tZ/ QQqMdfxije0BVa7B+aiXnqhTv03XGvxE X-Received: by 10.28.30.3 with SMTP id e3mr7083832wme.60.1498065641542; Wed, 21 Jun 2017 10:20:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Wed, 21 Jun 2017 10:20:40 -0700 (PDT) In-Reply-To: <20170621123247.GC367@elstar.local> References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> <9f2823af-51a3-6b38-89a0-72cf521f62ee@cisco.com> <20170621123247.GC367@elstar.local> From: Andy Bierman Date: Wed, 21 Jun 2017 10:20:40 -0700 Message-ID: To: Juergen Schoenwaelder , Robert Wilton , "t.petch" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114b35086a3cce05527b960e" Archived-At: Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 17:20:46 -0000 --001a114b35086a3cce05527b960e Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2017 at 5:32 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jun 21, 2017 at 10:03:21AM +0100, Robert Wilton wrote: > > > > We found that trying to define what "configuration is, or isn't", is > hard, > > but still regard having a definition is important. > > > > In the end, I see that the real core of the definition is actually the > > config true sentence. I.e. the intention of the draft is to define > > configuration as the nodes in the YANG schema that are labelled as config > > true, and hence it is the marking of the node as config true that > actually > > makes it configuration (at least in the context of this draft and > > NETCONF/YANG). > > > > So, do you think that it would help if the definition text was reordered > to > > make the binding to YANG config true first and foremost? > > > > E.g. > > > > Old: > > o configuration: Data that determines how a device behaves. This > > data is modeled in YANG using "config true" nodes. Configuration > > can originate from different sources. > > > > New: > > configuration: All data that is modelled in YANG using "config > > true" nodes. Configuration is used to instruct how a device behaves. > > Configuration can originate from different sources. > > > > I think this was true at some point of the internal discussions but I > think it is not true any longer. I believe the fix is this (moving the > config true statement to the definition of conventional > configuration): > > NEW: > > o configuration: Data that determines how a device behaves. > Configuration can originate from different sources. > > o conventional configuration: Configuration that is stored in any of > the conventional configuration datastores. This data is modeled in > YANG using "config true" nodes. > > I agree with Joel that all protocol negotiated values should not be considered configuration. I2RS is somewhere in between configuration and protocol-negotiated values. We don't have a good term for it yet. There will be some protocol negotiation that is modeled in YANG and represented in a configuration datastore (e.g. ephemeral datastore). This data can be modified with configured values. The operational datastore reflects the actual values used. Maybe this is called ephemeral configuration? There will be some protocol negotiation that is not modeled in YANG and not represented in a configuration datastore, but the operational datastore can still contain these values. This should not be called configuration. Andy > ---8<--- snip ---8<--- > > In the current NMDA draft, configuration is a combination of > conventional configuration, dynamic configuration, learned > configuration, system configuration, and default configuration. > Perhaps we need to create more figures: > > configuration > | > + conventional configuration (origin intended) > + dynamic configuration (origin dynamic) > + learned configuration (origin learned) > + system configuration (origin system) > + default configuration (origin default) > > I am not sure whether dynamic configuration (e.g., coming from an I2RS > subsystem) or system configuration is necessarily restricted to config > true nodes. By moving the config true statement to the definition of > the term conventional configuration, we state something where we are > sure the statement is correct. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114b35086a3cce05527b960e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 21, 2017 at 5:32 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 21, 2017 at 10:0= 3:21AM +0100, Robert Wilton wrote:
>
> We found that trying to define what "configuration is, or isn'= ;t", is hard,
> but still regard having a definition is important.
>
> In the end, I see that the real core of the definition is actually the=
> config true sentence.=C2=A0 I.e. the intention of the draft is to defi= ne
> configuration as the nodes in the YANG schema that are labelled as con= fig
> true, and hence it is the marking of the node as config true that actu= ally
> makes it configuration (at least in the context of this draft and
> NETCONF/YANG).
>
> So, do you think that it would help if the definition text was reorder= ed to
> make the binding to YANG config true first and foremost?
>
> E.g.
>
> Old:
>=C2=A0 =C2=A0 o=C2=A0 configuration: Data that determines how a device = behaves. This
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data is modeled in YANG using "config t= rue" nodes. Configuration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0can originate from different sources.
>
> New:
>=C2=A0 =C2=A0configuration: All data that is modelled in YANG using &qu= ot;config
>=C2=A0 =C2=A0true" nodes.=C2=A0 Configuration is used to instruct = how a device behaves.
>=C2=A0 =C2=A0Configuration can originate from different sources.
>

I think this was true at some point of the internal discussions but I
think it is not true any longer. I believe the fix is this (moving the
config true statement to the definition of conventional
configuration):

NEW:

=C2=A0 =C2=A0o=C2=A0 configuration: Data that determines how a device behav= es.
=C2=A0 =C2=A0 =C2=A0 Configuration can originate from different sources.
=C2=A0 =C2=A0o=C2=A0 conventional configuration: Configuration that is stor= ed in any of
=C2=A0 =C2=A0 =C2=A0 the conventional configuration datastores. This data i= s modeled in
=C2=A0 =C2=A0 =C2=A0 YANG using "config true" nodes.



I agree with Joel that = all protocol negotiated values should not be considered configuration.

I2RS is somewhere in between configuration and protoco= l-negotiated values.
We don't have a good term for it yet.

There will be some protocol negotiation that is mode= led in YANG and represented in
a configuration datastore (e.g. ep= hemeral datastore). This data can be modified with configured values.
=
The operational datastore reflects the actual values used. Maybe this = is called
ephemeral configuration?

= There will be some protocol negotiation that is not modeled in YANG and not= represented in
a configuration datastore, but the operational da= tastore can still contain these values.
This should not be = called configuration.


Andy

=C2=A0
---8<--- snip ---8<---

In the current NMDA draft, configuration is a combination of
conventional configuration, dynamic configuration, learned
configuration, system configuration, and default configuration.
Perhaps we need to create more figures:

=C2=A0 =C2=A0configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + conventional configuration (origin intended)<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 + dynamic configuration=C2=A0 =C2=A0 =C2=A0 (or= igin dynamic)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + learned configuration=C2=A0 =C2=A0 =C2=A0 (or= igin learned)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + system configuration=C2=A0 =C2=A0 =C2=A0 =C2= =A0(origin system)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + default configuration=C2=A0 =C2=A0 =C2=A0 (or= igin default)

I am not sure whether dynamic configuration (e.g., coming from an I2RS
subsystem) or system configuration is necessarily restricted to config
true nodes. By moving the config true statement to the definition of
the term conventional configuration, we state something where we are
sure the statement is correct.
<= br> /js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a114b35086a3cce05527b960e-- From nobody Thu Jun 22 03:25:12 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A25128AB0 for ; Thu, 22 Jun 2017 03:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 0e1mSBImCPAm for ; Thu, 22 Jun 2017 03:25:07 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0095.outbound.protection.outlook.com [104.47.1.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21E1127698 for ; Thu, 22 Jun 2017 03:25:06 -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=LevZs6rOR1/mqgAebiESNbDlXv5ox22PXZnlBYInTO0=; b=UMizXxCOkk0KXzIEImO3iCMacl0atCdPPL8CqUnAw6tYVNRpMbIK8soLDafUzuU6x/LNOCNdj2gkBHqFQKkzQ6P0CCHVLrn5GRhFbIqN5hEaW9bWp1epj8w/IJGYs71HICR5OMSQbtnPkdLnC2HZd3Tybpe0K3xEdJO7KHr0rRM= Authentication-Results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Thu, 22 Jun 2017 10:25:03 +0000 Message-ID: <062701d2eb41$5057d220$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" , "Joel M. Halpern" Cc: "Robert Wilton" , References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> <20170620175113.GA2280@elstar.local> <5b9f1ec3-9adf-c465-f38e-5ee11a2612b3@joelhalpern.com> <20170620194019.GA2432@elstar.local> Date: Thu, 22 Jun 2017 11:21:14 +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.169.157.161] X-ClientProxiedBy: AM4PR0202CA0017.eurprd02.prod.outlook.com (2603:10a6:200:89::27) To AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15) X-MS-Office365-Filtering-Correlation-Id: e1986410-0492-4b07-6052-08d4b958f276 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 3:z26E+N0RCQheefosmAra5qpaY4SPeUeLX+3xTUP/HeW0mpFfk0pwwMhPgFfqLohpwkca9SXzl0wV+d9Yu6Sw3uWxc7HsOEYXek9Mxnazgag1LVI24ZJWSw5hC8WYssTMAeFpbaPh0hEXXwT4Vpb/jNX7UGPLz7MJhLUbb+Tii4fwjDVuZliCr9LSJH6wPWFxebAqjE/zt0/IleJ5MP2RXKLRdoLjHWUNVoXSokILA/7Q2diT9ypP4TFrCqnY9i/9HaRFfXkbflMTgdKJbKmOoFQ7MU3dMfdMI8p6+xJ9s8PsnARqtZM8JAuYKsYsFpEC/grGsuFIOjTRvbCUoVzMtA==; 25:bbAC4le9eoslUBThP1MM/FwWWK8fiYkLznIbqZDkLMULXu2GUiKz98koTWmc04fBWq8H/DaZIspiRZZAmfUSf+G3LvojBb65Q/eqEaqA+j1LrZOOjq6iigEXw8Np4XU9EJrT75sfsBCI0xgi1W8NYu2RFTiTQxbzvDxJObzroUnGF7lV/HZLzJNT2wk/qJjxHlIotDFepBnItwcW7wsA0CGINhV69GTpW9tlCyPG4YGHkc2BKDeTmYu2o0a0U8oI0cE/CYlQLvBV0T5eLTCZMy541rMwZ8srMIn6S0mOMtTsYRzOwaTD44oAhs1VzskCXpOaBF8TAG4Zc6L29kOUlYqZtYCuhF/j9jPrhmgpnBM2i8XVVKnZbfpwFMn0aDNHVvq0u1WPSAK0yqjMcxMHXaFAfBmGKchF/F2Jzt95sr3yfyvKwXJ56DYu7OSlhojeRGb4aIdcky4GRsbNJAiF0ALSHNXaJ3XiMaInucnOXJQ= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM5PR0701MB2993: X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 31:2s94sgZHeriIw7gCpzrrA5AxdDKHzv4jseTUBwRFyB+5XZzQuzdRGqNA5n/YmBDdTksTOjEEjZOtqdU5gFWAMyuMyjO/vr/ZPbYGixxzwrVefC2yd60nHJXGgdSSkeSaGFoOdnYIG8ErHc4jphWrGQF7Q3Xt/eIA51GOe3B+W+kpIJbcCo+f3dFNkGLJmE+FM3ZfN+LxOse2XQuuqSl67StdKQ2/yJ7e+2Ya12fbYsi9V/B8ZQSs5qnfuGbN/nq/d2nbzfcfY0M3Ou0/d7ykOg==; 20:ohZLvd3C2UKQsfIPQUGEfr4fSv2CcQgEvwW2GMjeRGhsAPAsFcbHbyRVpZP9T4hyPG3GsmDnaVm9AMkntrgSwZygV42K4fr3BE/lyxhBB2HC2Tb9Y4lRH/cgz0uWUgNfPadksf6ExYYApuCXz42Lc7+5c+081AIqi437vuULZlI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2993; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM5PR0701MB2993; 4:JuwTynfg5MKsuYiZ3CUyseQ4P5ZG/JWjccGbko?= =?iso-8859-1?Q?6gnXiMDEdfLdiYKKf3CZJ+6UGmi0gZvo5ZSMOMMtRRu7DgCgiB9yCnYJt1?= =?iso-8859-1?Q?4AT9UPQLiP5vpWOSnlqK+NEUAXUurWVmdh/tOhMIb5Ay3POYszmz4QHK1t?= =?iso-8859-1?Q?sY2Oy69eiiv8NRwpAigKMKcLpw0NAJu5n9VPmlQrp8+EqK5Djb/5oCEgqk?= =?iso-8859-1?Q?HdDC5d/8hY5nErFp2zVOGfialfuSA4IZl2BMbK4a/wF6lYfBMIrxFZPxLL?= =?iso-8859-1?Q?S7sZi2yUkBvYjiRJgc57Tiy8FKOJPSWqZKuLf9n5W1CjbnMARUCvOmok4Z?= =?iso-8859-1?Q?GACDejkcO9m7lqbiBaw7LycO60ZUD8Vki+galKxyPowNL/izhJYQcYLEqk?= =?iso-8859-1?Q?RaYXOBjDps+d/n5fgwZaHTIuL9i3UXccjC2iT/y8cQerwuz5AbPYexHUrn?= =?iso-8859-1?Q?Ja1J7yMnISYyXLCfl1XqJgXBNnFYw3HDz/ZZ+6o6NSt24DEyUbsk+8/aJS?= =?iso-8859-1?Q?oHqFQAObHgO0MiygG2NPYZxKdQCia5XHMze1P033WgpavcbhwuVqVdpOZ4?= =?iso-8859-1?Q?BJ7w+wijDYeEKoKGxSQwqA+UkdiNaXMs2fwexG9u+HVPa72yv2OgGGmL0x?= =?iso-8859-1?Q?46mWCO6hw9vvIF+XCi9HhqiEHF3UiMHeU0K/fAGDxk6SJXzaEilq0fXxbD?= =?iso-8859-1?Q?KRmRJDCdf7k8ocLQ6xHkZYsrwO/MicaVUj9zNw9Mq8U2RLIX07er+J8OKx?= =?iso-8859-1?Q?BoczSSzqW4etAUH0cDxJsH2JkTFNVkUBC3UIC70ROmqeN0+558rICVRaK2?= =?iso-8859-1?Q?NVftxLdkuwycw9JTowaxC6njUYuCA847+fO95oC8ts0Ll6deU0GNGjVbZ3?= =?iso-8859-1?Q?Mhh454glIlP3+Hw/N1+bEXXutmykFYsfssjT597Q5ctS3ex+yJb5hkxQ9/?= =?iso-8859-1?Q?HzVpKV7Ai7kI5i+rhSyTTLeusVKFDC8HhSAJuZfZzlTyZmn8hmViwzdXUv?= =?iso-8859-1?Q?H2ujk3CLL3pJN3UnFgAbyEoo+UM7Rgj7LFc3Y2poNtNfV7ejPI1oF81l2g?= =?iso-8859-1?Q?mbasEFdGR+H+CuRfDd01UfO4ucU3U50nhdUyzj55ObJuowFP0UNXqF5HHn?= =?iso-8859-1?Q?Ux+MlBkWd+7CnBk0EhNXuscD2WF/LY2FpUNuxBdJdeegvXEafC0D0Q0Ejb?= =?iso-8859-1?Q?/RE+BCKkBdK1?= X-Forefront-PRVS: 03468CBA43 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39410400002)(39400400002)(39860400002)(39840400002)(39450400003)(39850400002)(377454003)(13464003)(51444003)(24454002)(230700001)(2906002)(5660300001)(84392002)(50986999)(81816999)(44736005)(76176999)(6486002)(33646002)(81686999)(230783001)(93886004)(81166006)(8676002)(189998001)(229853002)(4720700003)(23756003)(6116002)(61296003)(50226002)(478600001)(42186005)(3846002)(50466002)(6666003)(6306002)(38730400002)(6496005)(6246003)(4326008)(25786009)(62236002)(54906002)(66066001)(305945005)(44716002)(47776003)(86362001)(7736002)(53936002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2993; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM5PR0701MB2993; 23:aD627S4dmXj1bWEHsI7mv4cEK3ZMRB0R6iRiO?= =?iso-8859-1?Q?+C97S5IUfpiJUP0ea01eo9lUPffujR5EjwOvzQ3msiY7U5KHbe/qtuOb11?= =?iso-8859-1?Q?0kIPf+UJ050nDnupZu0tqdEIea8oCm9/gDLAaiRdDkAnyL3pZwmce7MWMG?= =?iso-8859-1?Q?d5sV12B41LJqZLcdOjSfReOTanyzSy49PehFqVI+TCtUnS5DW4Bh4k4y+W?= =?iso-8859-1?Q?FrdTtkVJjUlHGj9VgWUsjI2zTMGc1BpsVSmb9zgQLyE627PJUZGMWA8OjB?= =?iso-8859-1?Q?IL8DCch4CZCBerCBnGAPDucn/PXH7PqFgWUoI9C7HwBcUti8SRvogAQ+lh?= =?iso-8859-1?Q?2MVHQNH1W6ig2RlHpiU1Fl2JIEUrPnFDvAOW22M35wMI0gG1SlyXIKw3ak?= =?iso-8859-1?Q?ZBjz65nC7b6P9NwQUqqceiNzYlrXEMyqv9O65Uy5iF/wvr4WQdX8A8apC8?= =?iso-8859-1?Q?RTz44GmoL7BBlYtYA2LMZDEWpU0ORIv9Ggkm9EkXV7PbhT4voRJv8oPVSr?= =?iso-8859-1?Q?qvvMOu6crs1CqKhKfev9uxpRZuHej8BySiCPCYZzAeLKfrCp00C+Ei7bpB?= =?iso-8859-1?Q?i1iKYA5X4UtDz23wD/DYX2xZTD3sCxt4sFpgAoxd0BrIYRs8CtOXObvVjz?= =?iso-8859-1?Q?p0egUgZWtmQrFOGzkuoQsNwubq++i1vowcVH+h7ui3rVkQ94jYPZ6ILjTH?= =?iso-8859-1?Q?SaqgrtJXg67Gs2hEsuFp/N6ou9ZEESiEuyTMamzau6ZIfdGgC6g+oaddOE?= =?iso-8859-1?Q?opbfHVyO+6plCLposKf+4Hu14i1V3ClK0eW5v9kp22VyXor2F64y3lMxcw?= =?iso-8859-1?Q?1zSuHy4dqbOuhATIrBig0mPZSwv/hu5/jXed5kTnP4klRLnKAo0/6+/iNk?= =?iso-8859-1?Q?KlSaHQFbV9d2JS7nDWYIIlTAg7JMohIREN5ltGLQnx+BaRLpTdKEAKWX6Y?= =?iso-8859-1?Q?nSOWVlNvZw4GGtJB+B4lU0/d73VbhTOepQnUyang0MV7GF/BzRki7HVR3P?= =?iso-8859-1?Q?pK1NRUevA9x1lua+W8zynkuMJabYB3hCYwFavfhTgzMrQ1mQtdKGEIA6xR?= =?iso-8859-1?Q?1stZoYCEq4eN+qfCyXjfcE7XGPdF8Zga//S0Kq447jkMz6xACeaAjmUZo5?= =?iso-8859-1?Q?VNvbFlw5DbjVKZHsLdK0FAJbkv7H7CudPIou9BFHhcB7UW7iOaWrdjNTw1?= =?iso-8859-1?Q?iSRIuNWZlldqHfCAv45iu+AUE/V22rgPiy8g3+HcXmInR5YfnyTcY69aFu?= =?iso-8859-1?Q?bFZ+7FTgzb/bKv1YV+NXUdWxd/TLIBD0TrUuJ3ATRbu/qVQeY+VIgHlAWe?= =?iso-8859-1?Q?QPr5gn7eal+eh64B88mqfr5Fq7lmxQTXvo6Q+cr0+DJbHcrNeGYmCO3N3q?= =?iso-8859-1?Q?I18PtvjLJR9SW0K/4YtLsB8AU2CJYWZ?= X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM5PR0701MB2993; 6:lVzpd1K2Gm/r8xExTwmMdF1SwLzA6ErkwQ9WwL?= =?iso-8859-1?Q?BjNqvt+IofXFIJvFHCiH3x9rd1qtggZbIQ0++gdBRoh1NvR4i1OiR4wKaU?= =?iso-8859-1?Q?xzT5VcUrnjDaFSnp+rugxBRyuSXKy33cTafBrV+GOPTwEAbcYYnxTNGg9M?= =?iso-8859-1?Q?YNrMTe/rqrz9VGZMANbomfyuk/NcdcgZ0IQF1fl+fYLYaLZtEzgwkhHgr1?= =?iso-8859-1?Q?sOnOXQc10YqS46ih/E1Whzw1jppkasRc6fxiRkbbWpYw2GN57SlW5MugQZ?= =?iso-8859-1?Q?gtuy7t5AXA37sbYWG8pczbcJKtbvCDXSAdRafo/Xc2lFpWNb3rA/wnFWuY?= =?iso-8859-1?Q?03DLEVThKpgyadgLDPZg1V8hGaRLqBhAh0thjwVAHQZSt4yezMT7kth/WU?= =?iso-8859-1?Q?A+AGyE5DPcNVPgnqOUA2I1U8U+aNTGcsgpm9rvWvls16387GWRE4DQMSZL?= =?iso-8859-1?Q?mxzFgguFh4jiMXL1jDRjJvbcRUwIBw2Rf62LqsixDG5WHVdnzjTaFF23q9?= =?iso-8859-1?Q?uW8Zagt1/TEoLVqJzp5mRCp7wFrBKQNGOsXpscDCzFkCxqpdBmLWaWbWy9?= =?iso-8859-1?Q?pS8yadniEF1Ndh7nL6nN2jB8QbRSv+afBXdr+g+JBlSlyQ6xBhzvjqqGrs?= =?iso-8859-1?Q?C1wJE8LQdj9wacoQqpsQFBoW0PNerFZ7PJ/DSnKVv4aXKjtTSi0jGLVuqm?= =?iso-8859-1?Q?wXyYGzgkgoNIVhYhVE0eJ6FEAX+h39421nbeeophGfK/dz2DUcFw5D1w0I?= =?iso-8859-1?Q?M9swc6BpU0MjTuJZ/2EZKUfUF44vXZOpd5is+mDoUP42wo+81+hhBtyc+R?= =?iso-8859-1?Q?zcqY1skAgJHAJZSvDggwNC1wFWzPADl/MP4EV5ykR4vQFm0g5xzi/X9Qz0?= =?iso-8859-1?Q?v3zW/Tk2MIKqKkDHlz3O4+Zu8T/fh2FJ1m5Rr6CEIzyg/hgnzxfsKICJOf?= =?iso-8859-1?Q?2JK49zyHWfxa7Zwr7EyBK6p+tuj0jL4nOCjs7D/0EHwPDyFFpiE439Miaq?= =?iso-8859-1?Q?N7L8ofab2T4KnuKjmOTrKHjd3QjiYY4u7pWAQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 5:EPd1mZ9HoiybMz2m5+ALOY+GGXxJWLN8tz8G4gMHz/tUzL+8xJahFZ+Xu8FbK6ibi8S53nC60lBff/0BuvMSGcyDt3dZYTacpq54c9NKE7TBMkKXfAC27PI5idv9MMUfPUm6gMspE3Yh+Db3SiDkUnS8fT7ZRod9rEJfpZrG75IWu/V53Z/C0ICUttGGDu/2wYgD4OmFOn5Va9OZfh23pcOIyNz+GDkvdWE0CG6wMmynCszZqpdHJ+BAKB/wxVCh331IS7snJo52lLeIzR+uIHY9+syRfD1m6xrn0pOkGarVGBe1YycylXILO7Lda9kqVh5kebbLv9j1xmxsfPrTVnL6d/a8ofcePt/VgbzUW39Ill5UADtFnsyEP77l8zVfSKeWTGOe9OiIyLw+jf33fPRxhjvvytQWkltl7+CiDgqtgiNf2BxEZZEbDXXd7ykVpSZ8xuklF9xIPOxEieFI1jAe/VxRD4VeQ/+/74pNPHgXkdYdp5rY/1QqFqgWg2vm; 24:72h98g+tzBy3DkAwtKmJBhoUhMpqUt4mTk1DDzomFzAhi7MndYllsy0vU6Jv3Hi+wghnAlxRj50efO0K+9gD8jX8qndCK6Z8zfAO1Ldea1Y= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 7:ZFSGjdbN6W0urrDf1Bqmjqmad0NtERntXIxcL9DRxdRsKBjaci7UUnx/ZxOd2YNHLEhRW4GjFrNc5L8iRDrgTmCBCxredXeyPfnQc78+/AmfaIDVbJmgtmw9GOSKsf+8/v+VjS9dW85bqvwqWU0SS6m8Ljb6ovGuNtp3PZIySZOFf4O9ghioTlfP+2OE+xA4+zEkI/W1ofhugQTaX1CZO/aGACFV9B66fqejdXa0rE0j3wXx3RmQfgVwrzitWPKDYYRPfxvBNmyVpb+RqJEBzAIAribz5GZgBQ0KMfe4TkRmmfysJHPXA6EYADQi4pQwXXAXxVWXaGGaZfO0dKdzuBJFSJfvwT2Dac08dRrWl+smOjx3oTNiJ5x4t5GB87w4uR9fjy+la+SE7mNmCmDkyyVrPO7I0N9WCnMToyfvg4P1E48pY1mV43E+ynrPRY9g2mnZj37ydUFUFuTfWv1eNQ5X/PGbGKdjYnXn/eq4XOyanO7F1SX8QD0ApPKUy8Cwm2pNC/sX/E7o+EIZF5l/0M6oN8aURFKbMq+hfxRSigMpQU6J8sWp+efcYipOkCbJCVZpPeFjXfbUaK8cFbS0LD435/W9mD6re1HuvXdE0/4ksliMRbDJQyJx3H2rYdqARx6gPbMGkjy0ggdXDqwBOLO26NIJzPt7E+SvodfwapaOXATpiR3E24QA8Wl7kNi8AgPbsDiX+TczxfZfOUcFLZEwT05Z8GWIMFE8mmtNIRYzn0Yd7o1sKD2OJ0TJE7uIxske+a1yPhCnj6PWWf0wj16FZRvx/Ju1sKMNOV+tpIo= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2017 10:25:03.8874 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2993 Archived-At: Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 10:25:11 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Tuesday, June 20, 2017 8:40 PM > On Tue, Jun 20, 2017 at 02:19:32PM -0400, Joel M. Halpern wrote: > > I was going to just watch this, but I can't. > > > > To call protocol negotiated values "configuration" is to create a usage > > which will confuse MANY people. > > There are people who have a broad concept of configuration and there > are people who have a narrow concept of configuration. There is not > way to resolve this. All we can do is come up with a terminology that > is consistent and can be used consistently. Juergen, Robert, This is what triggered my post (which I have been mulling ever since ietf-netmod-revised-datastores appeared). There has been a narrow (IMHO) definition in use for over a decade to whit 'Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. ' which I have accepted as the basis of this work (having previously used a much wider definition) . 'Data that determines how a device behaves' seems to me a much wider definition encompassing much of 'state' as has been defined for the past decade. I don't expect to have to read the rest of the I-D (about the kinds of configuration) to find out that the definition does not mean what it appears to say; I may have to read on to fully understand it but the words as written seem to brook no misunderstanding! Having ' This data is modeled in YANG using "config true" nodes ' sort of suggests that the original definition holds sway and so contradicts the previous sentence. And for this sentence to make sense, a reader would really have to understand the debates over configuration, state and how to model them that have been going on for so long which means that regardless of how true it is, it does not really belong in a definition. There is no reference back to the previous definition, as to whether or not the latest definition is meant to be the same or not. I find this confusing. I think that the previous definition has to appear in this I-D, since it has influenced so much work, and this I-D then needs to go on to say 'We are revising it .. or 'We are not revising it ... I have read the later posts but this one seemed to catch the crux of my discontent. Tom Petch > > Even worse, configuring protocol learned > > values is liable to break things. To use one example, many protocols > > negotiate timers. The value that a given systems starts with is the > > configured value. The value that it learns from the protocol exchange is > > the operational value. In fact, you better not try to configure that value > > or you are liable to break the protocol. > > Nobody proposed this, please take a look at the figure in the document > to understand the information flow and where the distinction is made. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Thu Jun 22 03:25:30 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFD81293D6; Thu, 22 Jun 2017 03:25:28 -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 HcTApVXPKyCF; Thu, 22 Jun 2017 03:25:20 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3101292C5; Thu, 22 Jun 2017 03:25:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 7F3D01CA533; Thu, 22 Jun 2017 03:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ls3tEoeqlQb2; Thu, 22 Jun 2017 03:25:02 -0700 (PDT) Received: from [192.168.1.127] (host86-158-252-85.range86-158.btcentralplus.com [86.158.252.85]) by c8a.amsl.com (Postfix) with ESMTPSA id 34E791CA530; Thu, 22 Jun 2017 03:25:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: William Lupton In-Reply-To: Date: Thu, 22 Jun 2017 11:25:16 +0100 Cc: Benoit Claise , stefan vallin , Martin Bjorklund , "Deborah Brungard (dbrungard@att.com)" , ccamp-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4873921A-9782-4943-A076-C8D9E79E3991@broadband-forum.org> To: netmod@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [netmod] draft-vallin-netmod-alarm-module status and plans X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 10:25:29 -0000 Dear all, We at the Broadband Forum (BBF) would like to reiterate our interest in = the draft-vallin-netmod-alarm-module draft. We will also have some technical comments / suggestions (internal = discussion is ongoing) that we will share with NETMOD as soon as = possible. Thanks, William > On 31 May 2017, at 13:08, Benoit Claise wrote: >=20 > William, >=20 > This was discussed with the authors, the NETMOD chairs, and the RTG AD = Deborah. > The advice was for the authors to raise the draft in ccamp and try to = progress it there. >=20 > The authors updated their draft to version 2 and pinged the CCAMP = mailing list = (https://www.ietf.org/mail-archive/web/ccamp/current/msg18124.html). > =46rom that email thread, it seems there is interest in the work, but = where to do the work is not clear. >=20 > My advice to the authors: continue progress this work and if CCAMP is = not interested or consider this work too generic, bring it back to = NETMOD and we'll follow normal WG process. >=20 > Regards, Benoit >> All, >>=20 >> I heard from Kent that = https://tools.ietf.org/html/draft-vallin-netmod-alarm-module was moving = to CCAMP but I don=E2=80=99t see any mention of it at = https://datatracker.ietf.org/wg/ccamp/documents (although it is shown as = a dependency at https://datatracker.ietf.org/wg/ccamp/deps/svg). Is any = more info available please? >>=20 >> Thanks, >> William From nobody Thu Jun 22 04:01:26 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115FA128DE5 for ; Thu, 22 Jun 2017 04:01:25 -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 xFN4xjwHf__p for ; Thu, 22 Jun 2017 04:01:23 -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 A3B0D127B31 for ; Thu, 22 Jun 2017 04:01:22 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id r103so18394847wrb.0 for ; Thu, 22 Jun 2017 04:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=mDBhfqvWlJHliwMvVFjPwrgPE3k8TH9aRkcOIbXkvK4=; b=vUhL91FrEEmYJ3lAQty4ywMgZFAEOLfGOegkMUTJeE96n6dL7H7ySJXkFOJQ4qhech jehbtjI3IqMWy/282BPz8VtnwSmMr1OuwmtbgfklurvI3y2VLG+sJRcbijofcqBCp4Wc 7D1sEO7AgnNNF3yOsA4Kn389nH3bwoubQgn80XLRnHI6ShJVh9Mh+T2kDIj8jCAj9miN qtPWkO1fvvZbfFoWUnPKYstD429EEmO5O6cBuHHXaJ/zWp3eYWWei1WpdRwZKXPWMKz8 /bMKin9cq5+7YEqUhUq8zpdcRH9uAfY6MngtpZ98QjwvtEoaJn/KXar3w/RZ+mr0VlHZ 6kbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=mDBhfqvWlJHliwMvVFjPwrgPE3k8TH9aRkcOIbXkvK4=; b=ENIBxvsmdm1i1JHL7K+ixpAn7acZXEUuK4PE3g9GXxeIj6i/btWYqG3A9LnqOZNN6o XFoxC6dnPZaOeZYFFG6S1HAMODVuak5P2KUoQfcDPDtBfiGxWS2CRbKxlq91ULBAVeKe k1PPLXAVhb7dTTNse1jy+6Hd8dwlCaxGMlUr96W1xWcg4etrJlaLSP7/Tn6/RTGJGjma PNEHc2Xr24fv/6ve09DPrhAZGjsaAJGIR8KxeCej49OFZOY+5Sg1m7NT2MEdkyeH0vFW vvmGKCi9D7LIHzRUGhDZ1G3zP2KfeDqeCYm3AzG8rPX1CQEP/hKeiTg5eNEBjKgnRvKY ZNCw== X-Gm-Message-State: AKS2vOwfS6SA+gPDcEOxUB4DwqbIYcPx7qqoAAFes8siYhFXXKWXokLg Iws2FYGDU7yI/A== X-Received: by 10.223.171.69 with SMTP id r5mr1682971wrc.57.1498129281137; Thu, 22 Jun 2017 04:01:21 -0700 (PDT) Received: from DESKTOPFLHJVQJ (p57A7772E.dip0.t-ipconnect.de. [87.167.119.46]) by smtp.gmail.com with ESMTPSA id 29sm1895931wrv.23.2017.06.22.04.01.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jun 2017 04:01:20 -0700 (PDT) From: "Mehmet Ersue" To: "'t.petch'" , "'Juergen Schoenwaelder'" , "'Joel M. Halpern'" Cc: References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> <20170620175113.GA2280@elstar.local> <5b9f1ec3-9adf-c465-f38e-5ee11a2612b3@joelhalpern.com> <20170620194019.GA2432@elstar.local> <062701d2eb41$5057d220$4001a8c0@gateway.2wire.net> In-Reply-To: <062701d2eb41$5057d220$4001a8c0@gateway.2wire.net> Date: Thu, 22 Jun 2017 13:01:19 +0200 Message-ID: <00aa01d2eb46$e13f5d30$a3be1790$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHoIuNafM4VaG3sqQjNsDJwOa8ZUgNI/lI8AtkW4VsB5kCHOQHfAzmYAdP4quUCZqwVgAGE7XrAoYkNq9A= Content-Language: de Archived-At: Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 11:01:25 -0000 > Having ' This data is modeled in YANG using "config true" nodes ' sort of > suggests that the original definition holds sway and so contradicts the > previous sentence. And for this sentence to make sense, a reader would > really have to understand the debates over configuration, state and how to > model them that have been going on for so long which means that regardless > of how true it is, it does not really belong in a definition. > > There is no reference back to the previous definition, as to whether or not > the latest definition is meant to be the same or not. I find this confusing. > > I think that the previous definition has to appear in this I-D, since it has > influenced so much work, and this I-D then needs to go on to say It is indeed confusing to the reader if a document referring to a standard track RFC defines and uses a term differently. I agree that revising a term might become necessary though the revision should be introduced properly. > > 'We are revising it .. > or > 'We are not revising it ... > > I have read the later posts but this one seemed to catch the crux of my > discontent. > > Tom Petch > > > > Even worse, configuring protocol learned values is liable to break > > > things. To use one example, many > protocols > > > negotiate timers. The value that a given systems starts with is the > > > configured value. The value that it learns from the protocol > exchange is > > > the operational value. In fact, you better not try to configure > that value > > > or you are liable to break the protocol. > > > > Nobody proposed this, please take a look at the figure in the document > > to understand the information flow and where the distinction is made. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jun 22 05:45:40 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF04129404 for ; Thu, 22 Jun 2017 05:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5mTXUI_qFfd for ; Thu, 22 Jun 2017 05:45:35 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9D11287A0 for ; Thu, 22 Jun 2017 05:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10786; q=dns/txt; s=iport; t=1498135534; x=1499345134; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=SXBpygG4l/WVYO0t/kiqlgBp5h66GNdTEgOk5oPciJo=; b=gqZjKrYxOH9qNNENQIq+6AN1lVyNMQEOXuLlIxBPNNPaObZF0KhVFkxl KsKnLiiNGVwXJF1S2loH8XujHyv/AZ3FKaTrlE/WN5TwUsg7C8lK7TKQW 3Ph2hRToPLXLybc54uwY7yqWCnaYa9yX6PmIXbqvdbDZurMVVUCnSghyu k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQDOuktZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhDqBDYNsihlzkG2ILIgihSqCESeFM0oCgzwYAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?DAQIjQwsYHAMBAhcBAQwGAgIhLAIIBg0GAgEBihADFRCrbIImKoMqg18NhCYBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGgWDJ4NMgguCeYJXIIITDBwBBYJFgmEFlx2HCzu?= =?us-ascii?q?HM4ZsXIRnggmJE4ZziSWCOm2ISh84gQowIQgbFR+CfIQ/PjYBhx8NF4IZAQEB?= X-IronPort-AV: E=Sophos;i="5.39,373,1493683200"; d="scan'208,217";a="652765265" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2017 12:45:32 +0000 Received: from [10.55.221.38] (ams-bclaise-nitro5.cisco.com [10.55.221.38]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5MCjVo2019680 for ; Thu, 22 Jun 2017 12:45:32 GMT References: <149382509814.21435.13312408514705930156.idtracker@ietfa.amsl.com> To: NETMOD Working Group From: Benoit Claise X-Forwarded-Message-Id: <149382509814.21435.13312408514705930156.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 22 Jun 2017 14:45:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <149382509814.21435.13312408514705930156.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------858A733B6B2AC572BA7D2907" Content-Language: en-US Archived-At: Subject: [netmod] Fwd: New Liaison Statement, "Liaison to IETF on IP Services Approved Draft 1" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 12:45:39 -0000 This is a multi-part message in MIME format. --------------858A733B6B2AC572BA7D2907 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit FYI. Regards, B. -------- Forwarded Message -------- Subject: New Liaison Statement, "Liaison to IETF on IP Services Approved Draft 1" Date: Wed, 3 May 2017 08:24:58 -0700 From: Liaison Statement Management Tool To: Benoit Claise , Alvaro Retana , Alia Atlas , Deborah Brungard , Warren Kumari CC: Alvaro Retana , Deborah Brungard , nan@mef.net, Alia Atlas , Warren Kumari , The IETF Chair , ssteiff@pccwglobal.com, rraghu@ciena.com, Benoit Claise , Raghu Ranganathan Title: Liaison to IETF on IP Services Approved Draft 1 Submission Date: 2017-05-03 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1521/ From: Raghu Ranganathan To: Warren Kumari ,Benoit Claise ,Alia Atlas ,Alvaro Retana ,Deborah Brungard Cc: Alvaro Retana ,Deborah Brungard ,Alia Atlas ,Warren Kumari ,The IETF Chair ,Benoit Claise ,Raghu Ranganathan Response Contacts: rraghu@ciena.com, nan@mef.net, ssteiff@pccwglobal.com Technical Contacts: Purpose: For information Body: Following our previous liaisons, we would like to update you on the progress of the MEF IP Service Attributes project. A new Approved Draft of our specification for IP Service Attributes for Subscriber Services is available, which can be accessed as described below. Note that a corresponding specification for IP Service Attributes for Operator Services is in progress but an Approved Draft is not yet available. In the course of our work, we have reviewed some of the internet drafts from the L3SM working group that preceded publication of RFC 8049 ("Yang Data Model for L3VPN Service Delivery"), and we used this as input to our specification. Now that RFC 8049 is published, we intend to review it again to ensure our work remains aligned. We would appreciate your review of our Approved Draft, and in particular any assistance you can give in identifying areas where it may conflict or be otherwise misaligned with RFC 8049. Note that the scope of the current IP Service Attributes project does not include definition of a yang module; however, we expect that a future project will include specification of a yang module based on the service attributes defined in this document. It is our hope that such a module can be defined as an augment of the module defined in RFC 8049. MEF’s liaison partners may access all MEF approved drafts as follows: https://mef.net/liaison-login Username: mef Password: M3F3030 The next MEF meetings are: July 24 - 27, Toronto, Canada October 23 - 26, Raleigh, USA Attachments: L00263_001_LiaisontoIETFonIPServicesApprovedDraft1_Ball_Ranganathan.pdf https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-05-03-mef-ops-rtg-liaison-to-ietf-on-ip-services-approved-draft-1-attachment-1.pdf . --------------858A733B6B2AC572BA7D2907 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit FYI.

Regards, B.


-------- Forwarded Message --------
Subject: New Liaison Statement, "Liaison to IETF on IP Services Approved Draft 1"
Date: Wed, 3 May 2017 08:24:58 -0700
From: Liaison Statement Management Tool <lsmt@ietf.org>
To: Benoit Claise <bclaise@cisco.com>, Alvaro Retana <aretana@cisco.com>, Alia Atlas <akatlas@gmail.com>, Deborah Brungard <db3546@att.com>, Warren Kumari <warren@kumari.net>
CC: Alvaro Retana <aretana@cisco.com>, Deborah Brungard <db3546@att.com>, nan@mef.net, Alia Atlas <akatlas@gmail.com>, Warren Kumari <warren@kumari.net>, The IETF Chair <chair@ietf.org>, ssteiff@pccwglobal.com, rraghu@ciena.com, Benoit Claise <bclaise@cisco.com>, Raghu Ranganathan <rraghu@ciena.com> 


Title: Liaison to IETF on IP Services Approved Draft 1
Submission Date: 2017-05-03
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1521/

From: Raghu Ranganathan <rraghu@ciena.com>
To: Warren Kumari <warren@kumari.net>,Benoit Claise <bclaise@cisco.com>,Alia Atlas <akatlas@gmail.com>,Alvaro Retana <aretana@cisco.com>,Deborah Brungard <db3546@att.com>
Cc: Alvaro Retana <aretana@cisco.com>,Deborah Brungard <db3546@att.com>,Alia Atlas <akatlas@gmail.com>,Warren Kumari <warren@kumari.net>,The IETF Chair <chair@ietf.org>,Benoit Claise <bclaise@cisco.com>,Raghu Ranganathan <rraghu@ciena.com>
Response Contacts: rraghu@ciena.com, nan@mef.net, ssteiff@pccwglobal.com
Technical Contacts: 
Purpose: For information

Body: Following our previous liaisons, we would like to update you on the progress of the MEF IP Service Attributes project. A new Approved Draft of our specification for IP Service Attributes for Subscriber Services is available, which can be accessed as described below. Note that a corresponding specification for IP Service Attributes for Operator Services is in progress but an Approved Draft is not yet available.

In the course of our work, we have reviewed some of the internet drafts from the L3SM working group that preceded publication of RFC 8049 ("Yang Data Model for L3VPN Service Delivery"), and we used this as input to our specification. Now that RFC 8049 is published, we intend to review it again to ensure our work remains aligned. We would appreciate your review of our Approved Draft, and in particular any assistance you can give in identifying areas where it may conflict or be otherwise misaligned with RFC 8049.

Note that the scope of the current IP Service Attributes project does not include definition of a yang module; however, we expect that a future project will include specification of a yang module based on the service attributes defined in this document. It is our hope that such a module can be defined as an augment of the module defined in RFC 8049.

MEF’s liaison partners may access all MEF approved drafts as follows:
https://mef.net/liaison-login
Username: mef 
Password: M3F3030

The next MEF meetings are:
July 24 - 27, Toronto, Canada 
October 23 - 26, Raleigh, USA
Attachments:

    L00263_001_LiaisontoIETFonIPServicesApprovedDraft1_Ball_Ranganathan.pdf
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-05-03-mef-ops-rtg-liaison-to-ietf-on-ip-services-approved-draft-1-attachment-1.pdf

.
--------------858A733B6B2AC572BA7D2907-- From nobody Thu Jun 22 06:02:41 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0227E128B8E; Thu, 22 Jun 2017 06:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 ExnX0AQOQl-y; Thu, 22 Jun 2017 06:02:38 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0124.outbound.protection.outlook.com [104.47.38.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBB21243F3; Thu, 22 Jun 2017 06:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/dZlqTVqipnXg1s6FeBHdas6r9fmUDvvNNqxo5T+AcA=; b=Z0H+it1cU6aHbbjqsW7rbTQhL3nNkjWhQ2FP9EbYX0wMaNE/zPunvcCywDx3XHQKtnNrRlTD4LdpGrgMVvAi3VwdTchA0A/b77n2TkVK/sf2gRg6OU2sulkRouW4MJ/CdQ53/0XwzlCGp1lf5q0j8PXnkxTpdKZemffGSzvmbdY= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1410.namprd05.prod.outlook.com (10.160.117.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Thu, 22 Jun 2017 13:02:35 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1199.016; Thu, 22 Jun 2017 13:02:33 +0000 From: Kent Watsen To: William Lupton CC: "netmod@ietf.org" , "ccamp-chairs@ietf.org" , "Deborah Brungard (dbrungard@att.com)" Thread-Topic: [netmod] draft-vallin-netmod-alarm-module status and plans Thread-Index: AQHSvpM1OTQR5vh1LkGxZthcN4PPOaIOkDCAgCJ2VwCAACvzGQ== Date: Thu, 22 Jun 2017 13:02:33 +0000 Message-ID: References: <4873921A-9782-4943-A076-C8D9E79E3991@broadband-forum.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: broadband-forum.org; dkim=none (message not signed) header.d=none;broadband-forum.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [137.118.194.50] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1410; 7:cj3/K1WU3AkcQrd1sZ9mlXXm+gsxNpMGnV5n3l14N0XS7hhg+14qIn0aPRttYJBV+UWwYk111QwdwNpIqKnzOhk7Gh8/spEHGKz5fG1X5DeTTJ+A3D3JTsuWbJF4wIYo8grDWuprdWkWythOTNT58p17Nrxuy4IY6qJt4gNMS4bs08szqR6/QWffI/7xZ9WWiimRbgG1ey2T1a+tF7tCGzN+eCf7xok1H0mUj8suVgiPkpMvpz39Cobusa328+0z8/KcZpx/6xHZpoRf7yKuNSahRDQvM3XniIpwX/ertXLlI5Qdarh6jBMlcvWSPhkYNGQasVKevUPA0q2Fvh3fngVhmn/gl32Y4QseBr2o8kDho7fSqHRS/AqMgGVme+m97RMKEZjAfKvhFFHFQsN0mpLtZH6rgLtaXQoNFoK7870CCBFE/0nA1oriT9Hquy951o3XARWCxlJWN6gDKEODKq7kCEahtzsGIZ77EsaH2e1g8fh5jbMWceMGDnxr2+rUpXGBaacRAqhTe1UeiW4W3d0KhbKS1zoin0Dk8U6ROSBlf0sp2yaM4U70pw8G9V8r9Ds/HHZwjx60VRGGR5XJARNGGRxn7g4CV6QKAXciv3Fu8HQV4cL3nlK7uRrr3/RRpfc3kmr5PcHl45eUcfclz4M1ATGz5fAwT2BmVr1+TbA47XYGz0RTX6O0D8jr+KTUThDWZl4Qlh0QeHFSPZ0R2QLIWHxbIIowy0X8Pg2LfSsSP/CLMEW+p8RXhZeTdztBtb1bQKZqs9+pHwby9K4IUeZsjlXfrEfrt03Di63QKFM= x-ms-office365-filtering-correlation-id: bfc0e125-5124-4047-e3f1-08d4b96ef2e8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500055)(300135000095)(300000501055)(300135300095)(22001)(300000502055)(300135100095)(2017030254075)(300000503055)(300135400095)(48565401081)(201703131423075)(201703031133081)(300000504055)(300135200095)(300000505055)(300135600095)(300000506048)(300135500095); SRVR:BN3PR0501MB1410; x-ms-traffictypediagnostic: BN3PR0501MB1410: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1410; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1410; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39860400002)(39840400002)(39450400003)(377454003)(24454002)(8676002)(6916009)(2950100002)(6116002)(189998001)(33656002)(86362001)(14454004)(2906002)(38730400002)(110136004)(54356999)(102836003)(81166006)(122556002)(76176999)(3846002)(50986999)(6436002)(2900100001)(36756003)(25786009)(66066001)(230783001)(77096006)(478600001)(53546010)(6512007)(54906002)(82746002)(83716003)(99286003)(6306002)(6486002)(305945005)(3660700001)(966005)(3280700002)(4326008)(8936002)(6506006)(7736002)(229853002)(5660300001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1410; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 13:02:33.8503 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1410 Archived-At: Subject: Re: [netmod] draft-vallin-netmod-alarm-module status and plans X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 13:02:40 -0000 DQpIaSBXaWxsaWFtLA0KDQpQbGVhc2UgYmUgYXdhcmUgdGhhdCB0aGlzIGRyYWZ0IGlzIG1vdmlu ZyB0byB0aGUgQ0NBTVAgV0cuICBJIGRvbid0IHRoaW5rIHRoZSBjY2FtcC12ZXJzaW9uIG9mIHRo ZSBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQgeWV0LCBidXQgaXQgd2lsbCBiZSBkaXNjdXNzZWQgaW4g dGhhdCBXRyAoYW5kIG5vdCBORVRNT0QpIGluIFByYWd1ZS4gDQoNClJlZ2FyZHMsDQpLZW50DQoN Cg0KPiBPbiBKdW4gMjIsIDIwMTcsIGF0IDY6MjUgQU0sIFdpbGxpYW0gTHVwdG9uIDx3bHVwdG9u QGJyb2FkYmFuZC1mb3J1bS5vcmc+IHdyb3RlOg0KPiANCj4gRGVhciBhbGwsDQo+IA0KPiBXZSBh dCB0aGUgQnJvYWRiYW5kIEZvcnVtIChCQkYpIHdvdWxkIGxpa2UgdG8gcmVpdGVyYXRlIG91ciBp bnRlcmVzdCBpbiB0aGUgZHJhZnQtdmFsbGluLW5ldG1vZC1hbGFybS1tb2R1bGUgZHJhZnQuDQo+ IA0KPiBXZSB3aWxsIGFsc28gaGF2ZSBzb21lIHRlY2huaWNhbCBjb21tZW50cyAvIHN1Z2dlc3Rp b25zIChpbnRlcm5hbCBkaXNjdXNzaW9uIGlzIG9uZ29pbmcpIHRoYXQgd2Ugd2lsbCBzaGFyZSB3 aXRoIE5FVE1PRCBhcyBzb29uIGFzIHBvc3NpYmxlLg0KPiANCj4gVGhhbmtzLA0KPiBXaWxsaWFt DQo+IA0KPj4gT24gMzEgTWF5IDIwMTcsIGF0IDEzOjA4LCBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNl QGNpc2NvLmNvbT4gd3JvdGU6DQo+PiANCj4+IFdpbGxpYW0sDQo+PiANCj4+IFRoaXMgd2FzIGRp c2N1c3NlZCB3aXRoIHRoZSBhdXRob3JzLCB0aGUgTkVUTU9EIGNoYWlycywgYW5kIHRoZSBSVEcg QUQgRGVib3JhaC4NCj4+IFRoZSBhZHZpY2Ugd2FzIGZvciB0aGUgYXV0aG9ycyB0byByYWlzZSB0 aGUgZHJhZnQgaW4gY2NhbXAgYW5kIHRyeSB0byBwcm9ncmVzcyBpdCB0aGVyZS4NCj4+IA0KPj4g VGhlIGF1dGhvcnMgdXBkYXRlZCB0aGVpciBkcmFmdCB0byB2ZXJzaW9uIDIgYW5kIHBpbmdlZCB0 aGUgQ0NBTVAgbWFpbGluZyBsaXN0IChodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2NjYW1wL2N1cnJlbnQvbXNnMTgxMjQuaHRtbCkuDQo+PiBGcm9tIHRoYXQgZW1haWwgdGhy ZWFkLCBpdCBzZWVtcyB0aGVyZSBpcyBpbnRlcmVzdCBpbiB0aGUgd29yaywgYnV0IHdoZXJlIHRv IGRvIHRoZSB3b3JrIGlzIG5vdCBjbGVhci4NCj4+IA0KPj4gTXkgYWR2aWNlIHRvIHRoZSBhdXRo b3JzOiBjb250aW51ZSBwcm9ncmVzcyB0aGlzIHdvcmsgYW5kIGlmIENDQU1QIGlzIG5vdCBpbnRl cmVzdGVkIG9yIGNvbnNpZGVyIHRoaXMgd29yayB0b28gZ2VuZXJpYywgYnJpbmcgaXQgYmFjayB0 byBORVRNT0QgYW5kIHdlJ2xsIGZvbGxvdyBub3JtYWwgV0cgcHJvY2Vzcy4NCj4+IA0KPj4gUmVn YXJkcywgQmVub2l0DQo+Pj4gQWxsLA0KPj4+IA0KPj4+IEkgaGVhcmQgZnJvbSBLZW50IHRoYXQg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZhbGxpbi1uZXRtb2QtYWxhcm0tbW9k dWxlIHdhcyBtb3ZpbmcgdG8gQ0NBTVAgYnV0IEkgZG9u4oCZdCBzZWUgYW55IG1lbnRpb24gb2Yg aXQgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9jY2FtcC9kb2N1bWVudHMgKGFs dGhvdWdoIGl0IGlzIHNob3duIGFzIGEgZGVwZW5kZW5jeSBhdCBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL3dnL2NjYW1wL2RlcHMvc3ZnKS4gSXMgYW55IG1vcmUgaW5mbyBhdmFpbGFibGUg cGxlYXNlPw0KPj4+IA0KPj4+IFRoYW5rcywNCj4+PiBXaWxsaWFtDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBs aXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0K From nobody Thu Jun 22 07:28:08 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21122129540 for ; Thu, 22 Jun 2017 07:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p6dMf2TSd6c for ; Thu, 22 Jun 2017 07:28:04 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C22312943B for ; Thu, 22 Jun 2017 07:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16763; q=dns/txt; s=iport; t=1498141684; x=1499351284; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=wDJ/+9/bFJwRBSmA1CvvJKEoCN1Ts/NAKRvixvil27Y=; b=b3OZXarr/w65L3rco1v9V0/miDcuOh6qy5wUbMbUWy+CzovzDDW+WQTc 17o7jslkK2GYHsvJ2dpYQK6iZmx5M/vslMRrHeqig6xsmGyFxebpeJVtB H0pkrF/zvnhwg2H5Ca3pm6B1eJCxhNvqC58BzIm1hQXXXn7C2r8vDsAEa w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AACG00tZ/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ6gQ2DbIoZc5BtkE6FKoIRIQEKhB6BEEoCgz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECAQEBIUsZAgkCEAgnAwICGwwfEQYBDAYCAQGKIAgQjhSdYoImK?= =?us-ascii?q?os+AQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWDIoNMgWArgnmFCyaCTIJhBZBBjiK?= =?us-ascii?q?TYoschnOMTIhKHziBCjAhCBsVSYRUboFOPzaJXQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,373,1493683200"; d="scan'208,217";a="653789261" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2017 14:28:02 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5MES1ME010557; Thu, 22 Jun 2017 14:28:01 GMT To: Andy Bierman , Juergen Schoenwaelder , "t.petch" , "netmod@ietf.org" References: <201706200605.v5K65g8E000929@idle.juniper.net> <060101d2e9b9$fee4e140$4001a8c0@gateway.2wire.net> <027d01d2e9e3$58a322e0$4001a8c0@gateway.2wire.net> <9f2823af-51a3-6b38-89a0-72cf521f62ee@cisco.com> <20170621123247.GC367@elstar.local> From: Robert Wilton Message-ID: <6637e2b6-29e9-9ace-4d70-02fb22d5c643@cisco.com> Date: Thu, 22 Jun 2017 15:28:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------52598373623AFD2F9ACD6A87" Archived-At: Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 14:28:07 -0000 This is a multi-part message in MIME format. --------------52598373623AFD2F9ACD6A87 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 21/06/2017 18:20, Andy Bierman wrote: > > > On Wed, Jun 21, 2017 at 5:32 AM, Juergen Schoenwaelder > > wrote: > > On Wed, Jun 21, 2017 at 10:03:21AM +0100, Robert Wilton wrote: > > > > We found that trying to define what "configuration is, or > isn't", is hard, > > but still regard having a definition is important. > > > > In the end, I see that the real core of the definition is > actually the > > config true sentence. I.e. the intention of the draft is to define > > configuration as the nodes in the YANG schema that are labelled > as config > > true, and hence it is the marking of the node as config true > that actually > > makes it configuration (at least in the context of this draft and > > NETCONF/YANG). > > > > So, do you think that it would help if the definition text was > reordered to > > make the binding to YANG config true first and foremost? > > > > E.g. > > > > Old: > > o configuration: Data that determines how a device behaves. This > > data is modeled in YANG using "config true" nodes. > Configuration > > can originate from different sources. > > > > New: > > configuration: All data that is modelled in YANG using "config > > true" nodes. Configuration is used to instruct how a device > behaves. > > Configuration can originate from different sources. > > > > I think this was true at some point of the internal discussions but I > think it is not true any longer. I believe the fix is this (moving the > config true statement to the definition of conventional > configuration): > > NEW: > > o configuration: Data that determines how a device behaves. > Configuration can originate from different sources. > > o conventional configuration: Configuration that is stored in > any of > the conventional configuration datastores. This data is > modeled in > YANG using "config true" nodes. > > > > I agree with Joel that all protocol negotiated values should not be > considered configuration. There are values e.g. protocol timers that may be set either manually through configuration, or through a value negotiated by a peer. In some protocols, it may be defined that a manually configured value would override a negotiated value. In other cases, a negotiated value wins. However, in both cases, there is only ever one actual operational value being used. The idea of the classification of different types of configuration, and associated origin values, is so that a client can determine whether the actual operational value in use was taken from the configuration, or through protocol negotiation, or somewhere else. Other examples are like IP addresses that may be set through configuration, or learned from DHCP, or other sources. > > I2RS is somewhere in between configuration and protocol-negotiated values. > We don't have a good term for it yet. > > There will be some protocol negotiation that is modeled in YANG and > represented in > a configuration datastore (e.g. ephemeral datastore). This data can be > modified with configured values. > The operational datastore reflects the actual values used. Maybe this > is called > ephemeral configuration? I think that draft refers to this as dynamic configuration, but the expectation is that this would only apply to config true nodes. I don't think that we have a name if I2RS writes to config false nodes (which is in the I2RS requirements draft). > > There will be some protocol negotiation that is not modeled in YANG > and not represented in > a configuration datastore, but the operational datastore can still > contain these values. > This should not be called configuration. Agreed. If these values are exposed they should be exposed as config false nodes in the operational datastore. Thanks, Rob > > > Andy > > ---8<--- snip ---8<--- > > In the current NMDA draft, configuration is a combination of > conventional configuration, dynamic configuration, learned > configuration, system configuration, and default configuration. > Perhaps we need to create more figures: > > configuration > | > + conventional configuration (origin intended) > + dynamic configuration (origin dynamic) > + learned configuration (origin learned) > + system configuration (origin system) > + default configuration (origin default) > > I am not sure whether dynamic configuration (e.g., coming from an I2RS > subsystem) or system configuration is necessarily restricted to config > true nodes. By moving the config true statement to the definition of > the term conventional configuration, we state something where we are > sure the statement is correct. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --------------52598373623AFD2F9ACD6A87 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 21/06/2017 18:20, Andy Bierman wrote:


On Wed, Jun 21, 2017 at 5:32 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 21, 2017 at 10:03:21AM +0100, Robert Wilton wrote:
>
> We found that trying to define what "configuration is, or isn't", is hard,
> but still regard having a definition is important.
>
> In the end, I see that the real core of the definition is actually the
> config true sentence.  I.e. the intention of the draft is to define
> configuration as the nodes in the YANG schema that are labelled as config
> true, and hence it is the marking of the node as config true that actually
> makes it configuration (at least in the context of this draft and
> NETCONF/YANG).
>
> So, do you think that it would help if the definition text was reordered to
> make the binding to YANG config true first and foremost?
>
> E.g.
>
> Old:
>    o  configuration: Data that determines how a device behaves. This
>       data is modeled in YANG using "config true" nodes. Configuration
>       can originate from different sources.
>
> New:
>   configuration: All data that is modelled in YANG using "config
>   true" nodes.  Configuration is used to instruct how a device behaves.
>   Configuration can originate from different sources.
>

I think this was true at some point of the internal discussions but I
think it is not true any longer. I believe the fix is this (moving the
config true statement to the definition of conventional
configuration):

NEW:

   o  configuration: Data that determines how a device behaves.
      Configuration can originate from different sources.

   o  conventional configuration: Configuration that is stored in any of
      the conventional configuration datastores. This data is modeled in
      YANG using "config true" nodes.



I agree with Joel that all protocol negotiated values should not be considered configuration.
There are values e.g. protocol timers that may be set either manually through configuration, or through a value negotiated by a peer.  In some protocols, it may be defined that a manually configured value would override a negotiated value.  In other cases, a negotiated value wins.

However, in both cases, there is only ever one actual operational value being used.  The idea of the classification of different types of configuration, and associated origin values, is so that a client can determine whether the actual operational value in use was taken from the configuration, or through protocol negotiation, or somewhere else.

Other examples are like IP addresses that may be set through configuration, or learned from DHCP, or other sources.


I2RS is somewhere in between configuration and protocol-negotiated values.
We don't have a good term for it yet.

There will be some protocol negotiation that is modeled in YANG and represented in
a configuration datastore (e.g. ephemeral datastore). This data can be modified with configured values.
The operational datastore reflects the actual values used. Maybe this is called
ephemeral configuration?
I think that draft refers to this as dynamic configuration, but the expectation is that this would only apply to config true nodes.  I don't think that we have a name if I2RS writes to config false nodes (which is in the I2RS requirements draft).


There will be some protocol negotiation that is not modeled in YANG and not represented in
a configuration datastore, but the operational datastore can still contain these values.
This should not be called configuration.
Agreed.  If these values are exposed they should be exposed as config false nodes in the operational datastore.

Thanks,
Rob



Andy

 
---8<--- snip ---8<---

In the current NMDA draft, configuration is a combination of
conventional configuration, dynamic configuration, learned
configuration, system configuration, and default configuration.
Perhaps we need to create more figures:

   configuration
        |
        + conventional configuration (origin intended)
        + dynamic configuration      (origin dynamic)
        + learned configuration      (origin learned)
        + system configuration       (origin system)
        + default configuration      (origin default)

I am not sure whether dynamic configuration (e.g., coming from an I2RS
subsystem) or system configuration is necessarily restricted to config
true nodes. By moving the config true statement to the definition of
the term conventional configuration, we state something where we are
sure the statement is correct.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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


--------------52598373623AFD2F9ACD6A87-- From nobody Fri Jun 23 10:14:47 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6486C12762F; Fri, 23 Jun 2017 10:14:46 -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, 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 uZxlcn4BsGYD; Fri, 23 Jun 2017 10:14:43 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882C91270A3; Fri, 23 Jun 2017 10:14:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 72D1F31005B5; Fri, 23 Jun 2017 19:14:41 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3njqMaplxRXw; Fri, 23 Jun 2017 19:14:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4B5D931005B8; Fri, 23 Jun 2017 19:14:41 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OjVQdxjFNV-W; Fri, 23 Jun 2017 19:14:41 +0200 (CEST) Received: from [192.168.209.116] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 29ADE31005B5; Fri, 23 Jun 2017 19:14:41 +0200 (CEST) To: Kent Watsen , William Lupton References: <4873921A-9782-4943-A076-C8D9E79E3991@broadband-forum.org> Cc: "ccamp-chairs@ietf.org" , "Deborah Brungard (dbrungard@att.com)" , "netmod@ietf.org" , stefan vallin From: Vladimir Vassilev Message-ID: <9bdc2746-346f-9288-ba2b-f738896373fb@transpacket.com> Date: Fri, 23 Jun 2017 19:14:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] draft-vallin-netmod-alarm-module status and plans X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 17:14:46 -0000 Hi Kent, I followed the CCAMP thread concluding with=20 https://www.ietf.org/mail-archive/web/ccamp/current/msg18142.html and=20 IMO there is consensus that the draft should be move back to netmod. Vladimir On 06/22/2017 03:02 PM, Kent Watsen wrote: > Hi William, > > Please be aware that this draft is moving to the CCAMP WG. I don't thi= nk the ccamp-version of the draft has been posted yet, but it will be dis= cussed in that WG (and not NETMOD) in Prague. > > Regards, > Kent > > >> On Jun 22, 2017, at 6:25 AM, William Lupton wrote: >> >> Dear all, >> >> We at the Broadband Forum (BBF) would like to reiterate our interest i= n the draft-vallin-netmod-alarm-module draft. >> >> We will also have some technical comments / suggestions (internal disc= ussion is ongoing) that we will share with NETMOD as soon as possible. >> >> Thanks, >> William >> >>> On 31 May 2017, at 13:08, Benoit Claise wrote: >>> >>> William, >>> >>> This was discussed with the authors, the NETMOD chairs, and the RTG A= D Deborah. >>> The advice was for the authors to raise the draft in ccamp and try to= progress it there. >>> >>> The authors updated their draft to version 2 and pinged the CCAMP mai= ling list (https://www.ietf.org/mail-archive/web/ccamp/current/msg18124.h= tml). >>> From that email thread, it seems there is interest in the work, but = where to do the work is not clear. >>> >>> My advice to the authors: continue progress this work and if CCAMP is= not interested or consider this work too generic, bring it back to NETMO= D and we'll follow normal WG process. >>> >>> Regards, Benoit >>>> All, >>>> >>>> I heard from Kent that https://tools.ietf.org/html/draft-vallin-netm= od-alarm-module was moving to CCAMP but I don=E2=80=99t see any mention o= f it at https://datatracker.ietf.org/wg/ccamp/documents (although it is s= hown as a dependency at https://datatracker.ietf.org/wg/ccamp/deps/svg). = Is any more info available please? >>>> >>>> Thanks, >>>> William >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jun 23 13:28:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB97129431 for ; Fri, 23 Jun 2017 13:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 WmSTvnktSVXW for ; Fri, 23 Jun 2017 13:28:32 -0700 (PDT) Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 A20E612944A for ; Fri, 23 Jun 2017 13:28:28 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 082A81E08FA for ; Fri, 23 Jun 2017 14:28:27 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id cLUP1v0042SSUrH01LUSHV; Fri, 23 Jun 2017 14:28:27 -0600 X-Authority-Analysis: v=2.2 cv=Eay4eLuC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=A1X0JdhQAAAA:8 a=48vgC7mUAAAA:8 a=0ZgzDHaQzhVBHrr1te0A:9 a=UCwxXGSUb3N5vEZB:21 a=sxRglrcGoxU6sEhe:21 a=QEXdDO2ut3YA:10 a=3qFsgw-wyTgA:10 a=Df3jFdWbhGDLdZNm0fyq:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=l2xmn53iBsgcHAKs33D1Lwk47DNrRZtT709b7M4MT8k=; b=jmGrd0ns6pb/aJ7LdhsWpAgA1I 0qRebRbhzQdL1d6jqFrsHyzYP1W7e7gSEFkCQA+I3PvD3OnWmjyFtUDsMr4u7uIaPuw6Ic09MWdJp MNkdy7qwnbUVRE4eqy8UOFVNl; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:45720 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dOVBm-000Fab-UR; Fri, 23 Jun 2017 14:28:23 -0600 To: draft-ietf-netmod-rfc6087bis@ietf.org, netmod@ietf.org References: <149784804955.10723.13177357489958504644@ietfa.amsl.com> From: Lou Berger Message-ID: <3997511b-8bcf-3598-23aa-aafc96f9417e@labn.net> Date: Fri, 23 Jun 2017 16:28:20 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149784804955.10723.13177357489958504644@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dOVBm-000Fab-UR X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:45720 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [netmod] Small comment on draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 20:28:34 -0000 I happened to be looking at Appendix C. YANG Module Template (because a YANG Dr pointed out that I wasn't following it in one of my drafts) and noticed an inconsistency. The template says: Copyright (c) IETF Trust and the persons identified as authors of the code. All rights reserved. Which matches current trust language, so this is all good. But: the template then has Editor: your-name "; *and* no place to list all who authored the "code", i.e., the module. Given the copyright, I think the template should be revised to: OLD Editor: your-name "; NEW Authors: //List all who contributed text to the module your-name "; Lou On 6/19/2017 12:54 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language of the IETF. > > Title : Guidelines for Authors and Reviewers of YANG Data Model Documents > Author : Andy Bierman > Filename : draft-ietf-netmod-rfc6087bis-13.txt > Pages : 64 > Date : 2017-06-18 > > Abstract: > This memo provides guidelines for authors and reviewers of Standards > Track specifications containing YANG data model modules. Applicable > portions may be used as a basis for reviews of other YANG data model > documents. Recommendations and procedures are defined, which are > intended to increase interoperability and usability of Network > Configuration Protocol (NETCONF) and RESTCONF protocol > implementations that utilize YANG data model modules. This document > obsoletes RFC 6087. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-13 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-13 > > > 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/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Jun 23 13:34:26 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5C012944C for ; Fri, 23 Jun 2017 13:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=yumaworks-com.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 65Z7t4JUVmVo for ; Fri, 23 Jun 2017 13:34:22 -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 0255912943F for ; Fri, 23 Jun 2017 13:34:21 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id c11so80081484wrc.3 for ; Fri, 23 Jun 2017 13:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/GwIHWS4Z05QNfqcC1vEC+jQDHtltjUR1+fZIsZio/k=; b=THFbSItR8pHfaRA/ain740nFtNh5T9jJ4p67IcjBlzyhu1va/OwVMav7VAT4EBxl2E qWxST+Z1mKN1QWNtDgrRuKnQeoAWRgEi6xJoEJnWIB9XjQR41OOoj3l4v2pqAP66AGWb 6s9rvVXBfdx5psn5+npvwqd1lU1EqqUT1ZqXfL7I0rKruLW1gzc0ZjWOIOeDyCCw4SFn szgyIs2+jyONox+2TtsawtjxjnAxTxvngqgQLImvzdiCHgaLwZRLRbeZejZkLOns+ZGV uoC6LnYEfAcrml4A2hztTvK0z8Nd48Nb8arvbDEgYWH68QUqXzDWjnQAJsJ33DbrxiVN TsTw== 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; bh=/GwIHWS4Z05QNfqcC1vEC+jQDHtltjUR1+fZIsZio/k=; b=eTUUoPJfMDaLySSd5En/xl9vGxX/kb6M/fY+j/Rv5DGH9agwwkK3CHyPo6wfpqz+ey BD/Fbw8X3p9gucaHmkrCD2a+ffeQ/A6siioJTV1LRcAsbsatXTV/Nte9iaLDJaEtmiCZ +QR8a7lxNBQdPv6wpxZfhVOWxKTtXWe+VJRdnN/kLMigeOZVhwBzt9bTO03MA/Q8oycf e8FnjeMJRuRDOzQs/LKbBEGsQSO31c8/f9OYvLv8Fmerfv9II1Q1je/sTxGnWy0A0NaM YIUWadualXnq9aUUkCv5Idc20VTwfdkEG1FET1rSmHQOndpSV7zxz0TYEiLZdx6kGeIF 7YOg== X-Gm-Message-State: AKS2vOxyK4V52CpxX2z8qDt4kW2PlD2mw96bH/DurQk4GhMT4pn2l9PB jEmOonV7DE+4zEIF+5LIM5ini6a+D0Kd X-Received: by 10.223.163.135 with SMTP id l7mr7478733wrb.88.1498250060387; Fri, 23 Jun 2017 13:34:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Fri, 23 Jun 2017 13:34:19 -0700 (PDT) In-Reply-To: <3997511b-8bcf-3598-23aa-aafc96f9417e@labn.net> References: <149784804955.10723.13177357489958504644@ietfa.amsl.com> <3997511b-8bcf-3598-23aa-aafc96f9417e@labn.net> From: Andy Bierman Date: Fri, 23 Jun 2017 13:34:19 -0700 Message-ID: To: Lou Berger Cc: draft-ietf-netmod-rfc6087bis@ietf.org, "netmod@ietf.org" Content-Type: multipart/alternative; boundary="f403045f1466a270ab0552a68642" Archived-At: Subject: Re: [netmod] Small comment on draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 20:34:25 -0000 --f403045f1466a270ab0552a68642 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 23, 2017 at 1:28 PM, Lou Berger wrote: > I happened to be looking at Appendix C. YANG Module Template (because a > YANG Dr pointed out that I wasn't following it in one of my drafts) and > noticed an inconsistency. The template says: > Copyright (c) IETF Trust and the persons > identified as authors of the code. All rights reserved. > > Which matches current trust language, so this is all good. > > But: the template then has > Editor: your-name > "; > > *and* no place to list all who authored the "code", i.e., the module. > Given the copyright, I think the template should be revised to: > > OLD > Editor: your-name > "; > NEW > Authors: //List all who contributed text to the module > your-name > "; > > How about just "Authors". It is an administrative nightmare to keep track of everyone who contributed the tiniest edit to a module. The module header would be 10 pages long listing the name and email of anyone who contributed any text. The draft itself has a contributors section. The template has always been to list the document authors here. > Lou > Andy > > On 6/19/2017 12:54 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the NETCONF Data Modeling Language of the > IETF. > > > > Title : Guidelines for Authors and Reviewers of YANG > Data Model Documents > > Author : Andy Bierman > > Filename : draft-ietf-netmod-rfc6087bis-13.txt > > Pages : 64 > > Date : 2017-06-18 > > > > Abstract: > > This memo provides guidelines for authors and reviewers of Standards > > Track specifications containing YANG data model modules. Applicable > > portions may be used as a basis for reviews of other YANG data model > > documents. Recommendations and procedures are defined, which are > > intended to increase interoperability and usability of Network > > Configuration Protocol (NETCONF) and RESTCONF protocol > > implementations that utilize YANG data model modules. This document > > obsoletes RFC 6087. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-13 > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-13 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-13 > > > > > > 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/ > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > --f403045f1466a270ab0552a68642 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 23, 2017 at 1:28 PM, Lou Berger <lberger@labn.net> wrote:
I happened to be looking at = Appendix C.=C2=A0 YANG Module Template (because a
YANG Dr pointed out that I wasn't following it in one of my drafts) and=
noticed an inconsistency.=C2=A0 The template says:
=C2=A0 =C2=A0Copyright (c) <insert year> IETF Trust and the persons =C2=A0 =C2=A0identified as authors of the code.=C2=A0 All rights reserved.<= br>
Which matches current trust language, so this is all good.

But: the template then has
=C2=A0 =C2=A0Editor:=C2=A0 =C2=A0your-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:your-email@example.com>";

*and* no place to list all who authored the "code", i.e., the mod= ule.
Given the copyright, I think the template should be revised to:

OLD
=C2=A0 =C2=A0Editor:=C2=A0 =C2=A0your-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:your-email@example.com>";
NEW
=C2=A0 =C2=A0Authors:=C2=A0 //List all who contributed text to the module =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0your-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:your-email@example.com>";



How about just "Au= thors".
It is an administrative nightmare to keep track of e= veryone who
contributed the tiniest edit to a module.=C2=A0 The m= odule header would be 10 pages long
listing the name and email of= anyone who contributed any text.
The draft itself has a contribu= tors section.
The template has always been to list the document a= uthors here.

=C2=A0
Lou

Andy
=C2=A0

On 6/19/2017 12:54 AM, internet= -drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the NETCONF Data Modeling Language of the= IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Guidelines for Authors and Reviewers of YANG Data Model Documen= ts
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Andy Bierman
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-netmod-rfc6087bis-13.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-06-18
>
> Abstract:
>=C2=A0 =C2=A0 This memo provides guidelines for authors and reviewers o= f Standards
>=C2=A0 =C2=A0 Track specifications containing YANG data model modules.= =C2=A0 Applicable
>=C2=A0 =C2=A0 portions may be used as a basis for reviews of other YANG= data model
>=C2=A0 =C2=A0 documents.=C2=A0 Recommendations and procedures are defin= ed, which are
>=C2=A0 =C2=A0 intended to increase interoperability and usability of Ne= twork
>=C2=A0 =C2=A0 Configuration Protocol (NETCONF) and RESTCONF protocol >=C2=A0 =C2=A0 implementations that utilize YANG data model modules.=C2= =A0 This document
>=C2=A0 =C2=A0 obsoletes RFC 6087.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/dra= ft-ietf-netmod-rfc6087bis-13
> https://datatracker.ietf.o= rg/doc/html/draft-ietf-netmod-rfc6087bis-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-netmod-rfc6087bis-13
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


--f403045f1466a270ab0552a68642-- From nobody Fri Jun 23 13:53:25 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8290129447 for ; Fri, 23 Jun 2017 13:53:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 LW0GpetErr41 for ; Fri, 23 Jun 2017 13:53:22 -0700 (PDT) Received: from gproxy6.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 259FC129479 for ; Fri, 23 Jun 2017 13:53:21 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 24C361E0708 for ; Fri, 23 Jun 2017 14:53:19 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id cLtF1v0102SSUrH01LtJMn; Fri, 23 Jun 2017 14:53:19 -0600 X-Authority-Analysis: v=2.2 cv=Eay4eLuC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=wU2YTnxGAAAA:8 a=A1X0JdhQAAAA:8 a=48vgC7mUAAAA:8 a=NSfjhvSGQy68iMIqiIEA:9 a=J4RGsir1hLedKHuQ:21 a=d0XkGskmdCiWpZP3:21 a=QEXdDO2ut3YA:10 a=M1gkhFx4fT4A:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=Df3jFdWbhGDLdZNm0fyq:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=e7AB8jFuO4ABL92CxDM2Yg0K1ufcg1NzQALnRAVj/1A=; b=sCbWR8Y6lL8g/wEkUGqE8mD2jF Hu+TTslD+EmQ8GEULIY15d0LOIvMUQs2NoGM/FHYfRLWPcOoh4Nc5W6tQiRAavmb/sKcDpUkIeYX/ x+J5/QZbHW0v2Jm4Ir6Xi3AJV; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:45838 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dOVZr-000JnQ-Ok; Fri, 23 Jun 2017 14:53:15 -0600 To: Andy Bierman Cc: draft-ietf-netmod-rfc6087bis@ietf.org, "netmod@ietf.org" References: <149784804955.10723.13177357489958504644@ietfa.amsl.com> <3997511b-8bcf-3598-23aa-aafc96f9417e@labn.net> From: Lou Berger Message-ID: Date: Fri, 23 Jun 2017 16:53:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dOVZr-000JnQ-Ok X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:45838 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] Small comment on draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 20:53:24 -0000 On 6/23/2017 4:34 PM, Andy Bierman wrote: > > > On Fri, Jun 23, 2017 at 1:28 PM, Lou Berger > wrote: > > I happened to be looking at Appendix C. YANG Module Template > (because a > YANG Dr pointed out that I wasn't following it in one of my > drafts) and > noticed an inconsistency. The template says: > Copyright (c) IETF Trust and the persons > identified as authors of the code. All rights reserved. > > Which matches current trust language, so this is all good. > > But: the template then has > Editor: your-name > >"; > > *and* no place to list all who authored the "code", i.e., the module. > Given the copyright, I think the template should be revised to: > > OLD > Editor: your-name > >"; > NEW > Authors: //List all who contributed text to the module > your-name > >"; > > > > How about just "Authors". you mean: //List all who authored the module That works for me. > It is an administrative nightmare to keep track of everyone who > contributed the tiniest edit to a module. The module header would be > 10 pages long > listing the name and email of anyone who contributed any text. > The draft itself has a contributors section. > The template has always been to list the document authors here. > The copyright says " identified as authors of the code. " so it seems to me that all copyright holders need to be identified in the module. I have no idea that the test/bar is to become a copyright holder, but can ask for an official trust position if needed. Lou > > > Lou > > > Andy > > > > On 6/19/2017 12:54 AM, internet-drafts@ietf.org > wrote: > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the NETCONF Data Modeling Language > of the IETF. > > > > Title : Guidelines for Authors and Reviewers > of YANG Data Model Documents > > Author : Andy Bierman > > Filename : draft-ietf-netmod-rfc6087bis-13.txt > > Pages : 64 > > Date : 2017-06-18 > > > > Abstract: > > This memo provides guidelines for authors and reviewers of > Standards > > Track specifications containing YANG data model modules. > Applicable > > portions may be used as a basis for reviews of other YANG > data model > > documents. Recommendations and procedures are defined, which are > > intended to increase interoperability and usability of Network > > Configuration Protocol (NETCONF) and RESTCONF protocol > > implementations that utilize YANG data model modules. This > document > > obsoletes RFC 6087. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ > > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-13 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-13 > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-13 > > > > > > > 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/ > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > From nobody Fri Jun 23 17:09:10 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC110129B28; Fri, 23 Jun 2017 17:07:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: bclaise@cisco.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282096.7840.15606919501140664468.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:00 -0700 Archived-At: Subject: [netmod] netmod - Requested sessions have been scheduled for IETF 99 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:01 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. netmod Session 1 (1:30:00) Monday, Afternoon Session II 1550-1720 Room Name: Congress Hall I size: 250 --------------------------------------------- netmod Session 2 (2:00:00) Wednesday, Afternoon Session I 1330-1500 Room Name: Congress Hall I size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: NETCONF Data Modeling Language Area Name: Operations and Management Area Session Requester: Lou Berger Number of Sessions: 2 Length of Session(s): 1.5 Hours, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: netconf rtgwg Second Priority: teas i2rs anima Third Priority: saag isis ospf People who must be present: Lou Berger Benoit Claise Kent Watsen Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 24 10:08:00 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AD8127419 for ; Sat, 24 Jun 2017 10:07:59 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wallan-se.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 Qc_2pcJuwJwG for ; Sat, 24 Jun 2017 10:07:57 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 DAD661200FC for ; Sat, 24 Jun 2017 10:07:56 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id h22so43965040lfk.3 for ; Sat, 24 Jun 2017 10:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wallan-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vw4qoiEGZ5s3Brd5RF6NiMBgb7lC2DDjV7tGiLL53z8=; b=PVZaU+bSgwd3LWtSqL7JBnQEV+LEfXJkd5qZAclo/VP9sVyh9e4FQhLPGHCv1dbM4P 3E90HwAiGOyQ321XGAyQ3Aj5113uFUyYLi5q9DCVhCK21BqafcZd/tWTVegsg1zUPm1z N9uhbXSv8rx1rbxeiHGlWpqRPg+0NGvlPMCE2ree9yqTv5BwzlFxlnrzIQ0JShh9lTVv UX2YS2FTKlR5Ql0+UR5HZIf66S09kj/2gYIhHK4S1RpNfFJiME8EuqCS2ziggBb23Bpo B6DAl/jvwrQMJQW/izn36dCMvIgfcxfspf2QlxVCOweZ3hyrGu4t8M6qM4uPkF7rgQGU cCDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vw4qoiEGZ5s3Brd5RF6NiMBgb7lC2DDjV7tGiLL53z8=; b=ON6UAVGHCARJyu5x8RLJ45J8t/V9P5aYddx9D0xkNwvViHOqEcsRGcTmy42Sv8ZfEz OB4tCNyDhf92Tr/RIpPM+V7dlx+1WZvsIzvfwpPYMrg+waUZ+BWwA2ZKYq+u9sCbZSLN KS6Mwp5sB6WguM3Pn6kVWoX0j2YWRfJWr2LGagyLI7a9gJVlbhGbrMvttQbz5Qt+3pCS quwCHsVtVrb6Pm87GVEiZ8hIn1XZTnCtfbirEo7BvTfEPrIHRt4pJicgCtT0WS9yvDJv RYPQ77ScIYhla25GN02wcjz/p2e1B6s1qn4Gfxh790ZlNirG31PAd7xUS7Apx29ZecEB SlwA== X-Gm-Message-State: AKS2vOx5rGpsv4gs7llcT+0mKgxaNyL5t5CGfeUuK4nV0Hy/VjPfH1jY pr2KQ4AsFHSi26M8 X-Received: by 10.46.33.229 with SMTP id h98mr721344lji.65.1498324075114; Sat, 24 Jun 2017 10:07:55 -0700 (PDT) Received: from [192.168.1.201] (h95-155-236-198.cust.se.alltele.net. [95.155.236.198]) by smtp.gmail.com with ESMTPSA id n132sm2260623lfn.61.2017.06.24.10.07.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jun 2017 10:07:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: stefan vallin X-Mailer: iPhone Mail (14E304) In-Reply-To: <9bdc2746-346f-9288-ba2b-f738896373fb@transpacket.com> Date: Sat, 24 Jun 2017 19:07:53 +0200 Cc: Kent Watsen , William Lupton , "ccamp-chairs@ietf.org" , "Deborah Brungard (dbrungard@att.com)" , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4873921A-9782-4943-A076-C8D9E79E3991@broadband-forum.org> <9bdc2746-346f-9288-ba2b-f738896373fb@transpacket.com> To: Vladimir Vassilev Archived-At: Subject: Re: [netmod] draft-vallin-netmod-alarm-module status and plans X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 17:07:59 -0000 +1 Mvh stefan +46(0)705233262 > 23 juni 2017 kl. 19:14 skrev Vladimir Vassilev := >=20 > Hi Kent, >=20 > I followed the CCAMP thread concluding with https://www.ietf.org/mail-arch= ive/web/ccamp/current/msg18142.html and IMO there is consensus that the draf= t should be move back to netmod. >=20 > Vladimir >=20 >=20 >> On 06/22/2017 03:02 PM, Kent Watsen wrote: >> Hi William, >>=20 >> Please be aware that this draft is moving to the CCAMP WG. I don't think= the ccamp-version of the draft has been posted yet, but it will be discusse= d in that WG (and not NETMOD) in Prague. >>=20 >> Regards, >> Kent >>=20 >>=20 >>> On Jun 22, 2017, at 6:25 AM, William Lupton wrote: >>>=20 >>> Dear all, >>>=20 >>> We at the Broadband Forum (BBF) would like to reiterate our interest in t= he draft-vallin-netmod-alarm-module draft. >>>=20 >>> We will also have some technical comments / suggestions (internal discus= sion is ongoing) that we will share with NETMOD as soon as possible. >>>=20 >>> Thanks, >>> William >>>=20 >>>> On 31 May 2017, at 13:08, Benoit Claise wrote: >>>>=20 >>>> William, >>>>=20 >>>> This was discussed with the authors, the NETMOD chairs, and the RTG AD D= eborah. >>>> The advice was for the authors to raise the draft in ccamp and try to p= rogress it there. >>>>=20 >>>> The authors updated their draft to version 2 and pinged the CCAMP maili= ng list (https://www.ietf.org/mail-archive/web/ccamp/current/msg18124.html).= >>>> =46rom that email thread, it seems there is interest in the work, but w= here to do the work is not clear. >>>>=20 >>>> My advice to the authors: continue progress this work and if CCAMP is n= ot interested or consider this work too generic, bring it back to NETMOD and= we'll follow normal WG process. >>>>=20 >>>> Regards, Benoit >>>>> All, >>>>>=20 >>>>> I heard from Kent that https://tools.ietf.org/html/draft-vallin-netmod= -alarm-module was moving to CCAMP but I don=E2=80=99t see any mention of it a= t https://datatracker.ietf.org/wg/ccamp/documents (although it is shown as a= dependency at https://datatracker.ietf.org/wg/ccamp/deps/svg). Is any more i= nfo available please? >>>>>=20 >>>>> Thanks, >>>>> William >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Sat Jun 24 12:09:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D3C129404 for ; Sat, 24 Jun 2017 12:09:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 CYyyXF44jJv6 for ; Sat, 24 Jun 2017 12:09:43 -0700 (PDT) Received: from gproxy7.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 79A7C129400 for ; Sat, 24 Jun 2017 12:09:43 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id F3C9B215D70 for ; Sat, 24 Jun 2017 13:09:42 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id cj9f1v0012SSUrH01j9iEf; Sat, 24 Jun 2017 13:09:42 -0600 X-Authority-Analysis: v=2.2 cv=Eay4eLuC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=LWSFodeU3zMA:10 a=e45He0E8AAAA:8 a=48vgC7mUAAAA:8 a=mYPrF8hoAAAA:8 a=AUd_NHdVAAAA:8 a=WN7ql34MMCMFrQldTgMA:9 a=QEXdDO2ut3YA:10 a=w_-thPZWg7wA:10 a=sNfsouPNf8gA:10 a=eMiHdfvR8LwA:10 a=-Fram-4vtGMA:10 a=cj7hvcB7Pb6S7jLLiKPa:22 a=w1C3t2QeGrPiZgrLijVG:22 a=SK_ViTGLvA2mnZZ8RFS2:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6Ogx4ruWGo0sUWFZo/a7/UE7gYw0eLZDTyeP/QjzBM4=; b=cnFqYpNa4g14fty46KjllfWOYt oD+4w1xog3gjY1HVrecryJuuR5M9Ukud/u4ytcgF3J0pEK3cxh88OWgUb5SYDXQQ2+qEyBr9W4zAv 2K5+sDKV/EmaWx16hV6LrDis4; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:46401 helo=[11.4.0.6]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dOqR8-0004KC-NO; Sat, 24 Jun 2017 13:09:38 -0600 From: Lou Berger To: stefan vallin , Vladimir Vassilev CC: "ccamp-chairs@ietf.org" , , "Deborah Brungard (dbrungard@att.com)" Date: Sat, 24 Jun 2017 15:09:36 -0400 Message-ID: <15cdb826598.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <4873921A-9782-4943-A076-C8D9E79E3991@broadband-forum.org> <9bdc2746-346f-9288-ba2b-f738896373fb@transpacket.com> User-Agent: AquaMail/1.10.0-403 (build: 101000001) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dOqR8-0004KC-NO X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([11.4.0.6]) [100.15.84.20]:46401 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] draft-vallin-netmod-alarm-module status and plans X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 19:09:46 -0000 My understanding is the same as Kent's. This document should be brought into ccamp... Lou On June 24, 2017 1:08:35 PM stefan vallin wrote: > +1 > > Mvh stefan > +46(0)705233262 > >> 23 juni 2017 kl. 19:14 skrev Vladimir Vassilev : >> >> Hi Kent, >> >> I followed the CCAMP thread concluding with >> https://www.ietf.org/mail-archive/web/ccamp/current/msg18142.html and IMO >> there is consensus that the draft should be move back to netmod. >> >> Vladimir >> >> >>> On 06/22/2017 03:02 PM, Kent Watsen wrote: >>> Hi William, >>> >>> Please be aware that this draft is moving to the CCAMP WG. I don't think >>> the ccamp-version of the draft has been posted yet, but it will be >>> discussed in that WG (and not NETMOD) in Prague. >>> >>> Regards, >>> Kent >>> >>> >>>> On Jun 22, 2017, at 6:25 AM, William Lupton >>>> wrote: >>>> >>>> Dear all, >>>> >>>> We at the Broadband Forum (BBF) would like to reiterate our interest in the >>>> draft-vallin-netmod-alarm-module draft. >>>> >>>> We will also have some technical comments / suggestions (internal >>>> discussion is ongoing) that we will share with NETMOD as soon as possible. >>>> >>>> Thanks, >>>> William >>>> >>>>> On 31 May 2017, at 13:08, Benoit Claise wrote: >>>>> >>>>> William, >>>>> >>>>> This was discussed with the authors, the NETMOD chairs, and the RTG AD Deborah. >>>>> The advice was for the authors to raise the draft in ccamp and try to >>>>> progress it there. >>>>> >>>>> The authors updated their draft to version 2 and pinged the CCAMP mailing >>>>> list (https://www.ietf.org/mail-archive/web/ccamp/current/msg18124.html). >>>>> From that email thread, it seems there is interest in the work, but where >>>>> to do the work is not clear. >>>>> >>>>> My advice to the authors: continue progress this work and if CCAMP is not >>>>> interested or consider this work too generic, bring it back to NETMOD and >>>>> we'll follow normal WG process. >>>>> >>>>> Regards, Benoit >>>>>> All, >>>>>> >>>>>> I heard from Kent that >>>>>> https://tools.ietf.org/html/draft-vallin-netmod-alarm-module was moving to >>>>>> CCAMP but I don’t see any mention of it at >>>>>> https://datatracker.ietf.org/wg/ccamp/documents (although it is shown as a >>>>>> dependency at https://datatracker.ietf.org/wg/ccamp/deps/svg). Is any more >>>>>> info available please? >>>>>> >>>>>> Thanks, >>>>>> William >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Jun 25 18:17:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A384E128896 for ; Sun, 25 Jun 2017 18:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oto7CDOBkKeC for ; Sun, 25 Jun 2017 18:17:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D327412441E for ; Sun, 25 Jun 2017 18:17:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPV05153; Mon, 26 Jun 2017 01:17:38 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 26 Jun 2017 02:17:38 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.18]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Mon, 26 Jun 2017 09:17:32 +0800 From: wangzitao To: "netmod@ietf.org" Thread-Topic: Netmod Time Slot request Thread-Index: AdLuGftNz8p2A6zATAK4rcflYX2XYg== Date: Mon, 26 Jun 2017 01:17:31 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.161] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2AE3217EDGGEMM506MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.595060B3.001E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.18, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 379b513683e1af9f465e536e19386dc0 Archived-At: Subject: [netmod] Netmod Time Slot request X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 01:17:45 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2AE3217EDGGEMM506MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Netmod WG, It's that time again! The final agenda for IETF 99 has been published; you can find it at https:/= /datatracker.ietf.org/meeting/99/agenda.html NETMOD will be meeting: 15:50-17:20 on Monday and 13:30-15:00 on Wednesday. If you'd like a slot to present a draft, please send a request to Chairs an= d me. Kindly reminder, the deadline for draft submission is UTC 23:59 on 20= 17-07-03 (Monday). Best Regards! -Michael --_000_E6BC9BBCBCACC246846FC685F9FF41EA2AE3217EDGGEMM506MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Netmod WG,

 

It's that time agai= n!

The final agenda fo= r IETF 99 has been published; you can find it at http= s://datatracker.ietf.org/meeting/99/agenda.html

NETMOD will be meet= ing: 15:50-17:20 on Monday and 13:30-15:00 on Wednesday.<= /p>

If you'd like a slo= t to present a draft, please send a request to Chairs and me. Kindly remind= er, the deadline for draft submission is UTC 23:59 on 2017-07-03 (Monday).

 

Best Regards!<= /o:p>

 

-Michael

 

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2AE3217EDGGEMM506MBXchi_-- From nobody Mon Jun 26 01:23:26 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60DD127275; Mon, 26 Jun 2017 01:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHoVN8e7NPeN; Mon, 26 Jun 2017 01:23:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 03F88129466; Mon, 26 Jun 2017 01:23:21 -0700 (PDT) X-AuditID: c1b4fb3a-81bff70000001b2f-f7-5950c478c839 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AC.06.06959.874C0595; Mon, 26 Jun 2017 10:23:20 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 26 Jun 2017 10:23:19 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P279f2fgEUgjU9lsOTH7gsvehHyA2K7z50i3tf03gGE=; b=kAMDCZdWHCFi9zFdllZpgbGgOk3BneUsYDRimyojPXbY6K3fv0eKWFzNIsaitHkx3EV/DqSepb/k1GB2Zj99NOG4aa3vwWkwKhhuPmfXVnu/spEa7syDxwyWfPHoEZT0FWp0mb9A27lAsnnPxHPzTFjxbbr3eKQxN4LozpQN08g= Received: from VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) by VI1PR07MB1230.eurprd07.prod.outlook.com (10.164.87.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Mon, 26 Jun 2017 08:23:18 +0000 Received: from VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::f50e:de50:1e13:ec2b]) by VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::f50e:de50:1e13:ec2b%18]) with mapi id 15.01.1220.010; Mon, 26 Jun 2017 08:23:18 +0000 From: Daniele Ceccarelli To: Lou Berger , stefan vallin , "Vladimir Vassilev" CC: "ccamp-chairs@ietf.org" , "netmod@ietf.org" , "Deborah Brungard (dbrungard@att.com)" Thread-Topic: [netmod] draft-vallin-netmod-alarm-module status and plans Thread-Index: AQHS2gbGHGl86kCgd0ad8cuzVYdEwaIwz6AAgAAr8oCAAdjFAIABkHCAgAAiAgCAAm+LgA== Date: Mon, 26 Jun 2017 08:23:18 +0000 Message-ID: References: <4873921A-9782-4943-A076-C8D9E79E3991@broadband-forum.org> <9bdc2746-346f-9288-ba2b-f738896373fb@transpacket.com> <15cdb826598.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <15cdb826598.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [93.40.1.108] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1230; 7:z6LtGSXnWbNJ0ddPOXjzALG1x5pk2XQkSUSZTIFLolIFmJDU5K5Q2wceFajQGkGlAbwIvQ3xBqOBZSdM8gxbDA/WwrB4kDldyvRde4pw8H2WcZ8aUZeKGMBEjGK+oD5dheaGXG6fQJGqf6ns0nSda+gkT6+A8pE0WMAE7qgdLYwZpnWoWIFO749yav0Zo4bzt1TVTCm9h9XGnXxa/aaEskVYIGbhJaTh3FFfL9opCgscPIzd5VUdhq8E5d6R93fauN+kU2cd0nfTGiDl+fo0WxUcZ8waKpqkNH0hg2/YHXPFPBXspiJKXRp9L6bwTvQqkhsXDSAytk75FF7P8h1a8aXlx01Swjk4LzoBk2ytLqtf+M5jELAmloY+Sw6U5LWjU5M4zWwDeEV/0pUlqQ8Q2OBDtrL4BrWGTsHB1qtgIkU3Ewf/L8aywJlUlMIRrhvdioJnDhW1a+BcWSQ5XrEmJ2/xOtXo8yeSdOEos+HzZII/OwdnjvV4dNKyqeGDzO3fwj9Kfk9USx10mbPDTX9GCUc5476OuEKKBfVhfJDjgqRQ2OTTwFlCFebAx/yggR8BGlJBFO5JDJqgKV0lx3zLyZr/k/e7ux2B+CTRhq0DInjZqJLQPTaBLydviJMZlWdr3vBr2FLCExRBjMJFVWBJ1eJvBEwmEfvE9DPpUdJ0I20h4dcTlcI35dRDgdAnFiSQ+grqz8RTmfJe2Il/nfm063Dq/xrELxPN4dZnM6cdQMZUoGuLbrrPxNJ4Wz0U62q9yrKL8u5el7QOsTl0RJsAF3ydKyqgR9qKKaOY7ZmcJLQ= x-ms-office365-filtering-correlation-id: 36954bb7-05ca-404e-1944-08d4bc6c9984 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095); SRVR:VI1PR07MB1230; x-ms-traffictypediagnostic: VI1PR07MB1230: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278178393323532)(120809045254105)(236129657087228)(97927398514766)(100405760836317)(95692535739014)(92977632026198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1230; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1230; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39840400002)(39450400003)(39860400002)(39410400002)(24454002)(13464003)(377454003)(33656002)(6306002)(14454004)(2950100002)(4326008)(9686003)(53936002)(8936002)(305945005)(2906002)(74316002)(25786009)(229853002)(6246003)(54356999)(38730400002)(50986999)(76176999)(3660700001)(2900100001)(3280700002)(5660300001)(966005)(7736002)(102836003)(7696004)(189998001)(478600001)(66066001)(81166006)(6436002)(86362001)(8676002)(6116002)(230783001)(93886004)(3846002)(6506006)(55016002)(99286003)(53546010)(54906002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1230; H:VI1PR07MB1005.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2017 08:23:18.0921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1230 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGO/dju1qL03L4Zg1rlJWRlqgNiVh/tSBDIUrLsqE3Xc4pu2pW fzg1KrY+JqngR65sGgUVaeXSiJzLaQn24UgK8WuyrCQ1ZqUiebsL+u95z+95OM95OQwpvUuH MFp9HmvQa3QKUSBVldRyYGuhMyF526xnhbLB3kQoW57aKOXF0glKaX1bTCt7avqQ8pV1hlaJ 1ONXa5HaZvtNqCebSkVq92Q3pf4+YUQJ9OHAnemsTlvAGiJ3HQ/M/HBxnsi9ElZ4/tEd0ogs G0wogAEcDT+vfRWZUCAjxU4E8y+ekjyQ4i4Eja5YHlD4Mgk1Ex5CcFUQcHu6QywMowhKBhsX 8wwjwnHgcezj00E4H2ZcgofElQi6TR00D1biPTBmPifm/UFYDTVlaYL/IDinPH9vpvAGGL50 Q8RrCU6BL5/LKaFRJQm/StJ5HYD3wn3fdTGvEZaDpa0e8ZrEwfDRYyWEp2GwPeslBS2D8dEF mu+DsBnBlNnlB6Ew0FBLC1oO76xmxJsAD4mgxNUrFkA8OMsWCAG0ENA/XOFPhIOpuAcJOgs6 3D/96ToEC+4qWhgcNMy9rvSXWgO3mvvEArDTMO27LbagLdX/la9e3A2JN8OD1kjheB2Um4fF 1X/3sQK6qzzUDUTdRTKO5bjsjKioCNagTeO4HH2Ens1rQos/qP3RXJwdtXt3OxBmkGKZpOhx QrKU1hRwp7MdCBhSESR5+GTxSJKuOX2GNeSkGvJ1LOdAqxlKESxRPX+TJMUZmjw2i2VzWcM/ SjABIUYkm6+7c2HkYVv0p9BDMaXJsT65JaxNFZxS/aN9oLbTpNXJVn/zKU+c3LQk1R5fnPar ID6xbWqV9yU6n3L/mHdpc9LRjWPefn1nzp6ine/d9ZvDB4+d3d8lIXYNFZXErL13asf08qPx cc7WIw22ocSRm8bI/H03s9e/MP6AI/LZENUaBcVlaraHkwZO8weLBI/SPQMAAA== Archived-At: Subject: Re: [netmod] draft-vallin-netmod-alarm-module status and plans X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 08:23:25 -0000 SGkgVmxhZGltaXIsDQoNCnRoYXQgc2luZ2xlIGVtYWlsIGRvZXNuJ3QgcmVmbGVjdCB0aGUgY29u c2Vuc3VzIG9mIHRoZSBXRy4gVGhlIGNoYWlycyBhbmQgdGhlIEFEcyBhZ3JlZWQgdGhhdCBDQ0FN UCBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gcHJvZ3Jlc3MgdGhlIGRyYWZ0Lg0KDQpCUg0KRGFuaWVs ZSAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3UgQmVyZ2VyIFttYWls dG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50OiBzYWJhdG8gMjQgZ2l1Z25vIDIwMTcgMjE6MTAN ClRvOiBzdGVmYW4gdmFsbGluIDxzdGVmYW5Ad2FsbGFuLnNlPjsgVmxhZGltaXIgVmFzc2lsZXYg PHZsYWRpbWlyQHRyYW5zcGFja2V0LmNvbT4NCkNjOiBjY2FtcC1jaGFpcnNAaWV0Zi5vcmc7IG5l dG1vZEBpZXRmLm9yZzsgRGVib3JhaCBCcnVuZ2FyZCAoZGJydW5nYXJkQGF0dC5jb20pIDxkYnJ1 bmdhcmRAYXR0LmNvbT4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBkcmFmdC12YWxsaW4tbmV0bW9k LWFsYXJtLW1vZHVsZSBzdGF0dXMgYW5kIHBsYW5zDQoNCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhl IHNhbWUgYXMgS2VudCdzLiBUaGlzIGRvY3VtZW50IHNob3VsZCBiZSBicm91Z2h0IGludG8gY2Nh bXAuLi4NCg0KTG91DQoNCg0KT24gSnVuZSAyNCwgMjAxNyAxOjA4OjM1IFBNIHN0ZWZhbiB2YWxs aW4gPHN0ZWZhbkB3YWxsYW4uc2U+IHdyb3RlOg0KDQo+ICsxDQo+DQo+IE12aCBzdGVmYW4NCj4g KzQ2KDApNzA1MjMzMjYyDQo+DQo+PiAyMyBqdW5pIDIwMTcga2wuIDE5OjE0IHNrcmV2IFZsYWRp bWlyIFZhc3NpbGV2IDx2bGFkaW1pckB0cmFuc3BhY2tldC5jb20+Og0KPj4NCj4+IEhpIEtlbnQs DQo+Pg0KPj4gSSBmb2xsb3dlZCB0aGUgQ0NBTVAgdGhyZWFkIGNvbmNsdWRpbmcgd2l0aCANCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2NhbXAvY3VycmVudC9tc2cx ODE0Mi5odG1sIGFuZCANCj4+IElNTyB0aGVyZSBpcyBjb25zZW5zdXMgdGhhdCB0aGUgZHJhZnQg c2hvdWxkIGJlIG1vdmUgYmFjayB0byBuZXRtb2QuDQo+Pg0KPj4gVmxhZGltaXINCj4+DQo+Pg0K Pj4+IE9uIDA2LzIyLzIwMTcgMDM6MDIgUE0sIEtlbnQgV2F0c2VuIHdyb3RlOg0KPj4+IEhpIFdp bGxpYW0sDQo+Pj4NCj4+PiBQbGVhc2UgYmUgYXdhcmUgdGhhdCB0aGlzIGRyYWZ0IGlzIG1vdmlu ZyB0byB0aGUgQ0NBTVAgV0cuICBJIGRvbid0IA0KPj4+IHRoaW5rIHRoZSBjY2FtcC12ZXJzaW9u IG9mIHRoZSBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQgeWV0LCBidXQgaXQgDQo+Pj4gd2lsbCBiZSBk aXNjdXNzZWQgaW4gdGhhdCBXRyAoYW5kIG5vdCBORVRNT0QpIGluIFByYWd1ZS4NCj4+Pg0KPj4+ IFJlZ2FyZHMsDQo+Pj4gS2VudA0KPj4+DQo+Pj4NCj4+Pj4gT24gSnVuIDIyLCAyMDE3LCBhdCA2 OjI1IEFNLCBXaWxsaWFtIEx1cHRvbiANCj4+Pj4gPHdsdXB0b25AYnJvYWRiYW5kLWZvcnVtLm9y Zz4NCj4+Pj4gd3JvdGU6DQo+Pj4+DQo+Pj4+IERlYXIgYWxsLA0KPj4+Pg0KPj4+PiBXZSBhdCB0 aGUgQnJvYWRiYW5kIEZvcnVtIChCQkYpIHdvdWxkIGxpa2UgdG8gcmVpdGVyYXRlIG91ciANCj4+ Pj4gaW50ZXJlc3QgaW4gdGhlIGRyYWZ0LXZhbGxpbi1uZXRtb2QtYWxhcm0tbW9kdWxlIGRyYWZ0 Lg0KPj4+Pg0KPj4+PiBXZSB3aWxsIGFsc28gaGF2ZSBzb21lIHRlY2huaWNhbCBjb21tZW50cyAv IHN1Z2dlc3Rpb25zIChpbnRlcm5hbCANCj4+Pj4gZGlzY3Vzc2lvbiBpcyBvbmdvaW5nKSB0aGF0 IHdlIHdpbGwgc2hhcmUgd2l0aCBORVRNT0QgYXMgc29vbiBhcyBwb3NzaWJsZS4NCj4+Pj4NCj4+ Pj4gVGhhbmtzLA0KPj4+PiBXaWxsaWFtDQo+Pj4+DQo+Pj4+PiBPbiAzMSBNYXkgMjAxNywgYXQg MTM6MDgsIEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+DQo+ Pj4+PiBXaWxsaWFtLA0KPj4+Pj4NCj4+Pj4+IFRoaXMgd2FzIGRpc2N1c3NlZCB3aXRoIHRoZSBh dXRob3JzLCB0aGUgTkVUTU9EIGNoYWlycywgYW5kIHRoZSBSVEcgQUQgRGVib3JhaC4NCj4+Pj4+ IFRoZSBhZHZpY2Ugd2FzIGZvciB0aGUgYXV0aG9ycyB0byByYWlzZSB0aGUgZHJhZnQgaW4gY2Nh bXAgYW5kIHRyeSANCj4+Pj4+IHRvIHByb2dyZXNzIGl0IHRoZXJlLg0KPj4+Pj4NCj4+Pj4+IFRo ZSBhdXRob3JzIHVwZGF0ZWQgdGhlaXIgZHJhZnQgdG8gdmVyc2lvbiAyIGFuZCBwaW5nZWQgdGhl IENDQU1QIA0KPj4+Pj4gbWFpbGluZyBsaXN0IChodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2NjYW1wL2N1cnJlbnQvbXNnMTgxMjQuaHRtbCkuDQo+Pj4+PiBGcm9tIHRoYXQg ZW1haWwgdGhyZWFkLCBpdCBzZWVtcyB0aGVyZSBpcyBpbnRlcmVzdCBpbiB0aGUgd29yaywgDQo+ Pj4+PiBidXQgd2hlcmUgdG8gZG8gdGhlIHdvcmsgaXMgbm90IGNsZWFyLg0KPj4+Pj4NCj4+Pj4+ IE15IGFkdmljZSB0byB0aGUgYXV0aG9yczogY29udGludWUgcHJvZ3Jlc3MgdGhpcyB3b3JrIGFu ZCBpZiBDQ0FNUCANCj4+Pj4+IGlzIG5vdCBpbnRlcmVzdGVkIG9yIGNvbnNpZGVyIHRoaXMgd29y ayB0b28gZ2VuZXJpYywgYnJpbmcgaXQgYmFjayANCj4+Pj4+IHRvIE5FVE1PRCBhbmQgd2UnbGwg Zm9sbG93IG5vcm1hbCBXRyBwcm9jZXNzLg0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsIEJlbm9pdA0K Pj4+Pj4+IEFsbCwNCj4+Pj4+Pg0KPj4+Pj4+IEkgaGVhcmQgZnJvbSBLZW50IHRoYXQNCj4+Pj4+ PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmFsbGluLW5ldG1vZC1hbGFybS1t b2R1bGUgd2FzIA0KPj4+Pj4+IG1vdmluZyB0byBDQ0FNUCBidXQgSSBkb27igJl0IHNlZSBhbnkg bWVudGlvbiBvZiBpdCBhdCANCj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dn L2NjYW1wL2RvY3VtZW50cyAoYWx0aG91Z2ggaXQgaXMgDQo+Pj4+Pj4gc2hvd24gYXMgYSBkZXBl bmRlbmN5IGF0IA0KPj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvY2NhbXAv ZGVwcy9zdmcpLiBJcyBhbnkgbW9yZSBpbmZvIGF2YWlsYWJsZSBwbGVhc2U/DQo+Pj4+Pj4NCj4+ Pj4+PiBUaGFua3MsDQo+Pj4+Pj4gV2lsbGlhbQ0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4+ IG5ldG1vZEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2Qg bWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCg== From nobody Mon Jun 26 04:23:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54C8126C7A; Mon, 26 Jun 2017 04:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 c8lbuiIOTcfD; Mon, 26 Jun 2017 04:23:21 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF65120454; Mon, 26 Jun 2017 04:23:21 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v5QAtVfH025968; Mon, 26 Jun 2017 07:01:23 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2baems90th-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Jun 2017 07:01:22 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5QB1Lag008965; Mon, 26 Jun 2017 07:01:22 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v5QB1DlA008863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jun 2017 07:01:16 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 26 Jun 2017 11:00:59 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.17]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0319.002; Mon, 26 Jun 2017 07:00:59 -0400 From: "BRUNGARD, DEBORAH A" To: Daniele Ceccarelli , Lou Berger , stefan vallin , Vladimir Vassilev CC: "ccamp-chairs@ietf.org" , "netmod@ietf.org" , "David Sinicrope (david.sinicrope@ericsson.com)" , William Lupton , "ccamp@ietf.org" Thread-Topic: [netmod] draft-vallin-netmod-alarm-module status and plans Thread-Index: AQHS2gawnJV12AqGIEmsHiaF6Z83aKIxEq4AgAAr8oCAAdjGAIABkG+AgAAiAgCAAnAXAP//3EEA Date: Mon, 26 Jun 2017 11:00:58 +0000 Message-ID: References: <4873921A-9782-4943-A076-C8D9E79E3991@broadband-forum.org> <9bdc2746-346f-9288-ba2b-f738896373fb@transpacket.com> <15cdb826598.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.211.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-26_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706260187 Archived-At: Subject: Re: [netmod] draft-vallin-netmod-alarm-module status and plans X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 11:23:24 -0000 QXMgRGFuaWVsZSBzYXlzLCBpZiB0aGUgYXV0aG9ycyBhcmUgaW50ZXJlc3RlZCB0byBwcm9ncmVz cyB0aGlzIGRyYWZ0LCBpdCBzaG91bGQgYmUgc3VibWl0dGVkIHRvIGNjYW1wLg0KDQpUaGVyZSB3 YXMgYW4gZWFybGllciBjb21tZW50IGluIHRoaXMgdGhyZWFkIGJ5IGFuIGluZGl2aWR1YWwsIFdp bGxpYW0gTHVwdG9uLCBzYXlpbmcgIldlIGF0IHRoZSBCcm9hZGJhbmQgRm9ydW0gKEJCRikgd291 bGQgbGlrZSB0byByZWl0ZXJhdGUgb3VyIGludGVyZXN0IGluIHRoZSBkcmFmdC12YWxsaW4tbmV0 bW9kLWFsYXJtLW1vZHVsZSBkcmFmdC4iDQoNCldpbGxpYW0sIElFVEYgaGFzIGEgbGlhaXNvbiBy ZWxhdGlvbnNoaXAgd2l0aCBCQkYuIFRoZSBhcHByb3ByaWF0ZSBjaGFubmVsIHRvIGV4cHJlc3Mg YW5vdGhlciBncm91cCdzIGludGVyZXN0IGlzIHZpYSBsaWFpc29uIG9yIHRoZSBsaWFpc29uIGNv bnRhY3QuIEkgY2hlY2tlZCB0aGUgbGlhaXNvbnMgYW5kIEkgZG9uJ3Qgc2VlIGFueSBsaWFpc29u IGZyb20gQkJGIG9uIHRoaXMgdG9waWMuIFRoZSBsaWFpc29uIGNvbnRhY3QgaXMgRGF2ZSBTaW5p Y3JvcGUgKGNjJ2QpLiBQbGVhc2Ugd29yayB3aXRoIGhpbSB0byBwcm92aWRlIGNvbW11bmljYXRp b24gb24gYmVoYWxmIG9mIEJCRiB0byBJRVRGLg0KDQpJdCB3b3VsZCBiZSBtb3N0IGhlbHBmdWwg aWYgQkJGIGNvdWxkIHByb3ZpZGUgcmVxdWlyZW1lbnRzIGFuZCB1c2Ugc2NlbmFyaW9zIGZvciB0 aGVpciBuZWVkcyBvbiB0aGlzIGl0ZW0uDQoNClRoYW5rcywNCkRlYm9yYWgNCihSb3V0aW5nIEFE KQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERhbmllbGUgQ2VjY2Fy ZWxsaSBbbWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IE1v bmRheSwgSnVuZSAyNiwgMjAxNyA0OjIzIEFNDQo+IFRvOiBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxh Ym4ubmV0Pjsgc3RlZmFuIHZhbGxpbiA8c3RlZmFuQHdhbGxhbi5zZT47IFZsYWRpbWlyDQo+IFZh c3NpbGV2IDx2bGFkaW1pckB0cmFuc3BhY2tldC5jb20+DQo+IENjOiBjY2FtcC1jaGFpcnNAaWV0 Zi5vcmc7IG5ldG1vZEBpZXRmLm9yZzsgQlJVTkdBUkQsIERFQk9SQUggQQ0KPiA8ZGIzNTQ2QGF0 dC5jb20+DQo+IFN1YmplY3Q6IFJFOiBbbmV0bW9kXSBkcmFmdC12YWxsaW4tbmV0bW9kLWFsYXJt LW1vZHVsZSBzdGF0dXMgYW5kIHBsYW5zDQo+IA0KPiBIaSBWbGFkaW1pciwNCj4gDQo+IA0KPiAN Cj4gdGhhdCBzaW5nbGUgZW1haWwgZG9lc24ndCByZWZsZWN0IHRoZSBjb25zZW5zdXMgb2YgdGhl IFdHLiBUaGUgY2hhaXJzIGFuZCB0aGUNCj4gQURzIGFncmVlZCB0aGF0IENDQU1QIGlzIHRoZSBy aWdodCBwbGFjZSB0byBwcm9ncmVzcyB0aGUgZHJhZnQuDQo+IA0KPiANCj4gDQo+IEJSDQo+IA0K PiBEYW5pZWxlDQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IA0K PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4gDQo+IFNlbnQ6 IHNhYmF0byAyNCBnaXVnbm8gMjAxNyAyMToxMA0KPiANCj4gVG86IHN0ZWZhbiB2YWxsaW4gPHN0 ZWZhbkB3YWxsYW4uc2U+OyBWbGFkaW1pciBWYXNzaWxldg0KPiA8dmxhZGltaXJAdHJhbnNwYWNr ZXQuY29tPg0KPiANCj4gQ2M6IGNjYW1wLWNoYWlyc0BpZXRmLm9yZzsgbmV0bW9kQGlldGYub3Jn OyBEZWJvcmFoIEJydW5nYXJkDQo+IChkYnJ1bmdhcmRAYXR0LmNvbSkgPGRicnVuZ2FyZEBhdHQu Y29tPg0KPiANCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIGRyYWZ0LXZhbGxpbi1uZXRtb2QtYWxh cm0tbW9kdWxlIHN0YXR1cyBhbmQgcGxhbnMNCj4gDQo+IA0KPiANCj4gTXkgdW5kZXJzdGFuZGlu ZyBpcyB0aGUgc2FtZSBhcyBLZW50J3MuIFRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIGJyb3VnaHQg aW50bw0KPiBjY2FtcC4uLg0KPiANCj4gDQo+IA0KPiBMb3UNCj4gDQo+IA0KPiANCj4gDQo+IA0K PiBPbiBKdW5lIDI0LCAyMDE3IDE6MDg6MzUgUE0gc3RlZmFuIHZhbGxpbiA8c3RlZmFuQHdhbGxh bi5zZT4gd3JvdGU6DQo+IA0KPiANCj4gDQo+ID4gKzENCj4gDQo+ID4NCj4gDQo+ID4gTXZoIHN0 ZWZhbg0KPiANCj4gPiArNDYoMCk3MDUyMzMyNjINCj4gDQo+ID4NCj4gDQo+ID4+IDIzIGp1bmkg MjAxNyBrbC4gMTk6MTQgc2tyZXYgVmxhZGltaXIgVmFzc2lsZXYgPHZsYWRpbWlyQHRyYW5zcGFj a2V0LmNvbT46DQo+IA0KPiA+Pg0KPiANCj4gPj4gSGkgS2VudCwNCj4gDQo+ID4+DQo+IA0KPiA+ PiBJIGZvbGxvd2VkIHRoZSBDQ0FNUCB0aHJlYWQgY29uY2x1ZGluZyB3aXRoDQo+IA0KPiA+PiBo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsLQ0KPiAyRGFyY2hpdmVfd2ViX2NjYW1wX2N1cnJlbnRfbXNnMTgxNDIuaHRt bCZkPUR3SUdhUSZjPUxGWVotDQo+IG85X0hVTWVNVFNRaWN2aklnJnI9LQ0KPiB1ZkxxT250dDZM ZWpMTVRiTjNRcGpZSHhzT2J4bVBLUmhpRjNGbm1vSTAmbT1pcnNwYTZOY1hQS0RTNDJtanZfDQo+ IEMtDQo+IDdOTmV1b1RGSF83bVZBaElJNnNWdHcmcz1GQk1ENjZQNTh2eW9od2s1M2xGZnBJQk5G eDl1eEdVbXpONkgNCj4gV3B6OGdtMCZlPSAgYW5kDQo+IA0KPiA+PiBJTU8gdGhlcmUgaXMgY29u c2Vuc3VzIHRoYXQgdGhlIGRyYWZ0IHNob3VsZCBiZSBtb3ZlIGJhY2sgdG8gbmV0bW9kLg0KPiAN Cj4gPj4NCj4gDQo+ID4+IFZsYWRpbWlyDQo+IA0KPiA+Pg0KPiANCj4gPj4NCj4gDQo+ID4+PiBP biAwNi8yMi8yMDE3IDAzOjAyIFBNLCBLZW50IFdhdHNlbiB3cm90ZToNCj4gDQo+ID4+PiBIaSBX aWxsaWFtLA0KPiANCj4gPj4+DQo+IA0KPiA+Pj4gUGxlYXNlIGJlIGF3YXJlIHRoYXQgdGhpcyBk cmFmdCBpcyBtb3ZpbmcgdG8gdGhlIENDQU1QIFdHLiAgSSBkb24ndA0KPiANCj4gPj4+IHRoaW5r IHRoZSBjY2FtcC12ZXJzaW9uIG9mIHRoZSBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQgeWV0LCBidXQg aXQNCj4gDQo+ID4+PiB3aWxsIGJlIGRpc2N1c3NlZCBpbiB0aGF0IFdHIChhbmQgbm90IE5FVE1P RCkgaW4gUHJhZ3VlLg0KPiANCj4gPj4+DQo+IA0KPiA+Pj4gUmVnYXJkcywNCj4gDQo+ID4+PiBL ZW50DQo+IA0KPiA+Pj4NCj4gDQo+ID4+Pg0KPiANCj4gPj4+PiBPbiBKdW4gMjIsIDIwMTcsIGF0 IDY6MjUgQU0sIFdpbGxpYW0gTHVwdG9uDQo+IA0KPiA+Pj4+IDx3bHVwdG9uQGJyb2FkYmFuZC1m b3J1bS5vcmc+DQo+IA0KPiA+Pj4+IHdyb3RlOg0KPiANCj4gPj4+Pg0KPiANCj4gPj4+PiBEZWFy IGFsbCwNCj4gDQo+ID4+Pj4NCj4gDQo+ID4+Pj4gV2UgYXQgdGhlIEJyb2FkYmFuZCBGb3J1bSAo QkJGKSB3b3VsZCBsaWtlIHRvIHJlaXRlcmF0ZSBvdXINCj4gDQo+ID4+Pj4gaW50ZXJlc3QgaW4g dGhlIGRyYWZ0LXZhbGxpbi1uZXRtb2QtYWxhcm0tbW9kdWxlIGRyYWZ0Lg0KPiANCj4gPj4+Pg0K PiANCj4gPj4+PiBXZSB3aWxsIGFsc28gaGF2ZSBzb21lIHRlY2huaWNhbCBjb21tZW50cyAvIHN1 Z2dlc3Rpb25zIChpbnRlcm5hbA0KPiANCj4gPj4+PiBkaXNjdXNzaW9uIGlzIG9uZ29pbmcpIHRo YXQgd2Ugd2lsbCBzaGFyZSB3aXRoIE5FVE1PRCBhcyBzb29uIGFzDQo+IHBvc3NpYmxlLg0KPiAN Cj4gPj4+Pg0KPiANCj4gPj4+PiBUaGFua3MsDQo+IA0KPiA+Pj4+IFdpbGxpYW0NCj4gDQo+ID4+ Pj4NCj4gDQo+ID4+Pj4+IE9uIDMxIE1heSAyMDE3LCBhdCAxMzowOCwgQmVub2l0IENsYWlzZSA8 YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gPj4+Pj4NCj4gDQo+ID4+Pj4+IFdpbGxp YW0sDQo+IA0KPiA+Pj4+Pg0KPiANCj4gPj4+Pj4gVGhpcyB3YXMgZGlzY3Vzc2VkIHdpdGggdGhl IGF1dGhvcnMsIHRoZSBORVRNT0QgY2hhaXJzLCBhbmQgdGhlIFJURw0KPiBBRCBEZWJvcmFoLg0K PiANCj4gPj4+Pj4gVGhlIGFkdmljZSB3YXMgZm9yIHRoZSBhdXRob3JzIHRvIHJhaXNlIHRoZSBk cmFmdCBpbiBjY2FtcCBhbmQgdHJ5DQo+IA0KPiA+Pj4+PiB0byBwcm9ncmVzcyBpdCB0aGVyZS4N Cj4gDQo+ID4+Pj4+DQo+IA0KPiA+Pj4+PiBUaGUgYXV0aG9ycyB1cGRhdGVkIHRoZWlyIGRyYWZ0 IHRvIHZlcnNpb24gMiBhbmQgcGluZ2VkIHRoZSBDQ0FNUA0KPiANCj4gPj4+Pj4gbWFpbGluZyBs aXN0IChodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+ IDNBX193d3cuaWV0Zi5vcmdfbWFpbC0NCj4gMkRhcmNoaXZlX3dlYl9jY2FtcF9jdXJyZW50X21z ZzE4MTI0Lmh0bWwmZD1Ed0lHYVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZyPS0NCj4g dWZMcU9udHQ2TGVqTE1UYk4zUXBqWUh4c09ieG1QS1JoaUYzRm5tb0kwJm09aXJzcGE2TmNYUEtE UzQybWp2Xw0KPiBDLQ0KPiA3Tk5ldW9URkhfN21WQWhJSTZzVnR3JnM9TkxiMlZGSVJTRElaNTVk azJwTzRndkR3UnMwQ3c3YlBiQThRaA0KPiBjZUFzNW8mZT0gKS4NCj4gDQo+ID4+Pj4+IEZyb20g dGhhdCBlbWFpbCB0aHJlYWQsIGl0IHNlZW1zIHRoZXJlIGlzIGludGVyZXN0IGluIHRoZSB3b3Jr LA0KPiANCj4gPj4+Pj4gYnV0IHdoZXJlIHRvIGRvIHRoZSB3b3JrIGlzIG5vdCBjbGVhci4NCj4g DQo+ID4+Pj4+DQo+IA0KPiA+Pj4+PiBNeSBhZHZpY2UgdG8gdGhlIGF1dGhvcnM6IGNvbnRpbnVl IHByb2dyZXNzIHRoaXMgd29yayBhbmQgaWYgQ0NBTVANCj4gDQo+ID4+Pj4+IGlzIG5vdCBpbnRl cmVzdGVkIG9yIGNvbnNpZGVyIHRoaXMgd29yayB0b28gZ2VuZXJpYywgYnJpbmcgaXQgYmFjaw0K PiANCj4gPj4+Pj4gdG8gTkVUTU9EIGFuZCB3ZSdsbCBmb2xsb3cgbm9ybWFsIFdHIHByb2Nlc3Mu DQo+IA0KPiA+Pj4+Pg0KPiANCj4gPj4+Pj4gUmVnYXJkcywgQmVub2l0DQo+IA0KPiA+Pj4+Pj4g QWxsLA0KPiANCj4gPj4+Pj4+DQo+IA0KPiA+Pj4+Pj4gSSBoZWFyZCBmcm9tIEtlbnQgdGhhdA0K PiANCj4gPj4+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0NCj4gM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkR2YWxsaW4tMkRuZXRtb2Qt MkRhbGFybS0NCj4gMkRtb2R1bGUmZD1Ed0lHYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9 LQ0KPiB1ZkxxT250dDZMZWpMTVRiTjNRcGpZSHhzT2J4bVBLUmhpRjNGbm1vSTAmbT1pcnNwYTZO Y1hQS0RTNDJtanZfDQo+IEMtDQo+IDdOTmV1b1RGSF83bVZBaElJNnNWdHcmcz1zeUNTM3lCcUFu TUVIVmVfc2t3dTZMRzlEUDVGWms2NENKVkJyDQo+IHVuWmh4WSZlPSAgd2FzDQo+IA0KPiA+Pj4+ Pj4gbW92aW5nIHRvIENDQU1QIGJ1dCBJIGRvbuKAmXQgc2VlIGFueSBtZW50aW9uIG9mIGl0IGF0 DQo+IA0KPiA+Pj4+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLQ0KPiAzQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfd2dfY2NhbXBfZG9jdW1lbnRzJmQ9 RHdJR2FRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj0tDQo+IHVmTHFPbnR0NkxlakxN VGJOM1FwallIeHNPYnhtUEtSaGlGM0ZubW9JMCZtPWlyc3BhNk5jWFBLRFM0Mm1qdl8NCj4gQy0N Cj4gN05OZXVvVEZIXzdtVkFoSUk2c1Z0dyZzPW02TnJXT21GZ19UX3ZfX21EM0ZhNXJxcTM0WXVN UlRvWDkNCj4gV3pRdk5WbkQ0JmU9ICAoYWx0aG91Z2ggaXQgaXMNCj4gDQo+ID4+Pj4+PiBzaG93 biBhcyBhIGRlcGVuZGVuY3kgYXQNCj4gDQo+ID4+Pj4+PiBodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ193 Z19jY2FtcF9kZXBzX3N2ZyZkPUR3SUdhUSZjPUxGWVotDQo+IG85X0hVTWVNVFNRaWN2aklnJnI9 LQ0KPiB1ZkxxT250dDZMZWpMTVRiTjNRcGpZSHhzT2J4bVBLUmhpRjNGbm1vSTAmbT1pcnNwYTZO Y1hQS0RTNDJtanZfDQo+IEMtDQo+IDdOTmV1b1RGSF83bVZBaElJNnNWdHcmcz1TUklHUTVMeFVF NWFXdGpOc1hrR2ROdGJMN1luVmVuSzYxUXVzbA0KPiA5QkVGRSZlPSApLiBJcyBhbnkgbW9yZSBp bmZvIGF2YWlsYWJsZSBwbGVhc2U/DQo+IA0KPiA+Pj4+Pj4NCj4gDQo+ID4+Pj4+PiBUaGFua3Ms DQo+IA0KPiA+Pj4+Pj4gV2lsbGlhbQ0KPiANCj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gPj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0 DQo+IA0KPiA+Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPiANCj4gPj4+PiBodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lHYVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJ ZyZyPS0NCj4gdWZMcU9udHQ2TGVqTE1UYk4zUXBqWUh4c09ieG1QS1JoaUYzRm5tb0kwJm09aXJz cGE2TmNYUEtEUzQybWp2Xw0KPiBDLTdOTmV1b1RGSF83bVZBaElJNnNWdHcmcz16SUpJTzFpTFBi anRkVHNVa25UUzZkN3BtbnktT3YtDQo+IHYxSXMzV29BeXVoTSZlPQ0KPiANCj4gPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiA+Pj4gbmV0 bW9kIG1haWxpbmcgbGlzdA0KPiANCj4gPj4+IG5ldG1vZEBpZXRmLm9yZw0KPiANCj4gPj4+IGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUdhUSZjPUxGWVotDQo+IG85 X0hVTWVNVFNRaWN2aklnJnI9LQ0KPiB1ZkxxT250dDZMZWpMTVRiTjNRcGpZSHhzT2J4bVBLUmhp RjNGbm1vSTAmbT1pcnNwYTZOY1hQS0RTNDJtanZfDQo+IEMtN05OZXVvVEZIXzdtVkFoSUk2c1Z0 dyZzPXpJSklPMWlMUGJqdGRUc1VrblRTNmQ3cG1ueS1Pdi0NCj4gdjFJczNXb0F5dWhNJmU9DQo+ IA0KPiA+Pg0KPiANCj4gPg0KPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiANCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IA0KPiA+IG5l dG1vZEBpZXRmLm9yZw0KPiANCj4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRt b2QmZD1Ed0lHYVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZyPS0NCj4gdWZMcU9udHQ2 TGVqTE1UYk4zUXBqWUh4c09ieG1QS1JoaUYzRm5tb0kwJm09aXJzcGE2TmNYUEtEUzQybWp2Xw0K PiBDLTdOTmV1b1RGSF83bVZBaElJNnNWdHcmcz16SUpJTzFpTFBianRkVHNVa25UUzZkN3Btbnkt T3YtDQo+IHYxSXMzV29BeXVoTSZlPQ0KPiANCj4gDQo+IA0KPiANCg0K From nobody Mon Jun 26 09:44:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B205F12EAED; Mon, 26 Jun 2017 09:44:54 -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, RP_MATCHES_RCVD=-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 p2fLyAiV-UOC; Mon, 26 Jun 2017 09:44:53 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13634129BC4; Mon, 26 Jun 2017 09:44:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CCF7CF4B; Mon, 26 Jun 2017 18:44:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id UpMZNrfvU2Y1; Mon, 26 Jun 2017 18:44:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 26 Jun 2017 18:44:51 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADD0A2009B; Mon, 26 Jun 2017 18:44:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LGtobbbH2Ck4; Mon, 26 Jun 2017 18:44:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1C692009F; Mon, 26 Jun 2017 18:44:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 729173FD2BEA; Mon, 26 Jun 2017 18:44:46 +0200 (CEST) Date: Mon, 26 Jun 2017 18:44:46 +0200 From: Juergen Schoenwaelder To: Lou Berger Cc: Andy Bierman , "netmod@ietf.org" , draft-ietf-netmod-rfc6087bis@ietf.org Message-ID: <20170626164446.GC3341@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Andy Bierman , "netmod@ietf.org" , draft-ietf-netmod-rfc6087bis@ietf.org References: <149784804955.10723.13177357489958504644@ietfa.amsl.com> <3997511b-8bcf-3598-23aa-aafc96f9417e@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Small comment on draft-ietf-netmod-rfc6087bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 16:44:55 -0000 On Fri, Jun 23, 2017 at 04:53:12PM -0400, Lou Berger wrote: > > The copyright says " identified as authors of the code. " so it seems to > me that all copyright holders need to be identified in the module. I > have no idea that the test/bar is to become a copyright holder, but can > ask for an official trust position if needed. > I suggest to not open pandora's box. Using the names of the authors / editors of the RFC has practically worked for a few decades with hundreds of MIB modules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 26 12:06:53 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F242D12EB4D for ; Mon, 26 Jun 2017 12:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bp75HGB-g-u0 for ; Mon, 26 Jun 2017 12:06:50 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1846D126B71 for ; Mon, 26 Jun 2017 12:06:50 -0700 (PDT) Received: from localhost (h-155-4-133-90.NA.cust.bahnhof.se [155.4.133.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 27D2C1AE0351; Mon, 26 Jun 2017 21:06:49 +0200 (CEST) Date: Mon, 26 Jun 2017 21:06:49 +0200 (CEST) Message-Id: <20170626.210649.1449063638063213542.mbj@tail-f.com> To: wangzitao@huawei.com Cc: lberger@labn.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <149735725207.17561.16997653317514816844@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] Some comments on yang tree diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 19:06:52 -0000 SGksDQoNCndhbmd6aXRhbyA8d2FuZ3ppdGFvQGh1YXdlaS5jb20+IHdyb3RlOg0KPiBIaSBBdXRo b3JzLA0KPiANCj4gSSBoYXZlIHJlYWQgdGhpcyBkcmFmdCBhbmQgdGhpbmsgaXQgaXMgdmVyeSB1 c2VmdWwuIEhvd2V2ZXIsIElNSE8sDQo+IHRoZXJlIGFyZSBhbHNvIHNvbWV0aGluZyBuZWVkIHRv IGltcHJvdmVkLiBGb3IgZXhhbXBsZToNCj4gIyBJbiBzZWN0aW9uMiBUcmVlIERpYWdyYW0gU3lu dGF4LCBpdCBkZXNjcmliZXMgIiAhICBmb3IgYSBwcmVzZW5jZQ0KPiBjb250YWluZXIiLCBidXQg aW4gc29tZSBkcmFmdC8gUkZDIHRoZSBjb250YWluZXIgbm90IGJlIG1hcmtlZCBieQ0KPiAiISIs IGZvciBleGFtcGxlICJpZXRmLWludGVyZmFjZSIgW1JGQzcyMjNdLiANCg0KVGhlcmUgYXJlIG5v IHByZXNlbmNlIGNvbnRhaW5lcnMgaW4gUkZDIDcyMjMsIHdoaWNoIGlzIHdoeSAiISIgaXMgbm90 DQp1c2VkIGluIHRoYXQgdHJlZSBkaWFncmFtLg0KDQoNCg0KL21hcnRpbg0KDQoNCj4gIyBBbmQg SSBzdWdnZXN0IHRvIGhpZ2hsaWdodCB0aGUgc3ltYm9sICItdyIsIGl0IHVzdWFsbHkgYXBwZWFy cyBpbg0KPiAiaW5wdXQiIG9mIFJQQywgZm9yIGV4YW1wbGUgImlldGYteWFuZy1wdXNoIg0KPiBb ZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaF0gDQo+IA0KPiBQbGVhc2UgY29uc2lkZXIgbXkg c3VnZ2VzdGlvbi4NCj4gDQo+IEJlc3QgUmVnYXJkcyENCj4gLU1pY2hhZWwNCj4gDQo+IC0tLS0t 6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91 bmNlc0BpZXRmLm9yZ10g5Luj6KGoIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiDlj5HpgIHm l7bpl7Q6IDIwMTflubQ25pyIMTPml6UgMjA6MzQNCj4g5pS25Lu25Lq6OiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmcNCj4g5oqE6YCBOiBuZXRtb2RAaWV0Zi5vcmcNCj4g5Li76aKYOiBbbmV0bW9kXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMtMDAudHh0DQo+ IA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBORVRDT05GIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2Ugb2YgdGhlIElFVEYuDQo+ IA0KPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFlBTkcgVHJlZSBEaWFncmFtcw0KPiAgICAg ICAgIEF1dGhvcnMgICAgICAgICA6IE1hcnRpbiBCam9ya2x1bmQNCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBMb3UgQmVyZ2VyDQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5l dG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMtMDAudHh0DQo+IAlQYWdlcyAgICAgICAgICAgOiA0DQo+ IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA2LTEzDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhp cyBkb2N1bWVudCBjYXB0dXJlcyB0aGUgY3VycmVudCBzeW50YXggdXNlZCBpbiBZQU5HIG1vZHVs ZSBUcmVlDQo+ICAgIERpYWdyYW1zLiAgVGhlIHB1cnBvc2Ugb2YgdGhlIGRvY3VtZW50IGlzIHRv IHByb3ZpZGUgYSBzaW5nbGUNCj4gICAgbG9jYXRpb24gZm9yIHRoaXMgZGVmaW5pdGlvbi4gIFRo aXMgc3ludGF4IG1heSBiZSB1cGRhdGVkIGZyb20gdGltZQ0KPiAgICB0byB0aW1lIGJhc2VkIG9u IHRoZSBldm9sdXRpb24gb2YgdGhlIFlBTkcgbGFuZ3VhZ2UuDQo+IA0KPiANCj4gVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFt cy8NCj4gDQo+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoN Cj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXlhbmctdHJl ZS1kaWFncmFtcy0wMA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtcy0wMA0KPiANCj4gDQo+IFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Tue Jun 27 02:22:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE70C1293E1; Tue, 27 Jun 2017 02:22:32 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oseQe3-_1ejJ; Tue, 27 Jun 2017 02:22:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4505112EC06; Tue, 27 Jun 2017 02:22:30 -0700 (PDT) Received: from localhost (h-155-4-133-90.NA.cust.bahnhof.se [155.4.133.90]) by mail.tail-f.com (Postfix) with ESMTPSA id CA8611AE0385; Tue, 27 Jun 2017 11:22:27 +0200 (CEST) Date: Tue, 27 Jun 2017 11:22:28 +0200 (CEST) Message-Id: <20170627.112228.127070804981926989.mbj@tail-f.com> To: daniele.ceccarelli@ericsson.com Cc: lberger@labn.net, stefan@wallan.se, vladimir@transpacket.com, CCamp-chairs@ietf.org, dbrungard@att.com, netmod@ietf.org, ccamp@ietf.org From: Martin Bjorklund In-Reply-To: References: <15cdb826598.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] draft-vallin-netmod-alarm-module status and plans X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 09:22:33 -0000 SGkgRGFuaWVsZSwNCg0KW2FkZGluZyBDQ0FNUCB0byBDQ10NCg0KRGFuaWVsZSBDZWNjYXJlbGxp IDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gSGkgVmxhZGltaXIs DQo+IA0KPiB0aGF0IHNpbmdsZSBlbWFpbCBkb2Vzbid0IHJlZmxlY3QgdGhlIGNvbnNlbnN1cyBv ZiB0aGUgV0cuIFRoZSBjaGFpcnMNCj4gYW5kIHRoZSBBRHMgYWdyZWVkIHRoYXQgQ0NBTVAgaXMg dGhlIHJpZ2h0IHBsYWNlIHRvIHByb2dyZXNzIHRoZQ0KPiBkcmFmdC4NCg0KT2suICBJZiBJIHVu ZGVyc3RhbmQgdGhlIG1vdGl2YXRpb24gY29ycmVjdGx5LCB0aGlzIGRlY2lzaW9uIGlzIGJhc2Vk DQpvbiB0aGUgZmFjdCB0aGF0IHRoZXJlIGFyZSBwZW9wbGUgYWN0aXZlIGluIHRoZSBhbGFybSB3 b3JrIGluIElUVSBhbHNvDQphY3RpdmUgaW4gQ0NBTVAuDQoNCkkgYXNzdW1lIHRoZSBwcm9jZXNz IGlzIHN0aWxsIHRoYXQgdGhlIENDQU1QIFdHIG11c3QgZm9ybWFsbHkgYWRvcHQNCnRoaXMgaW5k aXZpZHVhbCBkcmFmdCBiZWZvcmUgaXQgaXMgcG9zdGVkIGFzIGEgZHJhZnQtY2NhbXAtIGRvY3Vt ZW50Lg0KDQpXZSBwb3N0ZWQgYSBsaW5rIHRvIHRoZSBkb2N1bWVudCB0byBDQ0FNUCwgYnV0IGRp ZG4ndCBnZXQgbXVjaA0KZmVlZGJhY2suICBEbyB5b3Ugd2FudCB1cyB0byBwb3N0IGFub3RoZXIg bGluayB0byB0aGUgZG9jdW1lbnQgYW5kDQphZ2FpbiBhc2sgZm9yIGZlZWRiYWNrPw0KDQoNCi9t YXJ0aW4NCg0KDQo+IEJSDQo+IERhbmllbGUgIA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0KPiBT ZW50OiBzYWJhdG8gMjQgZ2l1Z25vIDIwMTcgMjE6MTANCj4gVG86IHN0ZWZhbiB2YWxsaW4gPHN0 ZWZhbkB3YWxsYW4uc2U+OyBWbGFkaW1pciBWYXNzaWxldg0KPiA8dmxhZGltaXJAdHJhbnNwYWNr ZXQuY29tPg0KPiBDYzogY2NhbXAtY2hhaXJzQGlldGYub3JnOyBuZXRtb2RAaWV0Zi5vcmc7IERl Ym9yYWggQnJ1bmdhcmQNCj4gKGRicnVuZ2FyZEBhdHQuY29tKSA8ZGJydW5nYXJkQGF0dC5jb20+ DQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBkcmFmdC12YWxsaW4tbmV0bW9kLWFsYXJtLW1vZHVs ZSBzdGF0dXMgYW5kDQo+IHBsYW5zDQo+IA0KPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoZSBzYW1l IGFzIEtlbnQncy4gVGhpcyBkb2N1bWVudCBzaG91bGQgYmUNCj4gYnJvdWdodCBpbnRvIGNjYW1w Li4uDQo+IA0KPiBMb3UNCj4gDQo+IA0KPiBPbiBKdW5lIDI0LCAyMDE3IDE6MDg6MzUgUE0gc3Rl ZmFuIHZhbGxpbiA8c3RlZmFuQHdhbGxhbi5zZT4gd3JvdGU6DQo+IA0KPiA+ICsxDQo+ID4NCj4g PiBNdmggc3RlZmFuDQo+ID4gKzQ2KDApNzA1MjMzMjYyDQo+ID4NCj4gPj4gMjMganVuaSAyMDE3 IGtsLiAxOToxNCBza3JldiBWbGFkaW1pciBWYXNzaWxldg0KPiA+PiA8dmxhZGltaXJAdHJhbnNw YWNrZXQuY29tPjoNCj4gPj4NCj4gPj4gSGkgS2VudCwNCj4gPj4NCj4gPj4gSSBmb2xsb3dlZCB0 aGUgQ0NBTVAgdGhyZWFkIGNvbmNsdWRpbmcgd2l0aCANCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9jY2FtcC9jdXJyZW50L21zZzE4MTQyLmh0bWwgYW5kIA0KPiA+ PiBJTU8gdGhlcmUgaXMgY29uc2Vuc3VzIHRoYXQgdGhlIGRyYWZ0IHNob3VsZCBiZSBtb3ZlIGJh Y2sgdG8gbmV0bW9kLg0KPiA+Pg0KPiA+PiBWbGFkaW1pcg0KPiA+Pg0KPiA+Pg0KPiA+Pj4gT24g MDYvMjIvMjAxNyAwMzowMiBQTSwgS2VudCBXYXRzZW4gd3JvdGU6DQo+ID4+PiBIaSBXaWxsaWFt LA0KPiA+Pj4NCj4gPj4+IFBsZWFzZSBiZSBhd2FyZSB0aGF0IHRoaXMgZHJhZnQgaXMgbW92aW5n IHRvIHRoZSBDQ0FNUCBXRy4gIEkgZG9uJ3QgDQo+ID4+PiB0aGluayB0aGUgY2NhbXAtdmVyc2lv biBvZiB0aGUgZHJhZnQgaGFzIGJlZW4gcG9zdGVkIHlldCwgYnV0IGl0IA0KPiA+Pj4gd2lsbCBi ZSBkaXNjdXNzZWQgaW4gdGhhdCBXRyAoYW5kIG5vdCBORVRNT0QpIGluIFByYWd1ZS4NCj4gPj4+ DQo+ID4+PiBSZWdhcmRzLA0KPiA+Pj4gS2VudA0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4gT24gSnVu IDIyLCAyMDE3LCBhdCA2OjI1IEFNLCBXaWxsaWFtIEx1cHRvbiANCj4gPj4+PiA8d2x1cHRvbkBi cm9hZGJhbmQtZm9ydW0ub3JnPg0KPiA+Pj4+IHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4gRGVhciBh bGwsDQo+ID4+Pj4NCj4gPj4+PiBXZSBhdCB0aGUgQnJvYWRiYW5kIEZvcnVtIChCQkYpIHdvdWxk IGxpa2UgdG8gcmVpdGVyYXRlIG91ciANCj4gPj4+PiBpbnRlcmVzdCBpbiB0aGUgZHJhZnQtdmFs bGluLW5ldG1vZC1hbGFybS1tb2R1bGUgZHJhZnQuDQo+ID4+Pj4NCj4gPj4+PiBXZSB3aWxsIGFs c28gaGF2ZSBzb21lIHRlY2huaWNhbCBjb21tZW50cyAvIHN1Z2dlc3Rpb25zIChpbnRlcm5hbCAN Cj4gPj4+PiBkaXNjdXNzaW9uIGlzIG9uZ29pbmcpIHRoYXQgd2Ugd2lsbCBzaGFyZSB3aXRoIE5F VE1PRCBhcyBzb29uIGFzDQo+ID4+Pj4gcG9zc2libGUuDQo+ID4+Pj4NCj4gPj4+PiBUaGFua3Ms DQo+ID4+Pj4gV2lsbGlhbQ0KPiA+Pj4+DQo+ID4+Pj4+IE9uIDMxIE1heSAyMDE3LCBhdCAxMzow OCwgQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0KPiA+Pj4+Pg0KPiA+ Pj4+PiBXaWxsaWFtLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGlzIHdhcyBkaXNjdXNzZWQgd2l0aCB0 aGUgYXV0aG9ycywgdGhlIE5FVE1PRCBjaGFpcnMsIGFuZCB0aGUgUlRHIEFEDQo+ID4+Pj4+IERl Ym9yYWguDQo+ID4+Pj4+IFRoZSBhZHZpY2Ugd2FzIGZvciB0aGUgYXV0aG9ycyB0byByYWlzZSB0 aGUgZHJhZnQgaW4gY2NhbXAgYW5kIHRyeSANCj4gPj4+Pj4gdG8gcHJvZ3Jlc3MgaXQgdGhlcmUu DQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZSBhdXRob3JzIHVwZGF0ZWQgdGhlaXIgZHJhZnQgdG8gdmVy c2lvbiAyIGFuZCBwaW5nZWQgdGhlIENDQU1QIA0KPiA+Pj4+PiBtYWlsaW5nIGxpc3QNCj4gPj4+ Pj4gKGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2NhbXAvY3VycmVudC9t c2cxODEyNC5odG1sKS4NCj4gPj4+Pj4gRnJvbSB0aGF0IGVtYWlsIHRocmVhZCwgaXQgc2VlbXMg dGhlcmUgaXMgaW50ZXJlc3QgaW4gdGhlIHdvcmssIA0KPiA+Pj4+PiBidXQgd2hlcmUgdG8gZG8g dGhlIHdvcmsgaXMgbm90IGNsZWFyLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBNeSBhZHZpY2UgdG8gdGhl IGF1dGhvcnM6IGNvbnRpbnVlIHByb2dyZXNzIHRoaXMgd29yayBhbmQgaWYgQ0NBTVAgDQo+ID4+ Pj4+IGlzIG5vdCBpbnRlcmVzdGVkIG9yIGNvbnNpZGVyIHRoaXMgd29yayB0b28gZ2VuZXJpYywg YnJpbmcgaXQgYmFjayANCj4gPj4+Pj4gdG8gTkVUTU9EIGFuZCB3ZSdsbCBmb2xsb3cgbm9ybWFs IFdHIHByb2Nlc3MuDQo+ID4+Pj4+DQo+ID4+Pj4+IFJlZ2FyZHMsIEJlbm9pdA0KPiA+Pj4+Pj4g QWxsLA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEkgaGVhcmQgZnJvbSBLZW50IHRoYXQNCj4gPj4+Pj4+ IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12YWxsaW4tbmV0bW9kLWFsYXJtLW1v ZHVsZSB3YXMgDQo+ID4+Pj4+PiBtb3ZpbmcgdG8gQ0NBTVAgYnV0IEkgZG9u4oCZdCBzZWUgYW55 IG1lbnRpb24gb2YgaXQgYXQgDQo+ID4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L3dnL2NjYW1wL2RvY3VtZW50cyAoYWx0aG91Z2ggaXQgaXMgDQo+ID4+Pj4+PiBzaG93biBhcyBh IGRlcGVuZGVuY3kgYXQgDQo+ID4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dn L2NjYW1wL2RlcHMvc3ZnKS4gSXMgYW55IG1vcmUgaW5mbw0KPiA+Pj4+Pj4gYXZhaWxhYmxlIHBs ZWFzZT8NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGFua3MsDQo+ID4+Pj4+PiBXaWxsaWFtDQo+ID4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+ PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4+Pj4gbmV0bW9kQGlldGYub3JnDQo+ID4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBuZXRtb2QgbWFp bGluZyBsaXN0DQo+ID4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4+DQo+ID4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxp c3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Tue Jun 27 03:31:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC5F126D73; Tue, 27 Jun 2017 03:31:35 -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 4nBSFx6fMgGe; Tue, 27 Jun 2017 03:31:32 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A709C120721; Tue, 27 Jun 2017 03:31:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 1B7491CA584; Tue, 27 Jun 2017 03:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Uyh7igkTavsf; Tue, 27 Jun 2017 03:31:10 -0700 (PDT) Received: from [192.168.1.127] (host86-158-252-85.range86-158.btcentralplus.com [86.158.252.85]) by c8a.amsl.com (Postfix) with ESMTPSA id 332151CA566; Tue, 27 Jun 2017 03:31:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: William Lupton In-Reply-To: Date: Tue, 27 Jun 2017 11:31:28 +0100 Cc: Daniele Ceccarelli , Lou Berger , stefan vallin , Vladimir Vassilev , "ccamp-chairs@ietf.org" , "netmod@ietf.org" , David Sinicrope , "ccamp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4873921A-9782-4943-A076-C8D9E79E3991@broadband-forum.org> <9bdc2746-346f-9288-ba2b-f738896373fb@transpacket.com> <15cdb826598.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [netmod] draft-vallin-netmod-alarm-module status and plans X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 10:31:35 -0000 Deborah, Sorry about this. I will work with Dave S as you recommend. Thanks, William > On 26 Jun 2017, at 12:00, BRUNGARD, DEBORAH A wrote: >=20 > As Daniele says, if the authors are interested to progress this draft, = it should be submitted to ccamp. >=20 > There was an earlier comment in this thread by an individual, William = Lupton, saying "We at the Broadband Forum (BBF) would like to reiterate = our interest in the draft-vallin-netmod-alarm-module draft." >=20 > William, IETF has a liaison relationship with BBF. The appropriate = channel to express another group's interest is via liaison or the = liaison contact. I checked the liaisons and I don't see any liaison from = BBF on this topic. The liaison contact is Dave Sinicrope (cc'd). Please = work with him to provide communication on behalf of BBF to IETF. >=20 > It would be most helpful if BBF could provide requirements and use = scenarios for their needs on this item. >=20 > Thanks, > Deborah > (Routing AD) >=20 >> -----Original Message----- >> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >> Sent: Monday, June 26, 2017 4:23 AM >> To: Lou Berger ; stefan vallin ; = Vladimir >> Vassilev >> Cc: ccamp-chairs@ietf.org; netmod@ietf.org; BRUNGARD, DEBORAH A >> >> Subject: RE: [netmod] draft-vallin-netmod-alarm-module status and = plans >>=20 >> Hi Vladimir, >>=20 >>=20 >>=20 >> that single email doesn't reflect the consensus of the WG. The chairs = and the >> ADs agreed that CCAMP is the right place to progress the draft. >>=20 >>=20 >>=20 >> BR >>=20 >> Daniele >>=20 >>=20 >>=20 >> -----Original Message----- >>=20 >> From: Lou Berger [mailto:lberger@labn.net] >>=20 >> Sent: sabato 24 giugno 2017 21:10 >>=20 >> To: stefan vallin ; Vladimir Vassilev >> >>=20 >> Cc: ccamp-chairs@ietf.org; netmod@ietf.org; Deborah Brungard >> (dbrungard@att.com) >>=20 >> Subject: Re: [netmod] draft-vallin-netmod-alarm-module status and = plans >>=20 >>=20 >>=20 >> My understanding is the same as Kent's. This document should be = brought into >> ccamp... >>=20 >>=20 >>=20 >> Lou >>=20 >>=20 >>=20 >>=20 >>=20 >> On June 24, 2017 1:08:35 PM stefan vallin wrote: >>=20 >>=20 >>=20 >>> +1 >>=20 >>>=20 >>=20 >>> Mvh stefan >>=20 >>> +46(0)705233262 >>=20 >>>=20 >>=20 >>>> 23 juni 2017 kl. 19:14 skrev Vladimir Vassilev = : >>=20 >>>>=20 >>=20 >>>> Hi Kent, >>=20 >>>>=20 >>=20 >>>> I followed the CCAMP thread concluding with >>=20 >>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail- >> 2Darchive_web_ccamp_current_msg18142.html&d=3DDwIGaQ&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3D- >> ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=3Dirspa6NcXPKDS42mjv_ >> C- >> 7NNeuoTFH_7mVAhII6sVtw&s=3DFBMD66P58vyohwk53lFfpIBNFx9uxGUmzN6H >> Wpz8gm0&e=3D and >>=20 >>>> IMO there is consensus that the draft should be move back to = netmod. >>=20 >>>>=20 >>=20 >>>> Vladimir >>=20 >>>>=20 >>=20 >>>>=20 >>=20 >>>>> On 06/22/2017 03:02 PM, Kent Watsen wrote: >>=20 >>>>> Hi William, >>=20 >>>>>=20 >>=20 >>>>> Please be aware that this draft is moving to the CCAMP WG. I = don't >>=20 >>>>> think the ccamp-version of the draft has been posted yet, but it >>=20 >>>>> will be discussed in that WG (and not NETMOD) in Prague. >>=20 >>>>>=20 >>=20 >>>>> Regards, >>=20 >>>>> Kent >>=20 >>>>>=20 >>=20 >>>>>=20 >>=20 >>>>>> On Jun 22, 2017, at 6:25 AM, William Lupton >>=20 >>>>>> >>=20 >>>>>> wrote: >>=20 >>>>>>=20 >>=20 >>>>>> Dear all, >>=20 >>>>>>=20 >>=20 >>>>>> We at the Broadband Forum (BBF) would like to reiterate our >>=20 >>>>>> interest in the draft-vallin-netmod-alarm-module draft. >>=20 >>>>>>=20 >>=20 >>>>>> We will also have some technical comments / suggestions (internal >>=20 >>>>>> discussion is ongoing) that we will share with NETMOD as soon as >> possible. >>=20 >>>>>>=20 >>=20 >>>>>> Thanks, >>=20 >>>>>> William >>=20 >>>>>>=20 >>=20 >>>>>>> On 31 May 2017, at 13:08, Benoit Claise = wrote: >>=20 >>>>>>>=20 >>=20 >>>>>>> William, >>=20 >>>>>>>=20 >>=20 >>>>>>> This was discussed with the authors, the NETMOD chairs, and the = RTG >> AD Deborah. >>=20 >>>>>>> The advice was for the authors to raise the draft in ccamp and = try >>=20 >>>>>>> to progress it there. >>=20 >>>>>>>=20 >>=20 >>>>>>> The authors updated their draft to version 2 and pinged the = CCAMP >>=20 >>>>>>> mailing list (https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mail- >> 2Darchive_web_ccamp_current_msg18124.html&d=3DDwIGaQ&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3D- >> ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=3Dirspa6NcXPKDS42mjv_ >> C- >> 7NNeuoTFH_7mVAhII6sVtw&s=3DNLb2VFIRSDIZ55dk2pO4gvDwRs0Cw7bPbA8Qh >> ceAs5o&e=3D ). >>=20 >>>>>>> =46rom that email thread, it seems there is interest in the = work, >>=20 >>>>>>> but where to do the work is not clear. >>=20 >>>>>>>=20 >>=20 >>>>>>> My advice to the authors: continue progress this work and if = CCAMP >>=20 >>>>>>> is not interested or consider this work too generic, bring it = back >>=20 >>>>>>> to NETMOD and we'll follow normal WG process. >>=20 >>>>>>>=20 >>=20 >>>>>>> Regards, Benoit >>=20 >>>>>>>> All, >>=20 >>>>>>>>=20 >>=20 >>>>>>>> I heard from Kent that >>=20 >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__tools.ietf.org_html_draft-2Dvallin-2Dnetmod-2Dalarm- >> 2Dmodule&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D- >> ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=3Dirspa6NcXPKDS42mjv_ >> C- >> 7NNeuoTFH_7mVAhII6sVtw&s=3DsyCS3yBqAnMEHVe_skwu6LG9DP5FZk64CJVBr >> unZhxY&e=3D was >>=20 >>>>>>>> moving to CCAMP but I don=E2=80=99t see any mention of it at >>=20 >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__datatracker.ietf.org_wg_ccamp_documents&d=3DDwIGaQ&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3D- >> ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=3Dirspa6NcXPKDS42mjv_ >> C- >> 7NNeuoTFH_7mVAhII6sVtw&s=3Dm6NrWOmFg_T_v__mD3Fa5rqq34YuMRToX9 >> WzQvNVnD4&e=3D (although it is >>=20 >>>>>>>> shown as a dependency at >>=20 >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__datatracker.ietf.org_wg_ccamp_deps_svg&d=3DDwIGaQ&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3D- >> ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=3Dirspa6NcXPKDS42mjv_ >> C- >> 7NNeuoTFH_7mVAhII6sVtw&s=3DSRIGQ5LxUE5aWtjNsXkGdNtbL7YnVenK61Qusl >> 9BEFE&e=3D ). Is any more info available please? >>=20 >>>>>>>>=20 >>=20 >>>>>>>> Thanks, >>=20 >>>>>>>> William >>=20 >>>>>> _______________________________________________ >>=20 >>>>>> netmod mailing list >>=20 >>>>>> netmod@ietf.org >>=20 >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3D- >> ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=3Dirspa6NcXPKDS42mjv_ >> C-7NNeuoTFH_7mVAhII6sVtw&s=3DzIJIO1iLPbjtdTsUknTS6d7pmny-Ov- >> v1Is3WoAyuhM&e=3D >>=20 >>>>> _______________________________________________ >>=20 >>>>> netmod mailing list >>=20 >>>>> netmod@ietf.org >>=20 >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3D- >> ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=3Dirspa6NcXPKDS42mjv_ >> C-7NNeuoTFH_7mVAhII6sVtw&s=3DzIJIO1iLPbjtdTsUknTS6d7pmny-Ov- >> v1Is3WoAyuhM&e=3D >>=20 >>>>=20 >>=20 >>>=20 >>=20 >>> _______________________________________________ >>=20 >>> netmod mailing list >>=20 >>> netmod@ietf.org >>=20 >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3D- >> ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=3Dirspa6NcXPKDS42mjv_ >> C-7NNeuoTFH_7mVAhII6sVtw&s=3DzIJIO1iLPbjtdTsUknTS6d7pmny-Ov- >> v1Is3WoAyuhM&e=3D >>=20 >>=20 >>=20 >>=20 >=20 From nobody Tue Jun 27 07:35:50 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98379129B4B for ; Tue, 27 Jun 2017 07:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 NkelF81OB8UO for ; Tue, 27 Jun 2017 07:35:47 -0700 (PDT) Received: from gproxy6.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 577AD129B49 for ; Tue, 27 Jun 2017 07:35:47 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 81F851E0933 for ; Tue, 27 Jun 2017 08:35:45 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id dqbh1v00R2SSUrH01qbkYb; Tue, 27 Jun 2017 08:35:45 -0600 X-Authority-Analysis: v=2.2 cv=QYgWhoTv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=NEAV23lmAAAA:8 a=vlV76lHBhhWnInc5iiwA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Zh3OEeqRBh9mAfc466KtAvVBM5NoO+I4p5rhOZ+FG2Q=; b=nO3bRRAWBrMZKeWIcfox8XHeZs EDjraXLkuXeoy91+CL1ZedClWsHjqOYLiboBYAJfjPC9sn8yAG8FvX9Lm12SrxwJPz2CwuV2fafhs snrPBvmJmk9LfK0fO1GVD/mwV; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:33182 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dPraf-000UB9-2H; Tue, 27 Jun 2017 08:35:41 -0600 To: NetMod WG , draft-ietf-netmod-schema-mount@ietf.org From: Lou Berger Message-ID: <81ef5d46-88a2-2c5e-22d6-b3b2e53fc50d@labn.net> Date: Tue, 27 Jun 2017 10:35:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dPraf-000UB9-2H X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:33182 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [netmod] schema mount missing module-set-id X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 14:35:49 -0000 (as contributor) In reviewing schema mount in the hopes of having it ready for LC (as contributor) by Prague, I noticed that the "schema" list replicates the information contained YANG library with the exception of omitting the module-set-id leaf. Presuming that this leaf is in fact useful (although I know in other settings we leave it to the client/receiver to generate such hashes) I propose that we add a parallel module-set-id leaf to schema-mount's schema list. The specific addition would be: leaf module-set-id { type string; mandatory true; description "Contains a server-specific identifier representing the current set of modules and submodules identified in 'module-list'. The server MUST change the value of this leaf when the information represented by 'module-list' changes."; } and the parallel notification: /* * Notifications */ notification yang-schema-mount-change { description "Generated when the set of modules and submodules supported for a particular mount point schema has changed."; leaf module-set-id { type leafref { path "/yangmnt:schema-mounts/schema/yangmnt:module-set-id"; } mandatory true; description "Contains the module-set-id value representing the set of modules and submodules supported for the identified schema the time the notification is generated."; } } Does anyone object to this or have other thoughts on this addition (e.g., agree that it's a good idea to keep this model parallel with YANG library)? Thanks, Lou PS for full details on the proposed change see https://github.com/netmod-wg/schema-mount/pull/11 From nobody Tue Jun 27 23:26:33 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9352B129B44 for ; Tue, 27 Jun 2017 23:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.784 X-Spam-Level: X-Spam-Status: No, score=-3.784 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_RATIO_02=0.437, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lzo0EID8r88o for ; Tue, 27 Jun 2017 23:26:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824B4129572 for ; Tue, 27 Jun 2017 23:26:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPY60562; Wed, 28 Jun 2017 06:26:25 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 28 Jun 2017 07:25:32 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 28 Jun 2017 14:25:21 +0800 From: "Zhengguangying (Walker)" To: "cwildes@cisco.com" , "kirankoushik.agraharasreenivasa@verizonwireless.com" CC: "netmod@ietf.org" , "Zhangjun (Echo, CSD)" Thread-Topic: Some questions about "draft-ietf-netmod-syslog-model-13" Thread-Index: AdLv1JZSQaF8X4AWRYG7oeU4gagUqQ== Date: Wed, 28 Jun 2017 06:25:21 +0000 Message-ID: <381D7D55085B1E4D8B581BD652E1E140C91655C0@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.134.169.155] Content-Type: multipart/related; boundary="_005_381D7D55085B1E4D8B581BD652E1E140C91655C0nkgeml513mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.59534C12.00C3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4c7896c98e4ecbdcadb7a9c117e0690d Archived-At: Subject: [netmod] Some questions about "draft-ietf-netmod-syslog-model-13" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 06:26:32 -0000 --_005_381D7D55085B1E4D8B581BD652E1E140C91655C0nkgeml513mbxchi_ Content-Type: multipart/alternative; boundary="_000_381D7D55085B1E4D8B581BD652E1E140C91655C0nkgeml513mbxchi_" --_000_381D7D55085B1E4D8B581BD652E1E140C91655C0nkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have read the "draft-ietf-netmod-syslog-model-13", we have some comments= want to discuss with you all, https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-13 1. Because the destination may be in VRF, in the definition of list de= stination, there should add the vrf attribute 2. Whether "DNS " should be one case of transport? 3. The tls case should be concerned Please help to confirm these comments, thanks Regards Zhangjun, Walker [cid:image002.png@01D2EFFF.37F02670] [cid:image003.png@01D2EFFF.37F02670] --_000_381D7D55085B1E4D8B581BD652E1E140C91655C0nkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all<= /span>,

 

 

I = have read the “draft-ietf-netmod-syslog-model-13”,  we have some comments want to discuss with you all,

 

https://tools.ietf.org/html/draf= t-ietf-netmod-syslog-model-13

&n= bsp;

1.      Because the destination may be in VRF, in the definition of list destinati= on, there should add the vrf attribute

2.      Whether “DNS “ should be one case of transport?

3.      The tls case should be concerned

&n= bsp;

Please = help to confirm these comments, thanks

&n= bsp;

Regards=

Zhangju= n, Walker

&n= bsp;

--_000_381D7D55085B1E4D8B581BD652E1E140C91655C0nkgeml513mbxchi_-- --_005_381D7D55085B1E4D8B581BD652E1E140C91655C0nkgeml513mbxchi_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=9895; creation-date="Wed, 28 Jun 2017 03:21:03 GMT"; modification-date="Wed, 28 Jun 2017 03:21:03 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAb0AAAE0CAIAAAA383oDAAAAAXNSR0IArs4c6QAAJmFJREFUeF7t nQmW5SiSRSt7SVWr6l5Q1aq6t5T9IyzS0sKYTAgQ6F8/ceK4y8GGC3qfQcj/+PPPP//BFwQgAAEI hAn8V7gkBYcR+OPn1zBzGIIABNYSeF43v1NBGOav7ed4g8BIAlN085IUHqcgl7Ib2VbYggAE9iAw RTf3SI0oIAABCEwh8EdpuGdHVVpGL8oV+fHzvftGI7XGXV2tLhay1tROqa51ncWTRijFrEE3fqzE XCqZhldvq0/540bZU3ofRiFwJoH8DWxvbP2+dNEKnyqg04VsXZUwp8vOSKmuamJTpDTCrEcRX/e/ aKsNLPt9pVgpKkTzzDuFqCHwN4H2PL05MmoWsMLaXBzMWpMN6LRuxLUTTZXOrMG+rlEKL2tNx8h9 vqgFAQg8TqCtm6NClHFWUOmcU6nYXT1NYazBsdZGAccOBCAwiUBbN5sjxEhkoyanQ4KxAY81ONZa BCxlIACB9QTa+0KRfRK3sSOrfm6CnG6qlFSmZM0atHUrY9hSMbuTo6HqKqddWJAmSZdrs8EER9Oj PkXWdxc8QgACP/QteKsDayCB4I7WQI+YggAEBhJANwfCxBQEIPAVBNrrm1+BgSQhAAEIhAmgm2FU FIQABCDwkwC6SUeAAAQgcI0AunmNF6UhAAEIjNHN9Imi+BGaeEla6w4Bni29Q4+6ELAExuhm9jR6 5AmnO4eIThSCBTHXn4ql90MAAvcJjNHNUhwR6ZS68ZL3c8YCBCAAgTsE7j6/aQ/efOJIDwWVgiuV dAaletOLfZI8+7171DzrxYVqzxFZZU/PGmnFyNkq9zkRiSQLwdFOXxdiX+CUfjhlkaqR7ATiTj+j LgTeROCubuot7SQjqyCpvrgTh/ZH/T57UVSj5NRVcePZksG0XdODPWlduWL/d7FV3GWtuTD01KnV QfWY8ndY1FoTo/u8YQbwpvucXMYSmDtP12GOfWNQ/Yb83L3y5UTWXbxEIfWYeikZvFM3EqSLxIFS 76qelkx2nBtxGk/2jjXqQuCtBFbo5iV22XeyyVhp4Ago6yUY5526qYu4teEQgvlSDAIQcAS20007 r0wnocPbLzt8C3q5U7e0JlByXZp9K6JgzBSDAATuE7i7vum0w+1ONKfk6UxTDVZWSN2OR7oBImYr wWS9OJrpWoETKbuLouub4vfzf8mFWzONRJIVR5ud41xyoVjS8FwYqYWBg/37vRYLEHiWwF3dfDZ6 vK8hUB/trokBLxDYhwC6uU9bEAkEIHAGgX3XN8/gR5QQgMD3EUA3v6/NyRgCELhHAN28x4/aEIDA 9xFAN7+vzckYAhC4R2CYbt45zxNJ4c7DknfqRmKjDAQg8FUEhunm7Of7IvZL+hip+1WtTrIQgMAd AsN0804Q1IUABCBwEIEBz29m38EhCEpnfrInfNzxG62enqipH1KyfuuHdqSkno1xh2QOakVChQAE VhK4q5v2JImeNbSyqIcO4xed4AoOd2Ql9ZuWUY7NulYxORuzsv/hCwInEpgyT5c9IjcO1SvZ1UZ7 8ZHlyEecnthjiBkCEJiim9l3o8lFtrbpcxCAwOkEpuimnSDrLFu+KUknenp6TyJ+CHwPgbvrm7Kq aHll32+W7h2leupMVd4OVyqp1+t1bfU0WnaHvqf3kykE+ggM0M0+xzdrsXtzEyDVIQCBbgJz5+nd YdUrypCQqf0kvJiFAAQaEsQ+Ml0EAhCAwCUCR443L2VIYQhAAAJjCaCbY3liDQIQeD+BdbrJouT7 exMZQuA7CCzaT0+PYJY2dkrrrZtvoC8Lb/ZjUu4A66eZpq6Az06neRfr7qJ7l8LUrEtRLetFTSz7 F8g23LKw1403sylJ77T/lzJ/qh8HW2JZeLMdzT7wmj7tGyQ8o5joVIp0NuTSoyCz/c5g6Gyuecql 1HALEhQXi3Qzq4yzb9FlEHF0OoEXCNbpTdAX/1MNt2ieXoHiJoZ6gCc98+MYlc4gVT4AszZ1qmjn jJVhkZsgpPOFrEGJKls3TTmLK823NMfU6tlzU9ZdNmU3Y61Ya5a0iZSQ6hqOzjyyrEpdKNsNLJlL 7RtBmkITDnVHtsxVpBX7KZZ4170Zs+vPA/26nhDsRVLM9fngzXVVtbfTTc3crfVUfqysCqWiLI1t 4Tqy2SqKtfTbNLw0kVIwlV5S8RtMLZuvvWHSjxmnhikrd6XkoqT+2c8/lQb3jTNeiVaB3Glflex4 js6du3VTO5WMmr3LSXZptBXvG2lPqNTVT7hKG6U3YyWpCKtILwq6uCqOlfKL5unxiIMDbxE7242a LuqW436lq7lP19R71qBUdHWDrlMXqbUmFutrpd9668RZVewMad9mL2oWSAlHekvTrBbobjUVu7Tr dsec7c+RjiplnN+rd3QEWjeuuvHtdDPCQqHrUDFe635J+XDraw+p2F3dBZ+1Jhebsn6Hwxq/Y1l1 56sfRX0tfqe3dMdcqhgMJlhMhC/Sny8Vm9p1RyE9VTcVblwjhrRHOg3pa4khwahrtdbE8pTfPkpS KxhzsNjVSOIikh1n9ant1SAj5YNdN1jMeQzCrxRrdt1IjsvKPLy+mYWlEwr5QMvOau3Fete0LlKh sfadX3vTWhf1LlI36IKJZ5HKR+rIlcnGbHPUYXtWniIl1UVHIs5+Cj/bcFltcolYDpXmyMacdrZS asGS2d6rEWYBSrd3WZR+zHb+sTErXpFUMZ6NsHnLVDpMvAvVG66vT14V3Id182q4lIfAYgJ2/NU3 FlscsCjsPuPc9ekv8AjfBZBxcTaB4Mh3kyTPinYTaFfDQDevEqM8BCDw7QRO3Rf69nYjfwhA4DkC 6OZz7PEMAQicSQDdPLPdiBoCEBhEQFaEg49Sic/n1zcfXMa2T1QIuB12IR8EMqgfYuYygXc0evOZ v8tc5lfQh6su3fsPjzcl6EsRDyTp/D4VhsvoQSAD2d43denz/767ioUFkbyj0bNZ3ExtAfyOzvOw bmrEm2hWB0GqQAAC5xIQ5bmqP4/NTOvnKGwmOpvOfmMPMKTThLTKr+WJnysa8lU5eONOR2TrlnqM O9VgY8t+7xovXTQoZadZZCOJc/5Ur5/E0Ajr07G07bJXKp31Usxp1tlGdzGXXFgItmOkkCMz62b3 c7era/RSzKVDUPWe4FKznTnbzx3Yet+wiWTXuzr6c7CNNK80i2zMcYnPJvKL21WhjXuNlEw7ij0m 5Y5MpW0j1e3/2huadbMlnQurFPIrDbjC1BYrVanH7CxkDQYj0bpNVjajrPFKzJXylnPWReWDp3Q3 1uHbG6nSylkgTQjNbpOVm2AiJT51vEGqFeOVz7AmwCCQ5p3ezF3BltrIZRHEEpGptMwu8/Rm9E19 V11zH1PNPlFx3XRaqitqLpGoEf081BbNFmuiGFJAwrOsKjHbRCqc08Ccl5X5pkM5l+9NjCnASmdI xbQZTJZz2oWkg6Wd7VJ2l/r5pcKVMCoA+1y4WvexVII/Rjcj/UD0qA96xL7to00vEkkq4s5RsFga nnaLZiTZ1MSvw5UNJr2Yci4Fk3rpzjfYQBXxSvO9YzMLMGgwWDfen5+iGsw33gPvGMzeI5F7sMPp qbopOPT/T+ZuItDBIlIl2JVVLl2z2YAlZnHa0brBSJpJaQzZYNKLWc7NYMTOnXybiQQLND/Jgna0 2B2Dlbql/uy60Hqqd/LNsk0NDnFR6s9jjPeNVq72rSYvDcNmK7VsnjZap5uuZCpGrm4lBatiUkti SEWwZKQUs9P3bDHXriUyFRc2Khu5xp8mWOIcjLDSRvrBUGnKOsZK3+juVyUsToacOGa7UOUOCmLJ dt3SRdeFLlGN31wp2LRuyirbdYP9uUTe3n3pZ5W9PW1Pq/fnoOiVPrp+GA+aqKjMV/3KoqxgrQjB KOA3IxnbalsFMza13ax19LrdUjglHnRzZEtlP3ibDvpq1c3OsNlMpD42/Px21AdDdyRvrbhVc78V cjAvxptBUBSDAAQg8IvAqftCNCAEIACBpwhsP978z7+eQjPd73//73QXOIAABCYQYLw5Aeogk5/1 rCHPTAwKBzMQgMCgebrc2+ntPeOG/+N//u/zb1TTDTT1CWmsNc2RPZZRzY0dCAwkcHe8KQcV0oCC N/wlef3z3//syLykaH3WShLZba0jI6pAAALPErirm89Gj3cIQAAC6wmM2Rdyjz1LGm7I6c5OlE4R eAQ/94XsmFFHdnoxvfLD+7//6UaapYpSTMvbkaNzkTWYhiEpZOv+5qW1L8QTzuvvBzxCIEJgvG7+ Uo3f/+ZE6TxJWxr+86+PAFnJk+/Ti9lirqQl4sqLdNrylwzawtnwVEn/9pJb39AI22QizUsZCEBg AoFF83Q5EC1jzODSZzNZ2Saywzr9sWO1Ma2iAjdwzyceWMebPprEKAABCAwhsEg3RS7HasFHg/Sf sJAfB8qcjCLjYjekSTACAQhsTmCRbtqjtZf20CP4RCjdwDNSsV7GTb3vG8QCBCDwDgJ31zfT7Z3s ho/bFLLsGpP3ZF9IxpVOKO2PWkC96M6PXKk/mWQL13eWXBg65nVeKtHWlyxY4nzHPUYW7yNwVzen E/nic5Zjl4OntxQOIPA1BBbN07+G58hES2cKRvrAFgQgcJ3A9uPN6ylRAwIQgMBUAhvrpvkT51MR fHb659rHOgQg8C4Cj+pmXRmXydkmYbyrY5ENBF5MYJVuZrXpnjLKdvPUTecfxrONfy/yF/cnUoPA NxCYqZtGKz/nhEYdE5JWWSSaJV22HwNo6DfcKOQIAUNgwn76R1Pk30dQ9N/LoNvUNN+X5Ug6EIBA gcDQ8aaMwnLjr6mz6V0at5z+LhESBwQgMILAON2UAWZJnv9ai5Tf65w9e/7SHmMPzu71EfH0WXHr Qib4NsZsJE2wtY+BKoemZQpAAAL7E5gwTy8nLSJlpUoe7bbbO7ZMUDTVpsiZlV29ohedfZHRtFi9 5eKB7d8DiBACELhKYJxufjRRVvrKX+kwTV4ul446++b1qZzJFeuiMiKOFKvx1VXdq41AeQhA4CgC 43Tz56jvx7/CPombIAslHW/OG8HpWLI5hNRgrrWg2we7VpnSEIDAeQSG6uZfWugF9K/XFVfev+mG nKNktGPcmtV337CqlfaxgfNan4ghAIEeAuP2herT8+xvfz4dqQNPLXJH7HRiLoNZmaSnznVF1W0o aa2/q+SqD38ctafpqAMBCDxEYIVuFlPb5IDj9TA6lP2h9sUtBCAwnsCjuvl7On7syXs9xjc3FiEA gQEENtLNAdlgAgIQgMB8AhP2heYHjQcIQAACDxJANx+Ej2sIQOBIAujmkc1G0BCAwIMEVuvm3TM5 LVShpy8LRu7UbcXF7yEAgfcQWK2box5oL7VA0H7poc73NCyZQAAC0wis1s1piWAYAhCAwCIC655D skO8ytvb6sU+VNyJoMqBHzeozB4fchfdcNU9Uup8Bce2i1oSNxCAwCoCi3TTHrDR79OLwWICR1XM snInebIGpW6qepG61imnhlb1UvxAYC8CD8/TZZvIDuv0x+xozl18ZMT3iNO9eg3RQOC7CTysm+l7 5NyLh7+7dcgeAhDYkcDDuqlIZMjpBp4pMB4V2rETERMEvozAovVNq4lCOLshk90UcnpqFzezpkoX s3s+lc2i1G9pm+jL+gzpQuDbCazTzUdIs3XzCHacQuDdBHaZp8+g7Ob+M1xgEwIQ+EICLx9vfmGL kjIEIDCbwJvHm7PZYR8CEPhOAujmd7Y7WUMAAv0EttNNFiX7G5OaEIDAEgJ7rW/K9nd63tGi0D8m nD2307eB7h4wsu76DNbbLntCdGBzu9OlH8s7n3HKwq+0SDeoGU2ZBjMj8u6UmxVnRLuGczO1qQW2 G29ms5XbXm/+igr0CYQcUqq4juhgvJ36guyzP9tXPKpSySz8SotEPGbPRyxAIZKxwJGD0H0eZEa0 69OPdImxZfbSTaePkqpthm9okrENjLVHCNBRH8G+zOle8/RK2unk3U3YSzOO0hmk7AzLdveIQWek ebekwdRnqfZjw9XVyb6d9XdYy6Zcn9rHJ3fBfD/uspO70opNJWY38pKSzaa0xVy/KvVJZzPrN1s3 23AuyIq1oN94G6XwO3qRdJi0YilZm2+9sy2TwkuODtZNxW3vrqy8CpHmskvw1tWbVss3LacBSJVs 5JcuZvtcE0LcRf3TpZ546iXYUuq0VD5LvmI82wFKELL9ynFoBla/CVVNKpnaHnI13yaKq+nUA6j0 N9VH/WQqfXNJth4vvNc8/RKO5uBOPwPTbnrJkS0sYjfQoFgTg/LVdDFk4aLDr4YnN4ONuckz0lhN I2nMrmmaFiIFhoTadJR6qWfXNJhK4dU2uuoiXn4N0ng890serJvB5GXl+9JNXrc81qBYky8rnWNj TjO641fGF+tvhmzMwW6wf7Gx2Q23Jirseml6MchZBwfre1Ewwnqxl+umyuUoGRpuUJtHLTddDPwM kJGjxND0q8U6+vqkmG3nHutiyN3VZ2RsIkOsZT8p73x83qnbR3VsrTPWN+0t7e5w+6NFI/e2m/+W 2Lm+ldb9VKwbFAtNQUkdudQqMZcgWL/NRDTCuN8UWtZLlm3FSxqJWIjAt5xTF/ZjoGKt0pFsrVKb dgMs9cn0c0s+7PUj3+XiAnM9sITFNVO9w2TbqHKx2b01yOCNOVbsBlo7QzcHJowpCEDgKgGRbzfh yF4MWr5TN+hiajF0cypejEPgJQSyA9jgqDY4FzmIFLp5UGMRKgQgsAWBl+8LbcGYICAAgXcR2H+8 +feDje8i/2ML5HUZkRAEvoIA481jmlnWkoY8VnJMzgQKgS0JnKSbH90wx2ru4hxo6qec3Y2nXl+f R2k+6jQ3DqxDAAL/+MdJull401ujGUuK1metJJHd1uiEEIDAcQRO0s3j4A4MWIaZDDYHIsUUBLoJ nLEvZMeMOrLTi+mVnxLj586limJHy9uRo3Phhq5SMg1DGiNb93cvF040lRrYPj/c3QmoCAEIXCJw gG5+BMhKnqqVu5gtJvqVnUS78iKdtvwlg85LKebfveTfI3ep/SgMAQisJ3DwPF22ieywTn/sWG1M q6iMDtzzcV70rTDMwdd3fTxCoJvAwbr50SD9J/nLjwNlToaNHSocbw953xdPF8WJURICjxM4WDeV nQilG3jeJ1ua4N+3bCL/9fiSlc6PhiKjAyFjCgLDCRywvmk1UceVTihdGTdC1J0fqV5/MskWzm4E qQW3L2Rjq4SXrfVzsPz3+2bsj/UmZ19o+C2BQQg0CZyhm800ziww4Jwlunlm0xP12QTeME8/uwXu Rc8Tnff4URsCPQT2H2/2ZEUdCEAAAvMIMN6cxxbLEIDAOwmgm+9sV7KCAATmEUA3O9nytFAnOKpB 4HwCi9Y37/wdEoF838LYxmIjeyxPrEHgIAKLxptyKqabi4jUHQvdrqkIAQhAwBFYpJujuCOdo0hi BwIQ6CawaJ6uc20nfOns211J/5J9NlX39+ytl6DBq+sAzNO7+xwVIXA6gSd1M/3b86W/Rh8RKZVO WQwV6cwatH9zIv37E0FfjHxP7/rED4FuAg/P02VXOh0S9r3YItUyVc+mQRdJHShvMOrucFSEwAsI PKybsttj93yGbwEFDaaRvKB1SQECEJhB4GHd1JRkPBiZI1+i0GGwOTK9FACFIQCB9xFYtL5Z2t5J d2PSkvZKaVUxu/mjk/S02WSirdNtO+8OLlx2KPL7eg8ZQeA7CSzSzffBtdtQ78uOjCAAgQoBdJPu AQEIQOAagV3WN69FTWkIQAACzxFAN59jj2cIQOBMAujmme1G1BCAwHME0M3n2OMZAhA4kwC62dNu POPZQ406EHgLge108ylJuuQ3+IznWzoJeUAAAr8R2E43aR8IQAACmxPY6PnN7JkiexCoNCTU0V96 +qhEvzK6dNbsmaKPtdLBpPQx+NIxJw4abX5LEB4EmgQ20k2JNZUVe0W/Ty9mi2XzbxrUWqVDQc7C p7x7bV02zmZjUAACEDiCwAHzdB3xNUdqnwLyVUcvBkua6OpGljIjZY7oDQQJAQhECBygm5E0pEz8 XXBSsqmwcdep2oo0I6ndDKkIgW0JnKGb+vqiIMe6INo1yknSKYqJaAbbi2IQOIvAjgOi7Azajd2s 3l3dF8rWlaVVXanUH3UkK9+UdNa+s86NZJ16Mgg96w4hWgikBHbUzUyUyYR3c/VxG0dWOjePnJsE AhBoEthdN+2cWpPJXmymurjAEUEuZoI7CLyDwO66+Q7KZAEBCLyJwBn7Qm8iTi4QgMDpBNDN01uQ +CEAgdUE0M3VxPEHAQicTmBT3Ywc+7mJ/s6Tm3fq3gyb6hCAwOMENtXNBU+MR1zUn9Z8vPEIAAIQ eITAprr5CAucQgACEIgQ2O45pPhBoLRk6UrkXXAKy578cRc/P0aeJ9VzR8FXh0TaiTIQgMA+BPbS zewxm+DF0hGdknhVytuDm9npfLOudcoBoX26O5FAYAiBM+bpsk3khpN6JZU2dyWylDmEpjXyiNPh WWAQAhBICZyhm9kXxM1+FxzdBQIQgECWwBm6qaHrkNOuM6a73jwnRHeHAATmEdhrfdNuvEjObpcm fWWclrF1g8XURXYzSn7rlkedImfDc3tH7A7N675YhsAjBLbTzWco8GL2R7jjFAJnEjhsnj4DsowH mdrPYItNCLySAOPNVzYrSUEAAhMJMN6cCBfTEIDAKwmgm69sVpKCAAQmEjhYN1mXnNgvMA2BPQjs eZufqptyeDE9wjh1e8edWbL9aqrfPTrwb1GkJ7gGBlnhPNCLmup2922NPgN+3WbpNl8fifN4qm4+ Aq5ydDL91YtvKunNAw+SZp+KXdbE3YlEKsa7QbzkMjJNR8GYg8Wa7vYpcKpuSpfN/mny9zXSPt3F RRIRjm2DJ7D9CWRv8x3CftVzSG5Urwd1Iid23CGfT9tkq6cni0oVtXXd4aX6S+2yfq2L1J2db8pn SZpv1oJUtNpXMS6FKwPDIEDX6UsGtSlthM3wHApHo4LFliw1XD2StLfEB9EVCGkbZVWj2S0rnTnt MFnOzkUwu0sd5pIgSg+5VGVg4Sd9D0xD72q36GlvlQpo+yv3faos2bfMpcaz7tyte99vVob09Kf7 RoRPEdnv9VeWZKmB6snWAZZu+3TqoORdnC7U1GBKNdsNsvCzdbMtnobR9FLv8I5qqW8E801jLoUX 4VzpqBHxineY4ZowyeCp8/TKLe1+FWlX1Rf38ehEc0gb2HjifnVQ0PyYTfOteEll92M/hXAn8Qj/ rP20osQWCS8t2R3GpdzXeKmEVA8g+9urnB/P8VKLTCr8Ht0UQZGvyK2VSobUnQS6Pnab7Vfh1LNT gLPj6YMcDy9esi+Sd9eCXrN936ObzVQrBZqDuDvGR/mVz4MOReuo1fHBMwlR1mw8vHjJlfHP8zU2 36y1sS4URXAmMQ/dJcs99+ElB2sKa1tmB5s6Ua3Mu11vcHZUrWwxa1bTtLomhSt1P78N+hX7dQW0 ENRyNkiJSqzZIJ2FpmalyTbzrYy7tW4pkUh4Ckq+se2YdoMg/NRvpWLJS+QDr9RhmnUrEboOUOm0 6j3LuQTfxRxp37SNXHeNiEbHaCBiNljmJboZzPboYs92lKPRxYMHcpzVsyWfbSl089nWD3mPj7NC 5ihUIABnukaQALoZBEUxCEAAAr8IsC9EV4AABCBwjQC6eY0XpSEAAQgs0s2zHjKgW0AAAhCoEFik m80HKWgkCEAAAqcQWKSbp+AgTghAAAJNAuhmExEFIAABCPxGAN2kQ0AAAhC4RmCdbva9buNaNpSG AAQgMJ/AOt189lzUfJJ4gAAEvoXAOt38FqLkCQEIvJ0Auvn2FiY/CEBgNAF0czRR7EEAAm8nsEg3 J73r9O2tQ34QgMCOBHgf0o6tQkwQgMDOBBaNN3dGQGwQgAAELhHYabz5869KXPha/jfULsRGUQhA 4L0EHtLNrERe1cEhRt7btGQGAQhMIrBKN53GXZXIePbLHMVDmlwy+IexJkeBeQh8EYH5uilClgjl 1bu987hRwfubWriTzJsQkAsE1hKYti/0ESz591HM3Ojy6hs5r5b/hVG8azB/wd38uajNw1vbRfEG ge0ITNBNK5fz5uOXSIp6qoBeqkthCEAAAr8TGD1PlwFm7suOoWTwKBNMN2FP/xZr/Q/eiys1aH8s hfHxrTv3tmIzGA21FLNE4kaLdqTsckkNVuqWui7zdG5qCCwmMFQ3q6Kp8qH3uVUf1dC0mBBx6mB/ bNb1TH86dhP/dL01dSFhWJkWlcymFr+oBjXOuBTGSy7uWLiDwIsJTJint2hZwepctfzdhVWoj460 FwcLXt1lHYrWx4AinanstjD8/fs7EHiraZwzJSEwisADujkq9NTOR0T0a4gXGc01dU3KtPV6SEwY gQAEnibwgG4O15fUYMNFLILgFFiNIZ1Pd2b8Q2ARgaHrmz/X/5r7QnYrxq4VyvdWhoRBaZpcKdkY If4M0q1UKu/sNo5rDZdCWtfGnDWYWnAxxyf+QX1f1KFwA4EvIDBaN0U6f0rgjvRWxbZSy+IKu2OL EBMEDiQwQTf/GiX+orGDgOrhyyXBpAPhAzsGIUMAAkUC03RTPa4a4uVTfNY7HQ8CEHgjgfm66Yaf 8uO8cd/3vdfjjd2SnCCwNYFVuukgDHkF3BAjW7cOwUEAAjsSeEg3syh4b/GOPYSYIAABT2An3RzU OuwvDwKJGQhAIE/ggefeZzdF83jPJ4DYk++3Il3g4lZ8VIYABHoJvFA3e1FQDwIQgECIwEbz9Mrr M9wTkToTd1Py7CmdbF1lY98JIhfdFT3C5M4yVR7SrB9wcscx7cGhSjAS28rH6UPdh0IQ+EoCG+mm 6oKog2qEFQt7UTXOlbf6kq2bClClmFVSV7GuYtnfpkJvtVI1NL34lZ2TpCGwKYED5umqJpUBaYlu qW68NdxqqY4Wu4d+weXXj31WSOPNREkIrCRwgG7qKC+iOCk7Ebi+uitbwvqSgI8L+ylc+IXAYgIH 6Gb3yG7SgqBdQ5jdWgw5ZxPGPgQ6CGy0vml3e+xujMhfNje3qZKdyDd3acRyus+T3WXSwpEB7KVt K7FsM9IfNfc7HyEdnYMqEIBAlsBGunlKCz0oXg+6PqV1iBMCCwigmxcgV549umCFohCAwOEE0M3D G5DwIQCB5QQO2BdazgSHEIAABGoE0E36BwQgAIFrBNDNa7woDQEIQGBT3VxwWubOo5F36tLnIACB 0wlsqpuRpyNvoo+4qD83ejMAqkMAAocS2FQ3D6VJ2BCAwDcQ2O45pOwpneyDk2nJ0pXS6SN3OEfa u3Lx89t6JNnzS5GB7Td0NXKEwGsI7KWb9jyMfh+8mC2mSpeKV6V88zVuzbr2hCWHfF5zt5AIBITA GfN02SZyw0m9kmpi+vK39e3NMHM9czxCYA2BM3Qz+141ucjW9pqOghcIQEAJnKGbGq6qpF1nTKUT MaWLQwAC8wjstb5pN14k59J71YLbR/Vi6iJbTH5rVyqD4bm9I2dhXltiGQIQWENgO91ck7bzwtbN I9hxCoFDCRw2T59BWcaDTO1nsMUmBF5JgPHmK5uVpCAAgYkEGG9OhItpCEDglQTQzVc2K0lBAAIT CRysm6xLTuwXmIbA7wS43SyPU3VTdsDdeUc9VqRtXNntGbIR5E4xRe61IX6to44YInE6F/LjAl/L vFyFcFz5gT0tvd2OozE24FN1M0tBHvbUA471k45DzkF2GOmoUm/y4QZTd0Gk3V3T3eH3MxooGd1J VSoODy9r8D7GGbm/w+apuukk0sql+/4d7UQWEHiQQHq7PRjMDq7f9hySe4Jd5xdWTN15Hp2BanvU P6jd4aKsC5lsikH7diV3xRZrlky7S/00lM0iLVm6Un/nXingbL6VwppLaaQZbziHJWtQLrrU0pib xayRbG9xjZ4avDSyzlpzfiv5pgOIZngdkuTuuA4LJ1Z5v25q78lKqopm891xpZJ6b8h9qAdDSwZt GNnvSwVSgUhdBA1WYkhvNptX6fug39Idkt57KdUglrSZ9IpLrRSz6zDx1JoG7adFcxId9+sapeSl Gd53KmCfap86T49n2+ygOoiw92rE/thVPzc8/ATjhhKRkOQWcnVlnFXKzvGJ4MpGctVvM500ktRF 04gtkM005ZwWq9CLBNCNNGL8fpnNw7uf4AwL79fNILVP79F5XLDKvGISjHxd9ZKtuyC7BX7vYClp fQTyAnpXW5nyzxJAN3/w15HdJensGw+W2jtr7Y4LrVvP7o6LkhjJ9T6qkfthSMzBaem8LCKZri/T PdFZH+qDHl+1vmm7uLtv9cdUGd2V5hAveyNJLTsXdsHYeKS9bRX9MVWcSudw8lEyaItpdvXw0mIa c9ZaStvlG6SaTUGppjE34TiDJc7OTlrLNlkltVIPdH5dV2l+lGabwyHN9r1S2BXOrkpTm4IfP007 ZxV4lW6ehZ5ozyXwlFg85bf++dT8UDy3oYsfaV+Y8/takYxWErg07B0Y2FN+B6bwGlOMN1/TlCQC AQgsIsC+0CLQuIEABF5DAN18TVOSCAQgsIgAujkMNA9wDEOJIQjsTQDdHNk+bLKNpIktCOxK4Et1 c8iD07u2KXFBAAJzCXypbs6FinUIQODVBLZ7Dil4uOXTKGnJyANu2TM2qbVSsUpn2PCZ5Fd3XZKD wGME9tJNKz36ffBitliJq9O4oAtE87F+imMI7ERg33m67rHoWVo3wNT9a3t69/6mdt/ezqUXguzU AYgFAhC4TGBf3bSpyHjQKVr6dq/h7xm7jJMKEIDAFxDYVzd1dJldN7RLmenm+J3t8jt1v6DDkCIE IPCPvdY37f6MHV2muzTx7aPKEufnV1ffq8YSJzcNBCCwnW7u0yRX98dFyvuWR/fJmkggAIEmAXQz jyjySFMTLgUgAIFXEkA3X9msJAUBCEwksO++0MSkMQ0BCEDgBgF08wY8qkIAAl9JAN38ymYnaQhA 4AYBdPMGPKpCAAJfSQDd/MpmJ2kIQOAGAXTzBjyqQgACX0kA3fzKZidpCEDgBgF08wY8qkIAAl9J AN38ymYnaQhA4AaB/we/hNxpQvf9/AAAAABJRU5ErkJggg== --_005_381D7D55085B1E4D8B581BD652E1E140C91655C0nkgeml513mbxchi_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=10552; creation-date="Wed, 28 Jun 2017 03:21:03 GMT"; modification-date="Wed, 28 Jun 2017 03:21:03 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAbUAAAFpCAIAAACUNCHeAAAAAXNSR0IArs4c6QAAKPJJREFUeF7t nc2SLamtRt03PLQH95n82n4njzxu7y5O6agkIAVJ/gCroqNjVxYIaUl8G/Lv/PHnn3/+jR8IQAAC EHAE/g8mEIAABCCQJYA+UhgQgAAE8gTQRyoDAhCAAPpIDUAAAhBoIcD6sYUWbSEAgZ0IoI87ZZtY IQCBFgLoYwst2kIAAjsRQB93yjaxQgACLQTQxxZatIUABHYigD7ulG1ihQAEWgigjy20aAsBCOxE AH3cKdvECgEItBBAH1tovbjtH18/L3YQ1yAwHwH00eZsXpXhVUzzzT88fjeBXfQxrnpXq0zck3dX Dt5BYH0Cu+jj+pkkQghAYDSBP65eLg10WK+8kttyRP/6+ZyOmzbJE4nX9PXW5Igx2NRSh29Wjpq8 Ca3SssTz02WiVA6sCkxB4DoC00wqPf/TZ39EK1r6rNXQ6FHkT1mDJbNalCsJ80JWCqTkoTeOOF43 Q7C8M4Ep99f1hVJkGSVLy8jZQG8wXSz2fSND16utz4KscHcuZWKHwHACU+rjEAppzdWtR6lvX/ch /mMEAhC4msCU+hhZ9NXBjdqQnvfE+Dnc4NUFhH0ILExgmvOPlasinz/VL9ek/Jnzg/4aSOVI9vqP jKt90wdLdePPVFYuFkUMJgdYzC48UQntEQJMqkewHw/aqnfBq0PHA9MCAhD4JoA+vrEW/HLyjV7i EwRWJ4A+rp5h4oMABHoJTHl9pjdY+kEAAhBoIIA+NsCiKQQgsBUB9HGrdBMsBCDQQGBZfcw+39IA 5qjpmRsVz/Q98ou/QwACwwgsq49X3wwYtJ+VwmDfYUnGEAQg0EVgWX3sokEnCEAAAr8JLHh/j16y 6VfgpKD9kfpBue/afCj1kuP+aZzPn0o3NprjflBqFgIQuJ/AavqoHzuRz/5gsFnKR/bRFPN8S9Zg 6pt9/c/hy9b0oK3P0txfRowIgSUJ7LK/Tpdr9DJNfs2eDTQHHzlj+MigS1Y5QUGgj8Au+iivIxPR SUe4lNxXN/SCwA4EdtFHyWUSRLOQ9JlGN3eofmKEQJ3AaucftfalyCuvPtMN9KlG6WWsGVNZ+7qv tlnpa/S69CvbbSYzBG4msKA+3kxQRBD9eoQ8g0LgOgLb7a+vQGn27FcMgU0IQOB+Aqwf72fOiBCA wBwEWD/OkSe8hAAE7ieAPt7PnBEhAIE5COyrj5w0nKNC8RICzxHY9PxjemLPPyOoEyF3j2cvTL// mb97PMw+fDmwns2Dmx/Ll94ncDIcc9ts6WH/UrOB3DA1hMC+68csvlTQ+hmbEuVLZ2lp0Ka71u/x 8OpRtP2LxtJUzw9hSuiTyiTx6SdlVtpEHuJqSvoQUWgy8nL3mmLxjTfVR1/EZmFyfp6cTAzdZyTg 1dys4qmrudK66f66kiS/6TYbbf1sorYTXIZkmxmbssszH2Q4Pc28P4fWxE6pb/3cQuoeCeSwmXwt VULOBmu+zyoQTMtSyrQn2fBLefe1ZM4JHJ6fKZ0Jqe/W62Xpefqke88jdSXjmu5LSj/6aIske1Iy 5b5S95EpUbKQ7atPhEkDP5HiLpn5XwlHD136Iin5LJMkNQg204Jrpln260ral/ISTIex493Iki/J mRYgwyGrodlvu7raGo3LjqJ9jiT9ZI4OaZRKaIrjm+6vm3IT+WJMWhBRluCsqKx6tPMiEGatUV8a 6GkmbnuzTZREXLTBQyyGbQR11qs0qEA4HLceWmnFl2XVQSl1SScfu0PWHUtl4I2fJBMsy24mb+uI Pg7LSKr1Q50aNt63ofQF3jfNZIr2dc+qsJn292DxgQwfdzirsZUQL4PhZMYG8ipr6OOYdJiVS8To ECUdtbsZ4oyOOhk8xPLUuJEEldo0+Wy+Mpv6xp2Ml8FhRuKD7tCS848/sqyrx0xv/avfiuq6r6/F zBCyLZU9V2lc2UOZPY6ZcpU1rLfgnekI5NBz3SAbr2Gr/RTU/qDmXEpccD+Yumt0EVZZgejI76HQ iHuGno6upLwmEJ/fUsbjtWHcOwxnogbo40TJwlUIjCcQX3uOH/v1Ftlfvz5FOAiBywiY0yCXjTOr YdaPs2YOvyEAgasJsH68mjD2IQCBWQmgj7NmDr8hAIGrCaCPVxMeaZ+zRSNpYgsCRwTQxyNCLX+/ 6O625EK6zsjVxpaE0BYCpwigjz346vea9VikDwQg8D4C6OP7clLwKN3oO+pBwGnCxlEIPEeA+3t+ sK88hpG0yT+sIpvf9MHol3+cS4xkH//oU0A23c/NIEZemQD6+Du7WmXk8+FBXR1Gp3xf/SRWfYiV i47YIDAJAfbXdyfKb5DTinLhh1jvRsx4EBhEAH0cBPKcGV45dY4fvSFwCQH08RKsTUb9OcpPd1lR NpmiMQQgMJAA5x9/wOx+p1Pkuk324o+55iO776btNtdnBk4JTEFACKCPB8UwhfRM4SSzDgLTEUAf aynzy8npEozDEIBANwH0sRsdHSEAgcUJcH1m8QQTHgQg0E0AfexGR0cIQGBxAujj4gkmPAhAoJvA 1ucfufzSXTd0hMAOBPZdP6Z7Yngdzg5VTowQ6COwrz4KLySyr3ToBYHlCay2v5bHTszzJ9ln+FJ2 K//M/OevWYP1J2HqLy5jU7/8pCLAZQispo9a0SRJwXeUZZt5gyVrIrWVF5eVhlimnggEAisRWHN/ 7bfM6XUP5ilpn8hSM//WW2+tvk/XD1ZHPFmpyIgFApMSWFMffTLSpZjDCzJjm2VrIjjEpPWE2xBY icAu+qj32pH8Ha40k5Fgs2zLeN+Iw7SBAASGE1jt/KMWncqFl2Azo2vm5WP6hGNKTGqgLw35qzFc nxlexBiEwEUEVtPHizBhFgIQ2JDAdvvrDXNMyBCAQB8B9LGPG70gAIH1CaCP6+eYCCEAgT4C6GMf N3pBAALrE9hXH9N1ZG6yWb/GiRACPwnE5/6m16/Tc34/n/b7j2b455///6WePw5+jvjj6UjlR4x8 WhqD0le3SaZKLSOlbkT/5hdwaKoRb3WbM32DY0Xuryrd/nU4RMT4oRFpoK2NtRz34Z0tSxVuEpdt 5ud+JcZ9148GSpKqz//Tf0mezEFRLml2WD0fO6mxtJS+WhzNuKmxdDyUYO9G0sSblfHb7b+G7vu5 2uE0N+qjSJsOZw6NN2HxDnS41DTiRI19hfvESZuUl47N4qb62CcfSTeN2FVKSjdu1bjW9toNPYuY UdkEBbEEm00kK2u46ivc7DwqiWua+5vqY6lKPoqW/vPy5PfawVJLBtWm6dcQekWZGmTH1aN8iqDj O/DL8q+OxkL6VWweNkstpVfd2vdy+3dzBcEeNJ6YvvpXHU71yykUWnbpbSBr37LEDvNSj64jp96g TkqFs05fazOT+lb4pngqngRTHJyA8WY+EejjD3qyof6pSj8ELo5bJE+fecxupVNLb/lQMYPOyIOP egP4qYb0q2w9TDMpaGmWhtPfwHrb4neXegg9G43BZNN85wfdyxLI9hW3D1eFKSiZLSZeIZCNLpdE yznNfwm57k9yRrfx0cU5V/pKXNo9nd/ueLMAvScebLC8683kmyOSd2MKfbRss1dRune7pmPWjpyj 9EMb57yINBWQqQ9RQ/O16ZuJWBxWmHfY99Xq02pQz+Gm2Fsb66+NNKj+tpDviW4yrf6Y9mb9mEVa Opjk73DR6peoJxOX/ebIetJRFRWe/ss4Dh99jLLqlkg9QPcmPeplYzu9ijmssMMZlbVghEaURS9M Gr1+UfNsdBH/RGv6tEDmvHSPczZJL3nih0jfE32JK33BnBGvCOeTbdDHDMDKOs786Wa9i3ztxwvC 7NpKHfU2s1Uis33PGIxH192yFGOa4VrOzgQS/GY6jEJWtXpJmz6X4BtFPvRE7JyJtx5Ia115a0a1 zxv8xbDv6+swbdM1MHcg1m8/9LcrlsXl11nFyq2OX6Vsm32X+H/0ujVlPZIyXcp6qpjuFS0wvWT6 yXHRC/HKWDMlK27rZtmD4mQpitSrTsP0rUAwucu6J4qT1UfvsMZlpMqIVyWhGqzA1LFnx61zzqZV CJTUP+6zl2aNt/IFM2SIesEcipJfMWx6f/ghKRpAwOtm5JspyE1PxeBCPmi5tdl7PGn1fHh79DGP 9L///ds//pG5fDw8Ad0G//3vf/7rX3/v7k7HMwT8UvSMNel7kdkO397jSYfzl3Zh/XgpXoxDAAIT E+D6zMTJw3UIQOBSAujjpXgxDgEITEyA/fXtyfu6Bt3/83XpNvgTv94dNEgzCGxFYDV9PH+m+aSF X5JUKaIWgcuYqcirs/zshdGtJhLBLklgNX1MSerWBenYZsFr1iNS5dz4rFQH3pKy5AQgKAhUCKCP P+B0yuJPNcwaabM8qmZFMU8uWkf5gx0ITEVgF32sPE1hHkhI6astu75Fx6zODh8L0Y9AmDOD2U29 N1h5tCNbdb9FGaGcalri7EsIbKGP/gmB0jMDB6u89PZDpZ7Z/fjhQaO/WWfiPpcqKR9LEkqWky+Z f7jxbgK73N/zEYv0o5eH+shxmj59P7Ly9b6RdIpTr+aOu6sWfnFq3EsCKkOk9v5IfdD8e1a+Qvh4 3+QwjSGwJ4Fd9FFeo6Sf3k8HQ4lP4vj9k5Zm0b6BAbx7SRCNxvkjAdu5JkhkJzi67UVgF33U0pZW f93qdqbvYXHJmlQvddNnf+TQGg0gAIEzBPpl4syo1/U1e17/rid/JDnjV2o/nHTrR/3XyhWeyh5c C7TZ+Gs1TL5ljxxirEn5z4gOTdEAAhsSWE0fL0zhhIKSZDezUp4wlgszi2kIFAigjy2lscDF3wVC aMkYbSFwhgD62E5vxnsJZ/S5PTP0gMBYAujjCZ7vF533e3gCP10hcDUB9HEE4cDz1yOGObLxEjeO 3OTvEJiFAPp4TaZa3rLT5sF1ltv8oDUE1ieAPl6eY3uTzclnV37epv7xvvtGzssjZwAITE5gX328 9DbvIVUR8TDSpuLMye5DwsQIBF5LYLvnZ16bCRyDAATeRmDH9WP2GZvI03uVp3GyefWvw0jbYX/b dral2DTjmgdvIgY/pnTU/tUVZpPOuvJtExV/HiGwoz4m0F4C9BH57A9mmwX3sFoZK0NUPDQnHIMG Sz6jg4/MOgadhQD769+ZklXVoWp8GqSfjjRnL6cEDWZfGhS5PpNC8+vWDv/pAoF9CKCPPbnOvo6s x9B3n+EGvTPD3o12Jk76QmAqAujjj3SldVZkRSZb4LHprq9JuxetkbOrYwPBGgQWINCgBQtEa0LI 7jeNPprLGkYW60paEjv9vjLz7jJ/nUSfcDQOa9VLZ1SlcfZPyfn6EBJg/EtivcIgIgj8mghMA10K fvHYtJxcpqr2jHqZ9BHIKAJbrx+NMvrllVmFjYKOHQhAYAoC6OMUacJJCEDgAQJcn3kAOkNCAAJT EEAfp0gTTkIAAg8QQB8fgM6QEIDAFAR218fuOwrj2e17zCbZP9M37iEtIQCBLIHd9fGG25siQ9Tv lKR2IQCBRwjsro+PQGdQCEBgCgL73t8TfzDGtywdMa8aqzzE8ikO8+RMKpf6K9RKD8zw4okpJhtO TkdgU33Uz4fI5+DBbDM5V+h305X2Wg1L7/XJttE+a6mN7OWnq1EchsBTBNhf/yCfLteY5aEc8epj jjwiT48M+lS9Mi4E7iSAPv6gnX3PGG8Gu7MiGQsC7yGAPuZzIUtIfcrPX2Xm/pv3lDKeQGA4gU3P P8rpQgFaes9Y8DJOvZlce8k2S38111iM8mbdK12uGV4lGITAngT21cdH8q2v1TziAINCAAJxAuyv 46zOtkzLPbbkZznSHwJ3EWD9eBdpxoEABGYjwPpxtozhLwQgcBcB9PEu0owDAQjMRgB9PM4Y5w2P GdECAisS4PzjQVbTFWfzjKDuY5657igSc5vOIxbMoKOus58PrYNGvUs2NO/nKAJZZ8y9XANjzFq+ brhWz19YD/UQWD+2pviv9uluRHmw7+QTfun5nB4/vvqkmXzGgh96lLXhjnVTko6lB+QvfVQ0ezfr +ViCiRuVzZMOX1GoJ1067I4+HiAyUqhl0Xw+ZH11g5dMg6vDvM4+AK9jqy1PxJn9dWdJmP2XbMON aMY3FH5Dl930JXfN4zT6oI9Hb6/ks/+QOmYdNo/9ZA3Wu8uU0PYP4WTHza4EK6w8Lu9MlqqZxhEy Jfje52zBHAIRO5F4dTYNBHNSKB6ayUhp8hiDty2fOydzuRv62InU66MuQdEvPRXrX5tZwRXR8edA 45bTPPHtjcxp97LttZ2SwaxXh6FlcxAfwrcs+W9QaLzGh4jPlVHq1kS5dJ30WROdzea3lA6p1Upt xA1Wgo0H1TkPL+7G/noY4Kz8feoj/XQMY/rKXOqzlnVg+E4nEq8sXowGGQ9TMy3iFYaVcUfF6Ido 8tA7nz0TGqmW85Xgl8Zm3GxoJ+PtmAKPd0Efr03Bp6Tkp3Uk3zcJyqgJ3+pPpP2ZeLMKImJaH33s uKXvEp/KdGTUN1Y8irGVkB03G9rYeCMV9Wwb9PEm/memUOpbX23dFEZ4mHq8SVPqQi8WmgTIj3uG fGnjLxvz9KHJwwjCus+H6CJDdITWl5FuZ97QkfOPPVnQhZKUS+aJ/CqbIP2nelGalsasHig7LYNy Y3zQfvp5bqJIWmDUwccuzcw81x4eTnLdNzuosdZBzyD1wWbjPXSmkuVsVcg5BJ/xUnV6sFnU9WY+ kHpo2YzUS7qPVc+cvKYP+ngN10WtHopaMO5uO90dg47RDAKaAPtr6iFKQLb50Q65dpHrD/VF0/D9 8plw6Ls2AdaPa+eX6CAAgX4CrB/72dETAhBYmwD6uHZ+iQ4CEOgngD72s6MnBCCwNgHOPw7Ir9yf McDWoyaeDeSe0eP30Egqhjh2OG62wWGvw3rhiv8hokoD1o899Cq39fWYu6BP30Xe80/m9I37AZCm 8fAbrQ1aGaWOfHh+I+Om8I1j2YNN9XI+p03DVRp318YoBzrsoI8d0OgymIBe41wtkcn1p1TjqXEH J2wbc+yv21JdWlmkGe43YpH9kfQy3XXfyorGDFHxMCIN2UDqW78kN2fWXGYP6AOvPyqTTWEQi19g 6iP68Y++/MYTl8bNbof9wSwikzuftcNKq3xz+EB0uZZK93xttM3P0a3Rxx6ipXqVp8fMh1Ldy9hZ YfWTM01R+b8xq73yimOslcI2Ra/H0sOVxspO70PEWW+9J5V4vcxl4w26d0V+zcqxCeBhNnVVVBon gCKClVoqfeWYCsxG0RTaYW0824D99TD+2a3Tp1bSz+Ewvnu876HxNDG6PfH20zzRky3iQ2ubk0hb h6u3f5UzZ0K7eo9/T22cIRDviz7GWfW0TOfX009r/zN9s4rW7UnW82QtIv2tgR/q1NhAzrg3Nkdn POnuK3LWUaKlQZ+qjW4IpY7o43CkeYNndORMX+/NEGtipC6R8RWrGPR721KGhgQyKv3POmO2vU1B JeADxTFYG01OPtWY84+d5M15nGQlFVnlT9nB9NTSZerrTE8DM5z8KkOYza+2dqg4JhDft+RzNvzg 3BuIVNzQWCo+l75FNIdL86sd9rUk7gnJbEakPFJ7I9n6m8zE5e1XgCQ9lWRVRjmsyc65d2M39PFG 2AwFgfcR0Av2+OL9fXFc4hH6eAlWjEJgIgKRvcVE4Qx0FX0cCBNTEIDAUgS4PrNUOgkGAhAYSAB9 HAgTUxCAwFIE0Mel0kkwEIDAQALoYxvM4A19bUZPt87efJdc1X9qukfvkUibPPTYznT38T5C4HQt WAPnmZyxMDycmw2ij23Ag7fytRk93dp7lW7UMMebnG9qfDqCXwbODHpyGvuhzzgzCsh5O91RZEvo vD9zWUAf58pXs7fd06N5pEc7cOPeWPya5yYllAXI/T3NdVV6DCN4E5np7h8/EIe8QT90vc3HVPYJ kMoQnz+VRonME+1P+qyftaiwNoFksXjjYl/CrDuZzVGFqgHoY4nkKIs0XnZZMhGqkdqoI5UMxr1d rCX62JxQ/dUqn7MHvel4X9+yMoRfPWXXU+ZgkzOiFHWN0w/AmTkcWeKVYqxzzv61G37FBwMhmKNg beTXL1/nSdKfdJhauA+/EnSDuM/xIZqn0Dwd2F8Py9Wn8tJPxWKSjODXcsVgZCkXCSzic5onkRFl EachRDpGXC21ichu6pt1r2loH4sBmM1vU9KNPyWfr6Ya+TpsQjdpY/RxWOKSiBxKSWpQl1GZzxGD ZwII+hwfIqnVdbNX0IksivpEkA53zwPM5jee9NKy906k8XQv3xJ9HJ/iykSVPwUlUjZWxsuIFjQF Vjd4uC4WP6+bxvVVeUSU4yvNJnQ6R9n8lg5Gknipzx1h7taF84/NGS9tHvU0qGwG5U8iJXGDfggz x2Q7ZkbJNvu0yfrsGwdPCGiDmoD2qiSgpUFlKa0NZlWjlb/ecRtv486YQbOprByMfJ2UZPSQarA2 St9tEZ7Nk2e2Dujj8xljjZDNwfJYHgnwkUGfn2O9HqCPveQG9eNbuiSO2ZXjIOoPm4mvx8c6SrG1 8kQfW4nRHgIQ2IUA12d2yTRxQgACrQTQx1ZitIcABHYhgD7ukmnijBNI5+ki99/EbdJyRgLo4+Cs fSaVn1fZg4MHftrcMjGmK7xc5326oF4xPvo4OA3ZO9oit7kN9uN2c+djZL12e9IY8IAA+kiJQOAH gST05+UerAsQ4P6eniQePnZSejZGbnwzd8AFDWafxAgG4IcoOeMNBu+bk52p1pdIaNknPUpuyKOZ WsL0KBVrwUBKSNl0B4ttmWboY3Mq9SSRz00HzfIk2DfbLOh9qa+R6ay1+Ljamj+LV2f1GTqiPn4I 01GPa3yIBxKkSrPlCbC/bk6xPPfafb7M790+ptKPeCOvpREx9UeaXc91ONxINsV7aC2FI8FG2huv fZe4h57zEIYYWZUA+tiT2bQS6ZjbpcGSNWMz/WpE0xzp8b69z0Xxdn/BZLfekYxkObfzoMcuBNDH 5kxHtoHNRr87iGTIBxFEfyRtLQeqzOH+ujsu3TEbyBnLHRnRnK8GeCY0+j5LgPOPPfzNjJL9nbaV PegbpCNaMsyRtCHVbeSIHIysZCNDlFhk4zWNjf30q17tipNmReylsxROaQgDJxlMQ4sDhqFxJgIw jRJs2VNV9HkfAfL9vpw0esSkbQTW3xzU/ezm7Ik+zpk3tepkRTNxCnH93QTQx3fnB+8gAIHnCHB9 5jn2jAwBCLybAPr47vzgHQQg8ByB1fTxhvtdnksWI0MAArcSWE0fuVhxa/kwGASWJrCaPi6dLIKD AARuJYA+3oqbwSAAgYkIoI8TJQtXIQCBWwksqI+PvMHh1qQxGAQgcAuBBfWRh8BuqRwGgcD6BBbU x/WTRoQQgMAtBNDHWzAzCAQgMCEB9HHCpOEyBCBwC4HV9JF3nd5SNgwCgS0I8P6eLdJMkBCAQAeB 1daPHQjoAgEIQCBLAH2kMCAAAQjkCaCPVAYEIAAB9HHOGuCNbXPmDa9XILDa9Rn/r/S1Zum8hdYR 6+15HGgsT6xBIE5gtf115B+Jr9BJYnTpSyS5AylenbSEwLMEVtPHUTQvlchRTmIHAhC4lMBq++sE y+9J/a45+4/NC+vDf6I+tdTNSkOU3icUlGD215dOAIxDoLahDM7SuSAaTdG/ps/+SElYfeDZvhWD XkbjzBHHuQoPbxcjsMv+Ol0F9mvGG84GxtXQ1xbvslxsvhHOXAR20cd01UVfe7nhUsxcpYC3EICA IbCLPkrYacHIvpWZAAEIHBJY7fqM2S/L3rZyfUautOi+lU1xqVl9CH8lJ7jvRsoPi5gGELiIwGr6 eBEmbfZmwUqyGxTTG8JnCAjsQwB9bMu1XyS29ac1BCAwDwH0cZ5c4SkEIHAvge2uz9yLl9EgAIGJ CaCPEycP1yEAgUsJoI+X4sU4BCAwMQH08fLk3fCIzuUxdA2gH1jqMkAnCDxMYF99vE22um/NucHD S4foDvzhOcHwEPgmsK8+UgMQgAAE6gR2vL8n+4yNvrGxtKqqPI2Tpexfh/FpJq+cqLwbrf4UkHcj jX5oUA9dGsIEInen69vUs5/rVOvuff6aHSgdZx2Kij1FYN/i8xNPH5HP/mC2WSV/pr0oRWWIZC3r oRcaLZfpcykQ09cP4b8YjJrXfU5/9f834ZQAatl9aj4wLgQ0AfbXv2mIFhyuWdKVh9Iys15h2dVQ 0KB+/1BHHR8uxPRbjvRYhx1bnSnFO3ygVsdoDwH08WwNaB05a+ur/3CDQ7y6zshu8V5HEsuXEmD9 +AOvbA+D0PuWkBXjdYPdi9ZgOPc3Gw7w/hAYcWEC+55/TGff0tpNJ9hsrvUE7r4+YwpIzhLK6DKK d0Z76B3OuiehefvZeP1Bcdg4ph3ISps+/5iNOh308VYCYdO9sAC9PLSt9dHnxp95PDwX+WyCX+7e eTjLB3geERauI4A+/mKbXcGVlnXX5aPJ8svda4qFxhB4IQH08YVJwSUIQOAVBLg+84o04AQEIPBC AujjC5OCSxCAwCsIoI+vSANOQAACLySw+/nH7C0+Pk99V0L6eqXRzd0z/iFC4yTXeV84u3BpdgK7 rx8j99Yl6Ym0NNWQ7RW/I9o/ZFLqG7c5e73iPwTuJLC7Pjax7pDIJvuHjUvPbj/u2KHnNIDAjAT2 3V9HHoypbHJTsktPwmjBkp1vyVq2boLPk2jj9QeBZqxOfIbAswQ2XT/KltkLWdrVynnJ1EDvlHVf f/qyspQTI8Hduuyv+7bPLCqfnVqMvgCBTfWxlLmPEqWfSmplzdgnW8Giiagb12SCMGkGgT4C6OMP bv6SSGnzG1wD9mXl0ysivmmdeyjo3T7QEQKbE0Af8wVQkadXrdpE0DevY8KHwBUEuD7zi6q+0iIX Xsw6Tva82Sst/mD98s7hDlq6+3H9pZgURva60BV1g00I7EBgX31cPruvWucuT5sAlySAPi6ZVoKC AAQGEOD84wCImIAABJYkgD4umVaCggAEBhBAHwdAxAQEILAkAfRxybQSFAQgMIDA7vp4w83VkTu9 S5k803dAdWACAnsT2F0fD29CPF8ekSFKOhjpe95DLEAAAlkCu+sjZQEBCECguIHbdoWSfYGYf2Tl A863LB3RL/7RHc3DOSkZlYO+b+pi3JO3B8kHCh0CEBhIYNP7w/WzJfI5eDDbTMTLf99U2usHB7Nf VId9tTLywMzAiYEpCHwIsL/+UQb+dTjyjhxZ8ekORtQeWYw/MiiTBwI7EEAff2Q5+36zdJBLyTvM B2KEgCaAPubrQdRQn/LzEoloMp0gsDCBTc8/6msdKbt97zfLvvGs8hq07EWh5IC5xlJ/hVrWW67S LDxRCe0RAvvq4zO4v/6p2EeGZlAIQKCVAPvrVmL97dP6ji15P0F6QuBeAixn7uXNaBCAwDwEWD/O kys8hQAE7iWAPt7Lm9EgAIF5CKCPx7nivOExI1pAYEUCnH88yGp6aM8856f7mGeuvbm+x/6yT4I3 VeB5C03DSWMfb9aTPiwRl9a+z+md0b3Tq0i11NuwfuxhmO7RkTt16rfs9N3Qkx7a6XHuq09SnzMW uoc2g5Y8Getb5cbS7kD6Ol59f8JYbn0x+l4Rr64mMyoWbQd9PKBqpFDLovl8RXrO24wU7vlRIhbe 40nEW9pA4K91BlXbVwdmeyjbcC2apX2ljHgI34+S+uqOZpTsgzelGM2yq9Q3GEjQk9LG3x+PrAqz PmfTkZbVHqCGU6FXcq/0bH4lubIb9R/ESW82+LCWaVY//6P3xWaPnIU/MEeRdPTNzYG90MdOmFnl ksf+jH7pks1+ruhXva92o/S5ybg3kjVbGSv7zeF9qDQTdYuziqQjyKcpXqMpac4ffu1pEZQulXEN kGCOzCgny8CENiRH8fx2ztLT3dhfn0b4bSAyK9KXuZ9UQSdSX//Fbg4GrcWd8ePqISKBR1wyo8Td yxrPelUPJOKkb9MdfnfHrJ+l0PpGKcG/AmAf9nt6oY/3cP49yqfySjuyQ1dS3/QjjdM3efc0iDiT HffQ29YGfpQzrEqi6QG2+vnO9sNzlIU/fJR3whSv0MdbEyRLv4gqVTwTO8HdXGnFkY7HndFLVy3Q YyGmUUaxqsc+1vM3WMvmqNWxQ/hDRmn16v72oXMl97v18hF19ZiZLL960TFH6is+U3+psRk3UfIt /Qb8UCPEmWzf+rjZvl52K81MICbYZOqwJOSsRTY7FYDGcomeh1BvWfG55GFWdFLZSPGUqijunicZ L6H6KIeZkhxlM36Y4vsboI/3M3/1iGcWpK8OLOwcBMKo1m/I/nr9HMcjNBvbeMdlWkJgmVQOCYT1 4xCMGIEABBYkwPpxwaQSEgQgMIQA+jgEI0YgAIEFCaCPCyaVkCBwEYHdzs+ij/2F9KmV+l1gqYFv U+/V7xA9vwgc5gVOfQTkNqPI7VZ9Q7ytF/rYn5HDKik91nLYsd+nmXue+doo3Yr4Eh5nQntJCHu6 gT7umXeihkAzgfS9vtW3O/f3NFdJ2sFJN/9YiCkgfb9x5fED/VxE9mEPefbAPIRgAvDPQqQGfujD QGQydPStP5BzxudIX9kJmvmcDSRrUD+vkgUY5FxqVsqIL8dIsfna0JGaqLO/+njjE0NXeLzXFC3R x+Y0Gb0TLdOKoCXSV485EjdYV0aJRJ8n8ueMZLjguPVm2b+myS8Pxom+HD5SWeJ2OAM9Ui3uhzkq SaRBagIJchYaepQSN++Jr6tSRvyXQXff5lmxaAf218MS+6na9DPKYtZg9+7GW0v6ZTTXHxRxiYRm RskOMYpP3U4WVDxHvnu8bzDAiMESwDO1caZvMLRlmqGPw1KZrsaknyajsrUxi6Bug9nRs9bSQSN8 /mByTMcl89YE60fJDtHEZ2DjM0jP9I1nxLes5KhebPfU1cDsvNAU+jg+KZF1VtOoYw2KNfmgJdIf NKqt95iVb4JkJztEU+wXNT6D9EzfbDgVg4cAzzhTH/eM5Yuydr9Zzj/2MPcLLqMFIiLaenalJg28 DOm5oe1/Ph8KUxpLRtRDS18dRfxgGj3b10MoNStBT+29M5V4NUDjW+qlbRqkh2qlx82mI8JZF0PF 4HlnkgXDqq+uTCLqkyT7Ddozr97XB318X05m8EhPiYWnxwypeN7HhQsAfXy+vCb1ILIWmzQ03IbA r1V/ZOcCLAhAAAIbEuD6zIZJJ2QIQCBEAH0MYaIRBCCwIYHV9PFzUoz7EjasY0KGwBUEVtNHTqde USXYhMCeBFbTxz2zSNQQgMAVBNDHK6hiEwIQWIEA+rhCFokBAhC4gsCC+ugf47sCHDYhAIHlCSyo jws/7bR8ORIgBF5FYEF9fBVfnIEABOYlgD7Omzs8hwAEriWAPl7LF+sQgMC8BFbTRx6embcW8RwC byPA+83elhH8gQAE3kJgtfXjW7jiBwQgMD8B9HH+HBIBBCBwDQH08RquWIUABOYnMI0+8uKy+YuN CCAwGYFp9JEXl01WWbgLgfkJTKOP86MmAghAYDIC6ONkCcNdCEDgNgLo422oGQgCEJiMwEz6yIvL Jisu3IXA5ARm0kdeXDZ5seE+BCYjMJM+ToYWdyEAgckJoI+TJxD3IQCBywigj5ehxTAEIDA5gWn0 kReXTV5puA+B+QjwfrP5cobHEIDAPQSmWT/eg4NRIAABCAgB9JFigAAEIJAngD5SGRCAAAReqY+8 tYzChAAEXkvg4fUjby17bWXgGAQg8LA+kgAIQAACryWAPr42NTgGAQg8TAB9fDgBDA8BCLyWwPP6 yFvLXlscOAaBzQk8r4+8tWzzEiR8CLyWwPP6+Fo0OAYBCGxOAH3cvAAIHwIQKBJAHykOCEAAAnkC D+sjby2jMCEAgdcS4P1mr00NjkEAAg8TeHj9+HD0DA8BCECgTAB9pDogAAEIvPL8I2mBAAQg8FoC rB/7U8PL2frZ0RMCMxDYXR9PahzvZ5uhyPERAp0EdtdHBK6zcOgGgQ0I/A8/BnAiCWwZmgAAAABJ RU5ErkJggg== --_005_381D7D55085B1E4D8B581BD652E1E140C91655C0nkgeml513mbxchi_-- From nobody Wed Jun 28 12:42:14 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB4A12EAD5 for ; Wed, 28 Jun 2017 12:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8ef1t-xImFs for ; Wed, 28 Jun 2017 12:42:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1201126DC2 for ; Wed, 28 Jun 2017 12:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46475; q=dns/txt; s=iport; t=1498678930; x=1499888530; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TmFx84hHNyMBRAzCWlsfp6/HZMtDCYs9T9bbsnVJQGE=; b=FleVIInuvuWCVfr4/CL/bFXfiFRmUrzSWczgPw0ZVcaNwkXmPmVY4gHJ djBSnMEMtR0XzIoR4ONuvCV9YqqwxJyibTxARh2rtPg1Q/ZPLGHZ42TOm To0uZZ1V2pSOH74ehr9OkLBqrSAxwzfzbhhYkUcSc72ky5pBTpKlDyi+D Q=; X-Files: image001.png, image002.png : 9896, 10553 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAQB9BVRZ/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8NLy1jgQ4Hg2WKGZFDIpBPhSuCEQcBJIVwAhqCbz8YAQIBAQE?= =?us-ascii?q?BAQEBayiFGAEBAQEDBR4CCAFLEAIBCBEDAQIGAQEBIgICAgUQDwwdCAEBBA4EA?= =?us-ascii?q?Q6KIhCxe4ImKYseAQEBAQEBAQEBAQEBAQEBAQEBAQEBDgoFgyeDTIIMC4JuhQq?= =?us-ascii?q?CczCCMQWedAKGNgGBAIw3ggqFSoNuhlSVJwEfOIEKdBVJEgGEfhyBZnaINAGBD?= =?us-ascii?q?AEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,277,1496102400"; d="png'150?scan'150,208,217,150";a="263580812" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2017 19:42:09 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v5SJg9pK011962 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Jun 2017 19:42:09 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 28 Jun 2017 14:42:08 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Wed, 28 Jun 2017 14:42:08 -0500 From: "Clyde Wildes (cwildes)" To: "Zhengguangying (Walker)" , "Zhangjun (Echo, CSD)" CC: "netmod@ietf.org" , "kirankoushik.agraharasreenivasa@verizonwireless.com" Thread-Topic: Some questions about "draft-ietf-netmod-syslog-model-13" Thread-Index: AdLv1JZSQaF8X4AWRYG7oeU4gagUqQAYUYmA Date: Wed, 28 Jun 2017 19:42:08 +0000 Message-ID: References: <381D7D55085B1E4D8B581BD652E1E140C91655C0@nkgeml513-mbx.china.huawei.com> In-Reply-To: <381D7D55085B1E4D8B581BD652E1E140C91655C0@nkgeml513-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.100] Content-Type: multipart/related; boundary="_005_F8D795413D494011ACDDC75E8850A169ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Some questions about "draft-ietf-netmod-syslog-model-13" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 19:42:13 -0000 --_005_F8D795413D494011ACDDC75E8850A169ciscocom_ Content-Type: multipart/alternative; boundary="_000_F8D795413D494011ACDDC75E8850A169ciscocom_" --_000_F8D795413D494011ACDDC75E8850A169ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWmhhbmdqdW4sIFdhbGtlciwNCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUgbW9zdCByZWNlbnQg dmVyc2lvbiBvZiB0aGUgZHJhZnQgaXMgcmV2aXNpb24gMTUuDQoNCldlIGhhdmUgc3RyaXZlZCB0 byBwcm92aWRlIGEgbW9kZWwgdGhhdCBtZWV0cyB0aGUgbWluaW11bSByZXF1aXJlbWVudHMgZm9y IHN1Y2Nlc3NmdWwgaW1wbGVtZW50YXRpb24gYnkgbXVsdGlwbGUgdmVuZG9ycyB3aXRoIHRoZSBj YXZlYXQgdGhhdCBhIGZlYXR1cmUgdGhhdCBpcyBvbmx5IGltcGxlbWVudGVkIGJ5IGEgc2luZ2xl IHZlbmRvciBjYW4gYmVzdCBiZSBoYW5kbGVkIHRocm91Z2ggbW9kZWwgYXVnbWVudGF0aW9uIGJ5 IHRoYXQgdmVuZG9yLiBEZXN0aW5hdGlvbiBWUkYgaXMgYW4gZXhhbXBsZSB0aGF0IGNvdWxkIGJl IGFkZGVkIHRocm91Z2ggbW9kZWwgYXVnbWVudGF0aW9uLg0KDQpSZWdhcmRpbmcgeW91ciBxdWVz dGlvbiBhYm91dCBETlM6IGFyZSB5b3UgYXNraW5nIGlmIHRoZSBhZGRyZXNzIGxlYWYgd2hpY2gg aXMgZGVmaW5lZCBhcyDigJx0eXBlIGluZXQ6aG9zdOKAnSBiZSBhIGhvc3RuYW1lIHRoYXQgY2Fu IGJlIHRyYW5zbGF0ZWQgdGhyb3VnaCBETlMgdG8gYW4gSVAgYWRkcmVzcz8gSWYgc28sIHRoZSBh bnN3ZXIgaXMgeWVzLg0KDQpUTFMgd2FzIGFkZGVkIGFzIGEgZGVzdGluYXRpb24gdHJhbnNwb3J0 IGNob2ljZSBpbiByZXZpc2lvbiAxNCBvZiB0aGUgZHJhZnQuDQoNClJlZ2FyZHMsDQoNCkNseWRl DQoNCkZyb206ICJaaGVuZ2d1YW5neWluZyAoV2Fsa2VyKSIgPHpoZW5nZ3Vhbmd5aW5nQGh1YXdl aS5jb20+DQpEYXRlOiBUdWVzZGF5LCBKdW5lIDI3LCAyMDE3IGF0IDExOjI1IFBNDQpUbzogIkNs eWRlIFdpbGRlcyAoY3dpbGRlcykiIDxjd2lsZGVzQGNpc2NvLmNvbT4sICJraXJhbmtvdXNoaWsu YWdyYWhhcmFzcmVlbml2YXNhQHZlcml6b253aXJlbGVzcy5jb20iIDxraXJhbmtvdXNoaWsuYWdy YWhhcmFzcmVlbml2YXNhQHZlcml6b253aXJlbGVzcy5jb20+DQpDYzogIm5ldG1vZEBpZXRmLm9y ZyIgPG5ldG1vZEBpZXRmLm9yZz4sICJaaGFuZ2p1biAoRWNobywgQ1NEKSIgPG9saXZlLnpoYW5n anVuQGh1YXdlaS5jb20+DQpTdWJqZWN0OiBTb21lIHF1ZXN0aW9ucyBhYm91dCAiZHJhZnQtaWV0 Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTEzIg0KDQpIaSBhbGwsDQoNCg0KSSBoYXZlIHJlYWQgdGhl IOKAnGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0xM+KAnSwgIHdlIGhhdmUgc29tZSBj b21tZW50cyB3YW50IHRvIGRpc2N1c3Mgd2l0aCB5b3UgYWxsLA0KDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTEzDQoNCg0KICAxLiAg QmVjYXVzZSB0aGUgZGVzdGluYXRpb24gbWF5IGJlIGluIFZSRiwgaW4gdGhlIGRlZmluaXRpb24g b2YgbGlzdCBkZXN0aW5hdGlvbiwgdGhlcmUgc2hvdWxkIGFkZCB0aGUgdnJmIGF0dHJpYnV0ZQ0K ICAyLiAgV2hldGhlciDigJxETlMg4oCcIHNob3VsZCBiZSBvbmUgY2FzZSBvZiB0cmFuc3BvcnQ/ DQogIDMuICBUaGUgdGxzIGNhc2Ugc2hvdWxkIGJlIGNvbmNlcm5lZA0KDQpQbGVhc2UgaGVscCB0 byBjb25maXJtIHRoZXNlIGNvbW1lbnRzLCB0aGFua3MNCg0KUmVnYXJkcw0KWmhhbmdqdW4sIFdh bGtlcg0KDQpbY2lkOmltYWdlMDAxLnBuZ0AwMUQyRjAwQi5GM0QzMTg1MF0NCltjaWQ6aW1hZ2Uw MDIucG5nQDAxRDJGMDBCLkYzRDMxODUwXQ0K --_000_F8D795413D494011ACDDC75E8850A169ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7C5D3C8FF921284A9B3E0BFBC74F5875@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcgMyA5IDIgMiA1IDIgNCA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1 IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1T dW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9u dC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj MDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0 RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseTpTaW1TdW47fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0K CXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpwLkhUTUwsIGxpLkhUTUwsIGRp di5IVE1MDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCglmb250LXNpemU6MTAuNXB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5 OlNpbVN1bjt9DQpzcGFuLmdyZXkNCgl7bXNvLXN0eWxlLW5hbWU6Z3JleTt9DQpzcGFuLkVtYWls U3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q291cmllciBOZXciLHNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM2ODA2OTYzNTsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTI3MDUxNDY4IDIxNDMwODEyNDIgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDouMjVpbjsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlMlwpIjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFy Z2luLWxlZnQ6NDIuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxl ZnQ6NjMuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDo4NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRleHQ6IiU1XCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMDUuMHB0Ow0KCXRleHQtaW5kZW50Oi0y MS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MS43NWluOw0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNDcuMHB0Ow0KCXRleHQtaW5k ZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlOFwpIjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MTY4LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjE4OS4w cHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssc2VyaWYiPkhpIFpoYW5nanVuLCBXYWxrZXIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5QbGVhc2Ugbm90ZSB0 aGF0IHRoZSBtb3N0IHJlY2VudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpcyByZXZpc2lvbiAxNS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssc2VyaWYiPldlIGhhdmUgc3RyaXZlZCB0byBwcm92aWRlIGEgbW9kZWwgdGhhdCBtZWV0 cyB0aGUgbWluaW11bSByZXF1aXJlbWVudHMgZm9yIHN1Y2Nlc3NmdWwgaW1wbGVtZW50YXRpb24g YnkgbXVsdGlwbGUgdmVuZG9ycyB3aXRoIHRoZSBjYXZlYXQgdGhhdCBhIGZlYXR1cmUgdGhhdCBp cyBvbmx5IGltcGxlbWVudGVkDQogYnkgYSBzaW5nbGUgdmVuZG9yIGNhbiBiZXN0IGJlIGhhbmRs ZWQgdGhyb3VnaCBtb2RlbCBhdWdtZW50YXRpb24gYnkgdGhhdCB2ZW5kb3IuIERlc3RpbmF0aW9u IFZSRiBpcyBhbiBleGFtcGxlIHRoYXQgY291bGQgYmUgYWRkZWQgdGhyb3VnaCBtb2RlbCBhdWdt ZW50YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5SZWdhcmRpbmcgeW91ciBxdWVzdGlvbiBhYm91dCBETlM6 IGFyZSB5b3UgYXNraW5nIGlmIHRoZSBhZGRyZXNzIGxlYWYgd2hpY2ggaXMgZGVmaW5lZCBhcyDi gJx0eXBlIGluZXQ6aG9zdOKAnSBiZSBhIGhvc3RuYW1lIHRoYXQgY2FuIGJlIHRyYW5zbGF0ZWQg dGhyb3VnaCBETlMgdG8gYW4gSVAgYWRkcmVzcz8NCiBJZiBzbywgdGhlIGFuc3dlciBpcyB5ZXMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmIj5UTFMgd2FzIGFkZGVkIGFzIGEgZGVzdGluYXRpb24gdHJhbnNwb3J0IGNo b2ljZSBpbiByZXZpc2lvbiAxNCBvZiB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZiI+Q2x5ZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ JnF1b3Q7WmhlbmdndWFuZ3lpbmcgKFdhbGtlcikmcXVvdDsgJmx0O3poZW5nZ3Vhbmd5aW5nQGh1 YXdlaS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEp1bmUgMjcsIDIwMTcgYXQg MTE6MjUgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O0NseWRlIFdpbGRlcyAoY3dpbGRlcykmcXVv dDsgJmx0O2N3aWxkZXNAY2lzY28uY29tJmd0OywgJnF1b3Q7a2lyYW5rb3VzaGlrLmFncmFoYXJh c3JlZW5pdmFzYUB2ZXJpem9ud2lyZWxlc3MuY29tJnF1b3Q7ICZsdDtraXJhbmtvdXNoaWsuYWdy YWhhcmFzcmVlbml2YXNhQHZlcml6b253aXJlbGVzcy5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4m cXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldG1vZEBpZXRmLm9yZyZndDssICZxdW90 O1poYW5nanVuIChFY2hvLCBDU0QpJnF1b3Q7ICZsdDtvbGl2ZS56aGFuZ2p1bkBodWF3ZWkuY29t Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5Tb21lIHF1ZXN0aW9ucyBhYm91dCAmcXVvdDtkcmFm dC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMTMmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkhpIGFsbDwvc3Bhbj4sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1pbmRlbnQ6MTAuNXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtaW5kZW50OjEwLjVwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWlu ZGVudDoxMC41cHQiPkkgaGF2ZSByZWFkIDxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCnRo ZSDigJxkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMTPigJ08L3NwYW4+LCA8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7d2UgaGF2ZSBzb21lPC9zcGFuPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPmNvbW1lbnRzPC9zcGFuPiB3YW50IHRvIGRpc2N1c3Mgd2l0aCB5 b3U8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+IGFsbCw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW5ldG1vZC1zeXNsb2ctbW9kZWwtMTMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMTM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9 IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LS4y NWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+QmVjYXVzZSB0aGUgZGVzdGluYXRpb24gbWF5IGJlIGluIFZS RiwgaW4gdGhlIGRlZmluaXRpb24gb2YgbGlzdCBkZXN0aW5hdGlvbiwgdGhlcmUgc2hvdWxkIGFk ZCB0aGUgdnJmIGF0dHJpYnV0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LS4yNWluO3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ V2hldGhlciDigJxETlMg4oCcIHNob3VsZCBiZSBvbmUgY2FzZSBvZiB0cmFuc3BvcnQ/IDwvc3Bh bj4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDotLjI1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8yIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgdGxzIGNhc2Ugc2hvdWxkIGJl IGNvbmNlcm5lZDwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UGxl YXNlIGhlbHAgdG8gY29uZmlybSB0aGVzZSBjb21tZW50cywgdGhhbmtzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlpoYW5nanVuLCBX YWxrZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSI0NDUiIGhlaWdodD0iMzA4IiBp ZD0iX3gwMDVmX3g1NmZlX194MDA1Zl94NzI0N19feDAwNWZfeDAwMjBfMSIgc3JjPSJjaWQ6aW1h Z2UwMDEucG5nQDAxRDJGMDBCLkYzRDMxODUwIj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iNDM3IiBoZWlnaHQ9IjM2MSIgaWQ9Il94 MDA1Zl94NTZmZV9feDAwNWZfeDcyNDdfX3gwMDVmX3gwMDIwXzIiIHNyYz0iY2lkOmltYWdlMDAy LnBuZ0AwMUQyRjAwQi5GM0QzMTg1MCI+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_F8D795413D494011ACDDC75E8850A169ciscocom_-- --_005_F8D795413D494011ACDDC75E8850A169ciscocom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=9896; creation-date="Wed, 28 Jun 2017 19:42:08 GMT"; modification-date="Wed, 28 Jun 2017 19:42:08 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAb0AAAE0CAIAAAA383oDAAAAAXNSR0IArs4c6QAAJmFJREFUeF7t nQmW5SiSRSt7SVWr6l5Q1aq6t5T9IyzS0sKYTAgQ6F8/ceK4y8GGC3qfQcj/+PPPP//BFwQgAAEI hAn8V7gkBYcR+OPn1zBzGIIABNYSeF43v1NBGOav7ed4g8BIAlN085IUHqcgl7Ib2VbYggAE9iAw RTf3SI0oIAABCEwh8EdpuGdHVVpGL8oV+fHzvftGI7XGXV2tLhay1tROqa51ncWTRijFrEE3fqzE XCqZhldvq0/540bZU3ofRiFwJoH8DWxvbP2+dNEKnyqg04VsXZUwp8vOSKmuamJTpDTCrEcRX/e/ aKsNLPt9pVgpKkTzzDuFqCHwN4H2PL05MmoWsMLaXBzMWpMN6LRuxLUTTZXOrMG+rlEKL2tNx8h9 vqgFAQg8TqCtm6NClHFWUOmcU6nYXT1NYazBsdZGAccOBCAwiUBbN5sjxEhkoyanQ4KxAY81ONZa BCxlIACB9QTa+0KRfRK3sSOrfm6CnG6qlFSmZM0atHUrY9hSMbuTo6HqKqddWJAmSZdrs8EER9Oj PkXWdxc8QgACP/QteKsDayCB4I7WQI+YggAEBhJANwfCxBQEIPAVBNrrm1+BgSQhAAEIhAmgm2FU FIQABCDwkwC6SUeAAAQgcI0AunmNF6UhAAEIjNHN9Imi+BGaeEla6w4Bni29Q4+6ELAExuhm9jR6 5AmnO4eIThSCBTHXn4ql90MAAvcJjNHNUhwR6ZS68ZL3c8YCBCAAgTsE7j6/aQ/efOJIDwWVgiuV dAaletOLfZI8+7171DzrxYVqzxFZZU/PGmnFyNkq9zkRiSQLwdFOXxdiX+CUfjhlkaqR7ATiTj+j LgTeROCubuot7SQjqyCpvrgTh/ZH/T57UVSj5NRVcePZksG0XdODPWlduWL/d7FV3GWtuTD01KnV QfWY8ndY1FoTo/u8YQbwpvucXMYSmDtP12GOfWNQ/Yb83L3y5UTWXbxEIfWYeikZvFM3EqSLxIFS 76qelkx2nBtxGk/2jjXqQuCtBFbo5iV22XeyyVhp4Ago6yUY5526qYu4teEQgvlSDAIQcAS20007 r0wnocPbLzt8C3q5U7e0JlByXZp9K6JgzBSDAATuE7i7vum0w+1ONKfk6UxTDVZWSN2OR7oBImYr wWS9OJrpWoETKbuLouub4vfzf8mFWzONRJIVR5ud41xyoVjS8FwYqYWBg/37vRYLEHiWwF3dfDZ6 vK8hUB/trokBLxDYhwC6uU9bEAkEIHAGgX3XN8/gR5QQgMD3EUA3v6/NyRgCELhHAN28x4/aEIDA 9xFAN7+vzckYAhC4R2CYbt45zxNJ4c7DknfqRmKjDAQg8FUEhunm7Of7IvZL+hip+1WtTrIQgMAd AsN0804Q1IUABCBwEIEBz29m38EhCEpnfrInfNzxG62enqipH1KyfuuHdqSkno1xh2QOakVChQAE VhK4q5v2JImeNbSyqIcO4xed4AoOd2Ql9ZuWUY7NulYxORuzsv/hCwInEpgyT5c9IjcO1SvZ1UZ7 8ZHlyEecnthjiBkCEJiim9l3o8lFtrbpcxCAwOkEpuimnSDrLFu+KUknenp6TyJ+CHwPgbvrm7Kq aHll32+W7h2leupMVd4OVyqp1+t1bfU0WnaHvqf3kykE+ggM0M0+xzdrsXtzEyDVIQCBbgJz5+nd YdUrypCQqf0kvJiFAAQaEsQ+Ml0EAhCAwCUCR443L2VIYQhAAAJjCaCbY3liDQIQeD+BdbrJouT7 exMZQuA7CCzaT0+PYJY2dkrrrZtvoC8Lb/ZjUu4A66eZpq6Az06neRfr7qJ7l8LUrEtRLetFTSz7 F8g23LKw1403sylJ77T/lzJ/qh8HW2JZeLMdzT7wmj7tGyQ8o5joVIp0NuTSoyCz/c5g6Gyuecql 1HALEhQXi3Qzq4yzb9FlEHF0OoEXCNbpTdAX/1MNt2ieXoHiJoZ6gCc98+MYlc4gVT4AszZ1qmjn jJVhkZsgpPOFrEGJKls3TTmLK823NMfU6tlzU9ZdNmU3Y61Ya5a0iZSQ6hqOzjyyrEpdKNsNLJlL 7RtBmkITDnVHtsxVpBX7KZZ4170Zs+vPA/26nhDsRVLM9fngzXVVtbfTTc3crfVUfqysCqWiLI1t 4Tqy2SqKtfTbNLw0kVIwlV5S8RtMLZuvvWHSjxmnhikrd6XkoqT+2c8/lQb3jTNeiVaB3Glflex4 js6du3VTO5WMmr3LSXZptBXvG2lPqNTVT7hKG6U3YyWpCKtILwq6uCqOlfKL5unxiIMDbxE7242a LuqW436lq7lP19R71qBUdHWDrlMXqbUmFutrpd9668RZVewMad9mL2oWSAlHekvTrBbobjUVu7Tr dsec7c+RjiplnN+rd3QEWjeuuvHtdDPCQqHrUDFe635J+XDraw+p2F3dBZ+1Jhebsn6Hwxq/Y1l1 56sfRX0tfqe3dMdcqhgMJlhMhC/Sny8Vm9p1RyE9VTcVblwjhrRHOg3pa4khwahrtdbE8pTfPkpS KxhzsNjVSOIikh1n9ant1SAj5YNdN1jMeQzCrxRrdt1IjsvKPLy+mYWlEwr5QMvOau3Fete0LlKh sfadX3vTWhf1LlI36IKJZ5HKR+rIlcnGbHPUYXtWniIl1UVHIs5+Cj/bcFltcolYDpXmyMacdrZS asGS2d6rEWYBSrd3WZR+zHb+sTErXpFUMZ6NsHnLVDpMvAvVG66vT14V3Id182q4lIfAYgJ2/NU3 FlscsCjsPuPc9ekv8AjfBZBxcTaB4Mh3kyTPinYTaFfDQDevEqM8BCDw7QRO3Rf69nYjfwhA4DkC 6OZz7PEMAQicSQDdPLPdiBoCEBhEQFaEg49Sic/n1zcfXMa2T1QIuB12IR8EMqgfYuYygXc0evOZ v8tc5lfQh6su3fsPjzcl6EsRDyTp/D4VhsvoQSAD2d43denz/767ioUFkbyj0bNZ3ExtAfyOzvOw bmrEm2hWB0GqQAAC5xIQ5bmqP4/NTOvnKGwmOpvOfmMPMKTThLTKr+WJnysa8lU5eONOR2TrlnqM O9VgY8t+7xovXTQoZadZZCOJc/5Ur5/E0Ajr07G07bJXKp31Usxp1tlGdzGXXFgItmOkkCMz62b3 c7era/RSzKVDUPWe4FKznTnbzx3Yet+wiWTXuzr6c7CNNK80i2zMcYnPJvKL21WhjXuNlEw7ij0m 5Y5MpW0j1e3/2huadbMlnQurFPIrDbjC1BYrVanH7CxkDQYj0bpNVjajrPFKzJXylnPWReWDp3Q3 1uHbG6nSylkgTQjNbpOVm2AiJT51vEGqFeOVz7AmwCCQ5p3ezF3BltrIZRHEEpGptMwu8/Rm9E19 V11zH1PNPlFx3XRaqitqLpGoEf081BbNFmuiGFJAwrOsKjHbRCqc08Ccl5X5pkM5l+9NjCnASmdI xbQZTJZz2oWkg6Wd7VJ2l/r5pcKVMCoA+1y4WvexVII/Rjcj/UD0qA96xL7to00vEkkq4s5RsFga nnaLZiTZ1MSvw5UNJr2Yci4Fk3rpzjfYQBXxSvO9YzMLMGgwWDfen5+iGsw33gPvGMzeI5F7sMPp qbopOPT/T+ZuItDBIlIl2JVVLl2z2YAlZnHa0brBSJpJaQzZYNKLWc7NYMTOnXybiQQLND/Jgna0 2B2Dlbql/uy60Hqqd/LNsk0NDnFR6s9jjPeNVq72rSYvDcNmK7VsnjZap5uuZCpGrm4lBatiUkti SEWwZKQUs9P3bDHXriUyFRc2Khu5xp8mWOIcjLDSRvrBUGnKOsZK3+juVyUsToacOGa7UOUOCmLJ dt3SRdeFLlGN31wp2LRuyirbdYP9uUTe3n3pZ5W9PW1Pq/fnoOiVPrp+GA+aqKjMV/3KoqxgrQjB KOA3IxnbalsFMza13ax19LrdUjglHnRzZEtlP3ibDvpq1c3OsNlMpD42/Px21AdDdyRvrbhVc78V cjAvxptBUBSDAAQg8IvAqftCNCAEIACBpwhsP978z7+eQjPd73//73QXOIAABCYQYLw5Aeogk5/1 rCHPTAwKBzMQgMCgebrc2+ntPeOG/+N//u/zb1TTDTT1CWmsNc2RPZZRzY0dCAwkcHe8KQcV0oCC N/wlef3z3//syLykaH3WShLZba0jI6pAAALPErirm89Gj3cIQAAC6wmM2Rdyjz1LGm7I6c5OlE4R eAQ/94XsmFFHdnoxvfLD+7//6UaapYpSTMvbkaNzkTWYhiEpZOv+5qW1L8QTzuvvBzxCIEJgvG7+ Uo3f/+ZE6TxJWxr+86+PAFnJk+/Ti9lirqQl4sqLdNrylwzawtnwVEn/9pJb39AI22QizUsZCEBg AoFF83Q5EC1jzODSZzNZ2Saywzr9sWO1Ma2iAjdwzyceWMebPprEKAABCAwhsEg3RS7HasFHg/Sf sJAfB8qcjCLjYjekSTACAQhsTmCRbtqjtZf20CP4RCjdwDNSsV7GTb3vG8QCBCDwDgJ31zfT7Z3s ho/bFLLsGpP3ZF9IxpVOKO2PWkC96M6PXKk/mWQL13eWXBg65nVeKtHWlyxY4nzHPUYW7yNwVzen E/nic5Zjl4OntxQOIPA1BBbN07+G58hES2cKRvrAFgQgcJ3A9uPN6ylRAwIQgMBUAhvrpvkT51MR fHb659rHOgQg8C4Cj+pmXRmXydkmYbyrY5ENBF5MYJVuZrXpnjLKdvPUTecfxrONfy/yF/cnUoPA NxCYqZtGKz/nhEYdE5JWWSSaJV22HwNo6DfcKOQIAUNgwn76R1Pk30dQ9N/LoNvUNN+X5Ug6EIBA gcDQ8aaMwnLjr6mz6V0at5z+LhESBwQgMILAON2UAWZJnv9ai5Tf65w9e/7SHmMPzu71EfH0WXHr Qib4NsZsJE2wtY+BKoemZQpAAAL7E5gwTy8nLSJlpUoe7bbbO7ZMUDTVpsiZlV29ohedfZHRtFi9 5eKB7d8DiBACELhKYJxufjRRVvrKX+kwTV4ul446++b1qZzJFeuiMiKOFKvx1VXdq41AeQhA4CgC 43Tz56jvx7/CPombIAslHW/OG8HpWLI5hNRgrrWg2we7VpnSEIDAeQSG6uZfWugF9K/XFVfev+mG nKNktGPcmtV337CqlfaxgfNan4ghAIEeAuP2herT8+xvfz4dqQNPLXJH7HRiLoNZmaSnznVF1W0o aa2/q+SqD38ctafpqAMBCDxEYIVuFlPb5IDj9TA6lP2h9sUtBCAwnsCjuvl7On7syXs9xjc3FiEA gQEENtLNAdlgAgIQgMB8AhP2heYHjQcIQAACDxJANx+Ej2sIQOBIAujmkc1G0BCAwIMEVuvm3TM5 LVShpy8LRu7UbcXF7yEAgfcQWK2box5oL7VA0H7poc73NCyZQAAC0wis1s1piWAYAhCAwCIC655D skO8ytvb6sU+VNyJoMqBHzeozB4fchfdcNU9Uup8Bce2i1oSNxCAwCoCi3TTHrDR79OLwWICR1XM snInebIGpW6qepG61imnhlb1UvxAYC8CD8/TZZvIDuv0x+xozl18ZMT3iNO9eg3RQOC7CTysm+l7 5NyLh7+7dcgeAhDYkcDDuqlIZMjpBp4pMB4V2rETERMEvozAovVNq4lCOLshk90UcnpqFzezpkoX s3s+lc2i1G9pm+jL+gzpQuDbCazTzUdIs3XzCHacQuDdBHaZp8+g7Ob+M1xgEwIQ+EICLx9vfmGL kjIEIDCbwJvHm7PZYR8CEPhOAujmd7Y7WUMAAv0EttNNFiX7G5OaEIDAEgJ7rW/K9nd63tGi0D8m nD2307eB7h4wsu76DNbbLntCdGBzu9OlH8s7n3HKwq+0SDeoGU2ZBjMj8u6UmxVnRLuGczO1qQW2 G29ms5XbXm/+igr0CYQcUqq4juhgvJ36guyzP9tXPKpSySz8SotEPGbPRyxAIZKxwJGD0H0eZEa0 69OPdImxZfbSTaePkqpthm9okrENjLVHCNBRH8G+zOle8/RK2unk3U3YSzOO0hmk7AzLdveIQWek ebekwdRnqfZjw9XVyb6d9XdYy6Zcn9rHJ3fBfD/uspO70opNJWY38pKSzaa0xVy/KvVJZzPrN1s3 23AuyIq1oN94G6XwO3qRdJi0YilZm2+9sy2TwkuODtZNxW3vrqy8CpHmskvw1tWbVss3LacBSJVs 5JcuZvtcE0LcRf3TpZ546iXYUuq0VD5LvmI82wFKELL9ynFoBla/CVVNKpnaHnI13yaKq+nUA6j0 N9VH/WQqfXNJth4vvNc8/RKO5uBOPwPTbnrJkS0sYjfQoFgTg/LVdDFk4aLDr4YnN4ONuckz0lhN I2nMrmmaFiIFhoTadJR6qWfXNJhK4dU2uuoiXn4N0ng890serJvB5GXl+9JNXrc81qBYky8rnWNj TjO641fGF+tvhmzMwW6wf7Gx2Q23Jirseml6MchZBwfre1Ewwnqxl+umyuUoGRpuUJtHLTddDPwM kJGjxND0q8U6+vqkmG3nHutiyN3VZ2RsIkOsZT8p73x83qnbR3VsrTPWN+0t7e5w+6NFI/e2m/+W 2Lm+ldb9VKwbFAtNQUkdudQqMZcgWL/NRDTCuN8UWtZLlm3FSxqJWIjAt5xTF/ZjoGKt0pFsrVKb dgMs9cn0c0s+7PUj3+XiAnM9sITFNVO9w2TbqHKx2b01yOCNOVbsBlo7QzcHJowpCEDgKgGRbzfh yF4MWr5TN+hiajF0cypejEPgJQSyA9jgqDY4FzmIFLp5UGMRKgQgsAWBl+8LbcGYICAAgXcR2H+8 +feDje8i/2ML5HUZkRAEvoIA481jmlnWkoY8VnJMzgQKgS0JnKSbH90wx2ru4hxo6qec3Y2nXl+f R2k+6jQ3DqxDAAL/+MdJull401ujGUuK1metJJHd1uiEEIDAcQRO0s3j4A4MWIaZDDYHIsUUBLoJ nLEvZMeMOrLTi+mVnxLj586limJHy9uRo3Phhq5SMg1DGiNb93cvF040lRrYPj/c3QmoCAEIXCJw gG5+BMhKnqqVu5gtJvqVnUS78iKdtvwlg85LKebfveTfI3ep/SgMAQisJ3DwPF22ieywTn/sWG1M q6iMDtzzcV70rTDMwdd3fTxCoJvAwbr50SD9J/nLjwNlToaNHSocbw953xdPF8WJURICjxM4WDeV nQilG3jeJ1ua4N+3bCL/9fiSlc6PhiKjAyFjCgLDCRywvmk1UceVTihdGTdC1J0fqV5/MskWzm4E qQW3L2Rjq4SXrfVzsPz3+2bsj/UmZ19o+C2BQQg0CZyhm800ziww4Jwlunlm0xP12QTeME8/uwXu Rc8Tnff4URsCPQT2H2/2ZEUdCEAAAvMIMN6cxxbLEIDAOwmgm+9sV7KCAATmEUA3O9nytFAnOKpB 4HwCi9Y37/wdEoF838LYxmIjeyxPrEHgIAKLxptyKqabi4jUHQvdrqkIAQhAwBFYpJujuCOdo0hi BwIQ6CawaJ6uc20nfOns211J/5J9NlX39+ytl6DBq+sAzNO7+xwVIXA6gSd1M/3b86W/Rh8RKZVO WQwV6cwatH9zIv37E0FfjHxP7/rED4FuAg/P02VXOh0S9r3YItUyVc+mQRdJHShvMOrucFSEwAsI PKybsttj93yGbwEFDaaRvKB1SQECEJhB4GHd1JRkPBiZI1+i0GGwOTK9FACFIQCB9xFYtL5Z2t5J d2PSkvZKaVUxu/mjk/S02WSirdNtO+8OLlx2KPL7eg8ZQeA7CSzSzffBtdtQ78uOjCAAgQoBdJPu AQEIQOAagV3WN69FTWkIQAACzxFAN59jj2cIQOBMAujmme1G1BCAwHME0M3n2OMZAhA4kwC62dNu POPZQ406EHgLge108ylJuuQ3+IznWzoJeUAAAr8R2E43aR8IQAACmxPY6PnN7JkiexCoNCTU0V96 +qhEvzK6dNbsmaKPtdLBpPQx+NIxJw4abX5LEB4EmgQ20k2JNZUVe0W/Ty9mi2XzbxrUWqVDQc7C p7x7bV02zmZjUAACEDiCwAHzdB3xNUdqnwLyVUcvBkua6OpGljIjZY7oDQQJAQhECBygm5E0pEz8 XXBSsqmwcdep2oo0I6ndDKkIgW0JnKGb+vqiIMe6INo1yknSKYqJaAbbi2IQOIvAjgOi7Azajd2s 3l3dF8rWlaVVXanUH3UkK9+UdNa+s86NZJ16Mgg96w4hWgikBHbUzUyUyYR3c/VxG0dWOjePnJsE AhBoEthdN+2cWpPJXmymurjAEUEuZoI7CLyDwO66+Q7KZAEBCLyJwBn7Qm8iTi4QgMDpBNDN01uQ +CEAgdUE0M3VxPEHAQicTmBT3Ywc+7mJ/s6Tm3fq3gyb6hCAwOMENtXNBU+MR1zUn9Z8vPEIAAIQ eITAprr5CAucQgACEIgQ2O45pPhBoLRk6UrkXXAKy578cRc/P0aeJ9VzR8FXh0TaiTIQgMA+BPbS zewxm+DF0hGdknhVytuDm9npfLOudcoBoX26O5FAYAiBM+bpsk3khpN6JZU2dyWylDmEpjXyiNPh WWAQAhBICZyhm9kXxM1+FxzdBQIQgECWwBm6qaHrkNOuM6a73jwnRHeHAATmEdhrfdNuvEjObpcm fWWclrF1g8XURXYzSn7rlkedImfDc3tH7A7N675YhsAjBLbTzWco8GL2R7jjFAJnEjhsnj4DsowH mdrPYItNCLySAOPNVzYrSUEAAhMJMN6cCBfTEIDAKwmgm69sVpKCAAQmEjhYN1mXnNgvMA2BPQjs eZufqptyeDE9wjh1e8edWbL9aqrfPTrwb1GkJ7gGBlnhPNCLmup2922NPgN+3WbpNl8fifN4qm4+ Aq5ydDL91YtvKunNAw+SZp+KXdbE3YlEKsa7QbzkMjJNR8GYg8Wa7vYpcKpuSpfN/mny9zXSPt3F RRIRjm2DJ7D9CWRv8x3CftVzSG5Urwd1Iid23CGfT9tkq6cni0oVtXXd4aX6S+2yfq2L1J2db8pn SZpv1oJUtNpXMS6FKwPDIEDX6UsGtSlthM3wHApHo4LFliw1XD2StLfEB9EVCGkbZVWj2S0rnTnt MFnOzkUwu0sd5pIgSg+5VGVg4Sd9D0xD72q36GlvlQpo+yv3faos2bfMpcaz7tyte99vVob09Kf7 RoRPEdnv9VeWZKmB6snWAZZu+3TqoORdnC7U1GBKNdsNsvCzdbMtnobR9FLv8I5qqW8E801jLoUX 4VzpqBHxineY4ZowyeCp8/TKLe1+FWlX1Rf38ehEc0gb2HjifnVQ0PyYTfOteEll92M/hXAn8Qj/ rP20osQWCS8t2R3GpdzXeKmEVA8g+9urnB/P8VKLTCr8Ht0UQZGvyK2VSobUnQS6Pnab7Vfh1LNT gLPj6YMcDy9esi+Sd9eCXrN936ObzVQrBZqDuDvGR/mVz4MOReuo1fHBMwlR1mw8vHjJlfHP8zU2 36y1sS4URXAmMQ/dJcs99+ElB2sKa1tmB5s6Ua3Mu11vcHZUrWwxa1bTtLomhSt1P78N+hX7dQW0 ENRyNkiJSqzZIJ2FpmalyTbzrYy7tW4pkUh4Ckq+se2YdoMg/NRvpWLJS+QDr9RhmnUrEboOUOm0 6j3LuQTfxRxp37SNXHeNiEbHaCBiNljmJboZzPboYs92lKPRxYMHcpzVsyWfbSl089nWD3mPj7NC 5ihUIABnukaQALoZBEUxCEAAAr8IsC9EV4AABCBwjQC6eY0XpSEAAQgs0s2zHjKgW0AAAhCoEFik m80HKWgkCEAAAqcQWKSbp+AgTghAAAJNAuhmExEFIAABCPxGAN2kQ0AAAhC4RmCdbva9buNaNpSG AAQgMJ/AOt189lzUfJJ4gAAEvoXAOt38FqLkCQEIvJ0Auvn2FiY/CEBgNAF0czRR7EEAAm8nsEg3 J73r9O2tQ34QgMCOBHgf0o6tQkwQgMDOBBaNN3dGQGwQgAAELhHYabz5869KXPha/jfULsRGUQhA 4L0EHtLNrERe1cEhRt7btGQGAQhMIrBKN53GXZXIePbLHMVDmlwy+IexJkeBeQh8EYH5uilClgjl 1bu987hRwfubWriTzJsQkAsE1hKYti/0ESz591HM3Ojy6hs5r5b/hVG8azB/wd38uajNw1vbRfEG ge0ITNBNK5fz5uOXSIp6qoBeqkthCEAAAr8TGD1PlwFm7suOoWTwKBNMN2FP/xZr/Q/eiys1aH8s hfHxrTv3tmIzGA21FLNE4kaLdqTsckkNVuqWui7zdG5qCCwmMFQ3q6Kp8qH3uVUf1dC0mBBx6mB/ bNb1TH86dhP/dL01dSFhWJkWlcymFr+oBjXOuBTGSy7uWLiDwIsJTJint2hZwepctfzdhVWoj460 FwcLXt1lHYrWx4AinanstjD8/fs7EHiraZwzJSEwisADujkq9NTOR0T0a4gXGc01dU3KtPV6SEwY gQAEnibwgG4O15fUYMNFLILgFFiNIZ1Pd2b8Q2ARgaHrmz/X/5r7QnYrxq4VyvdWhoRBaZpcKdkY If4M0q1UKu/sNo5rDZdCWtfGnDWYWnAxxyf+QX1f1KFwA4EvIDBaN0U6f0rgjvRWxbZSy+IKu2OL EBMEDiQwQTf/GiX+orGDgOrhyyXBpAPhAzsGIUMAAkUC03RTPa4a4uVTfNY7HQ8CEHgjgfm66Yaf 8uO8cd/3vdfjjd2SnCCwNYFVuukgDHkF3BAjW7cOwUEAAjsSeEg3syh4b/GOPYSYIAABT2An3RzU OuwvDwKJGQhAIE/ggefeZzdF83jPJ4DYk++3Il3g4lZ8VIYABHoJvFA3e1FQDwIQgECIwEbz9Mrr M9wTkToTd1Py7CmdbF1lY98JIhfdFT3C5M4yVR7SrB9wcscx7cGhSjAS28rH6UPdh0IQ+EoCG+mm 6oKog2qEFQt7UTXOlbf6kq2bClClmFVSV7GuYtnfpkJvtVI1NL34lZ2TpCGwKYED5umqJpUBaYlu qW68NdxqqY4Wu4d+weXXj31WSOPNREkIrCRwgG7qKC+iOCk7Ebi+uitbwvqSgI8L+ylc+IXAYgIH 6Gb3yG7SgqBdQ5jdWgw5ZxPGPgQ6CGy0vml3e+xujMhfNje3qZKdyDd3acRyus+T3WXSwpEB7KVt K7FsM9IfNfc7HyEdnYMqEIBAlsBGunlKCz0oXg+6PqV1iBMCCwigmxcgV549umCFohCAwOEE0M3D G5DwIQCB5QQO2BdazgSHEIAABGoE0E36BwQgAIFrBNDNa7woDQEIQGBT3VxwWubOo5F36tLnIACB 0wlsqpuRpyNvoo+4qD83ejMAqkMAAocS2FQ3D6VJ2BCAwDcQ2O45pOwpneyDk2nJ0pXS6SN3OEfa u3Lx89t6JNnzS5GB7Td0NXKEwGsI7KWb9jyMfh+8mC2mSpeKV6V88zVuzbr2hCWHfF5zt5AIBITA GfN02SZyw0m9kmpi+vK39e3NMHM9czxCYA2BM3Qz+141ucjW9pqOghcIQEAJnKGbGq6qpF1nTKUT MaWLQwAC8wjstb5pN14k59J71YLbR/Vi6iJbTH5rVyqD4bm9I2dhXltiGQIQWENgO91ck7bzwtbN I9hxCoFDCRw2T59BWcaDTO1nsMUmBF5JgPHmK5uVpCAAgYkEGG9OhItpCEDglQTQzVc2K0lBAAIT CRysm6xLTuwXmIbA7wS43SyPU3VTdsDdeUc9VqRtXNntGbIR5E4xRe61IX6to44YInE6F/LjAl/L vFyFcFz5gT0tvd2OozE24FN1M0tBHvbUA471k45DzkF2GOmoUm/y4QZTd0Gk3V3T3eH3MxooGd1J VSoODy9r8D7GGbm/w+apuukk0sql+/4d7UQWEHiQQHq7PRjMDq7f9hySe4Jd5xdWTN15Hp2BanvU P6jd4aKsC5lsikH7diV3xRZrlky7S/00lM0iLVm6Un/nXingbL6VwppLaaQZbziHJWtQLrrU0pib xayRbG9xjZ4avDSyzlpzfiv5pgOIZngdkuTuuA4LJ1Z5v25q78lKqopm891xpZJ6b8h9qAdDSwZt GNnvSwVSgUhdBA1WYkhvNptX6fug39Idkt57KdUglrSZ9IpLrRSz6zDx1JoG7adFcxId9+sapeSl Gd53KmCfap86T49n2+ygOoiw92rE/thVPzc8/ATjhhKRkOQWcnVlnFXKzvGJ4MpGctVvM500ktRF 04gtkM005ZwWq9CLBNCNNGL8fpnNw7uf4AwL79fNILVP79F5XLDKvGISjHxd9ZKtuyC7BX7vYClp fQTyAnpXW5nyzxJAN3/w15HdJensGw+W2jtr7Y4LrVvP7o6LkhjJ9T6qkfthSMzBaem8LCKZri/T PdFZH+qDHl+1vmm7uLtv9cdUGd2V5hAveyNJLTsXdsHYeKS9bRX9MVWcSudw8lEyaItpdvXw0mIa c9ZaStvlG6SaTUGppjE34TiDJc7OTlrLNlkltVIPdH5dV2l+lGabwyHN9r1S2BXOrkpTm4IfP007 ZxV4lW6ehZ5ozyXwlFg85bf++dT8UDy3oYsfaV+Y8/takYxWErg07B0Y2FN+B6bwGlOMN1/TlCQC AQgsIsC+0CLQuIEABF5DAN18TVOSCAQgsIgAujkMNA9wDEOJIQjsTQDdHNk+bLKNpIktCOxK4Et1 c8iD07u2KXFBAAJzCXypbs6FinUIQODVBLZ7Dil4uOXTKGnJyANu2TM2qbVSsUpn2PCZ5Fd3XZKD wGME9tJNKz36ffBitliJq9O4oAtE87F+imMI7ERg33m67rHoWVo3wNT9a3t69/6mdt/ezqUXguzU AYgFAhC4TGBf3bSpyHjQKVr6dq/h7xm7jJMKEIDAFxDYVzd1dJldN7RLmenm+J3t8jt1v6DDkCIE IPCPvdY37f6MHV2muzTx7aPKEufnV1ffq8YSJzcNBCCwnW7u0yRX98dFyvuWR/fJmkggAIEmAXQz jyjySFMTLgUgAIFXEkA3X9msJAUBCEwksO++0MSkMQ0BCEDgBgF08wY8qkIAAl9JAN38ymYnaQhA 4AYBdPMGPKpCAAJfSQDd/MpmJ2kIQOAGAXTzBjyqQgACX0kA3fzKZidpCEDgBgF08wY8qkIAAl9J AN38ymYnaQhA4AaB/we/hNxpQvf9/AAAAABJRU5ErkJgggA= --_005_F8D795413D494011ACDDC75E8850A169ciscocom_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=10553; creation-date="Wed, 28 Jun 2017 19:42:08 GMT"; modification-date="Wed, 28 Jun 2017 19:42:08 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAbUAAAFpCAIAAACUNCHeAAAAAXNSR0IArs4c6QAAKPJJREFUeF7t nc2SLamtRt03PLQH95n82n4njzxu7y5O6agkIAVJ/gCroqNjVxYIaUl8G/Lv/PHnn3/+jR8IQAAC EHAE/g8mEIAABCCQJYA+UhgQgAAE8gTQRyoDAhCAAPpIDUAAAhBoIcD6sYUWbSEAgZ0IoI87ZZtY IQCBFgLoYwst2kIAAjsRQB93yjaxQgACLQTQxxZatIUABHYigD7ulG1ihQAEWgigjy20aAsBCOxE AH3cKdvECgEItBBAH1tovbjtH18/L3YQ1yAwHwH00eZsXpXhVUzzzT88fjeBXfQxrnpXq0zck3dX Dt5BYH0Cu+jj+pkkQghAYDSBP65eLg10WK+8kttyRP/6+ZyOmzbJE4nX9PXW5Igx2NRSh29Wjpq8 Ca3SssTz02WiVA6sCkxB4DoC00wqPf/TZ39EK1r6rNXQ6FHkT1mDJbNalCsJ80JWCqTkoTeOOF43 Q7C8M4Ep99f1hVJkGSVLy8jZQG8wXSz2fSND16utz4KscHcuZWKHwHACU+rjEAppzdWtR6lvX/ch /mMEAhC4msCU+hhZ9NXBjdqQnvfE+Dnc4NUFhH0ILExgmvOPlasinz/VL9ek/Jnzg/4aSOVI9vqP jKt90wdLdePPVFYuFkUMJgdYzC48UQntEQJMqkewHw/aqnfBq0PHA9MCAhD4JoA+vrEW/HLyjV7i EwRWJ4A+rp5h4oMABHoJTHl9pjdY+kEAAhBoIIA+NsCiKQQgsBUB9HGrdBMsBCDQQGBZfcw+39IA 5qjpmRsVz/Q98ou/QwACwwgsq49X3wwYtJ+VwmDfYUnGEAQg0EVgWX3sokEnCEAAAr8JLHh/j16y 6VfgpKD9kfpBue/afCj1kuP+aZzPn0o3NprjflBqFgIQuJ/AavqoHzuRz/5gsFnKR/bRFPN8S9Zg 6pt9/c/hy9b0oK3P0txfRowIgSUJ7LK/Tpdr9DJNfs2eDTQHHzlj+MigS1Y5QUGgj8Au+iivIxPR SUe4lNxXN/SCwA4EdtFHyWUSRLOQ9JlGN3eofmKEQJ3AaucftfalyCuvPtMN9KlG6WWsGVNZ+7qv tlnpa/S69CvbbSYzBG4msKA+3kxQRBD9eoQ8g0LgOgLb7a+vQGn27FcMgU0IQOB+Aqwf72fOiBCA wBwEWD/OkSe8hAAE7ieAPt7PnBEhAIE5COyrj5w0nKNC8RICzxHY9PxjemLPPyOoEyF3j2cvTL// mb97PMw+fDmwns2Dmx/Ll94ncDIcc9ts6WH/UrOB3DA1hMC+68csvlTQ+hmbEuVLZ2lp0Ka71u/x 8OpRtP2LxtJUzw9hSuiTyiTx6SdlVtpEHuJqSvoQUWgy8nL3mmLxjTfVR1/EZmFyfp6cTAzdZyTg 1dys4qmrudK66f66kiS/6TYbbf1sorYTXIZkmxmbssszH2Q4Pc28P4fWxE6pb/3cQuoeCeSwmXwt VULOBmu+zyoQTMtSyrQn2fBLefe1ZM4JHJ6fKZ0Jqe/W62Xpefqke88jdSXjmu5LSj/6aIske1Iy 5b5S95EpUbKQ7atPhEkDP5HiLpn5XwlHD136Iin5LJMkNQg204Jrpln260ral/ISTIex493Iki/J mRYgwyGrodlvu7raGo3LjqJ9jiT9ZI4OaZRKaIrjm+6vm3IT+WJMWhBRluCsqKx6tPMiEGatUV8a 6GkmbnuzTZREXLTBQyyGbQR11qs0qEA4HLceWmnFl2XVQSl1SScfu0PWHUtl4I2fJBMsy24mb+uI Pg7LSKr1Q50aNt63ofQF3jfNZIr2dc+qsJn292DxgQwfdzirsZUQL4PhZMYG8ipr6OOYdJiVS8To ECUdtbsZ4oyOOhk8xPLUuJEEldo0+Wy+Mpv6xp2Ml8FhRuKD7tCS848/sqyrx0xv/avfiuq6r6/F zBCyLZU9V2lc2UOZPY6ZcpU1rLfgnekI5NBz3SAbr2Gr/RTU/qDmXEpccD+Yumt0EVZZgejI76HQ iHuGno6upLwmEJ/fUsbjtWHcOwxnogbo40TJwlUIjCcQX3uOH/v1Ftlfvz5FOAiBywiY0yCXjTOr YdaPs2YOvyEAgasJsH68mjD2IQCBWQmgj7NmDr8hAIGrCaCPVxMeaZ+zRSNpYgsCRwTQxyNCLX+/ 6O625EK6zsjVxpaE0BYCpwigjz346vea9VikDwQg8D4C6OP7clLwKN3oO+pBwGnCxlEIPEeA+3t+ sK88hpG0yT+sIpvf9MHol3+cS4xkH//oU0A23c/NIEZemQD6+Du7WmXk8+FBXR1Gp3xf/SRWfYiV i47YIDAJAfbXdyfKb5DTinLhh1jvRsx4EBhEAH0cBPKcGV45dY4fvSFwCQH08RKsTUb9OcpPd1lR NpmiMQQgMJAA5x9/wOx+p1Pkuk324o+55iO776btNtdnBk4JTEFACKCPB8UwhfRM4SSzDgLTEUAf aynzy8npEozDEIBANwH0sRsdHSEAgcUJcH1m8QQTHgQg0E0AfexGR0cIQGBxAujj4gkmPAhAoJvA 1ucfufzSXTd0hMAOBPZdP6Z7Yngdzg5VTowQ6COwrz4KLySyr3ToBYHlCay2v5bHTszzJ9ln+FJ2 K//M/OevWYP1J2HqLy5jU7/8pCLAZQispo9a0SRJwXeUZZt5gyVrIrWVF5eVhlimnggEAisRWHN/ 7bfM6XUP5ilpn8hSM//WW2+tvk/XD1ZHPFmpyIgFApMSWFMffTLSpZjDCzJjm2VrIjjEpPWE2xBY icAu+qj32pH8Ha40k5Fgs2zLeN+Iw7SBAASGE1jt/KMWncqFl2Azo2vm5WP6hGNKTGqgLw35qzFc nxlexBiEwEUEVtPHizBhFgIQ2JDAdvvrDXNMyBCAQB8B9LGPG70gAIH1CaCP6+eYCCEAgT4C6GMf N3pBAALrE9hXH9N1ZG6yWb/GiRACPwnE5/6m16/Tc34/n/b7j2b455///6WePw5+jvjj6UjlR4x8 WhqD0le3SaZKLSOlbkT/5hdwaKoRb3WbM32DY0Xuryrd/nU4RMT4oRFpoK2NtRz34Z0tSxVuEpdt 5ud+JcZ9148GSpKqz//Tf0mezEFRLml2WD0fO6mxtJS+WhzNuKmxdDyUYO9G0sSblfHb7b+G7vu5 2uE0N+qjSJsOZw6NN2HxDnS41DTiRI19hfvESZuUl47N4qb62CcfSTeN2FVKSjdu1bjW9toNPYuY UdkEBbEEm00kK2u46ivc7DwqiWua+5vqY6lKPoqW/vPy5PfawVJLBtWm6dcQekWZGmTH1aN8iqDj O/DL8q+OxkL6VWweNkstpVfd2vdy+3dzBcEeNJ6YvvpXHU71yykUWnbpbSBr37LEDvNSj64jp96g TkqFs05fazOT+lb4pngqngRTHJyA8WY+EejjD3qyof6pSj8ELo5bJE+fecxupVNLb/lQMYPOyIOP egP4qYb0q2w9TDMpaGmWhtPfwHrb4neXegg9G43BZNN85wfdyxLI9hW3D1eFKSiZLSZeIZCNLpdE yznNfwm57k9yRrfx0cU5V/pKXNo9nd/ueLMAvScebLC8683kmyOSd2MKfbRss1dRune7pmPWjpyj 9EMb57yINBWQqQ9RQ/O16ZuJWBxWmHfY99Xq02pQz+Gm2Fsb66+NNKj+tpDviW4yrf6Y9mb9mEVa Opjk73DR6peoJxOX/ebIetJRFRWe/ss4Dh99jLLqlkg9QPcmPeplYzu9ijmssMMZlbVghEaURS9M Gr1+UfNsdBH/RGv6tEDmvHSPczZJL3nih0jfE32JK33BnBGvCOeTbdDHDMDKOs786Wa9i3ztxwvC 7NpKHfU2s1Uis33PGIxH192yFGOa4VrOzgQS/GY6jEJWtXpJmz6X4BtFPvRE7JyJtx5Ia115a0a1 zxv8xbDv6+swbdM1MHcg1m8/9LcrlsXl11nFyq2OX6Vsm32X+H/0ujVlPZIyXcp6qpjuFS0wvWT6 yXHRC/HKWDMlK27rZtmD4mQpitSrTsP0rUAwucu6J4qT1UfvsMZlpMqIVyWhGqzA1LFnx61zzqZV CJTUP+6zl2aNt/IFM2SIesEcipJfMWx6f/ghKRpAwOtm5JspyE1PxeBCPmi5tdl7PGn1fHh79DGP 9L///ds//pG5fDw8Ad0G//3vf/7rX3/v7k7HMwT8UvSMNel7kdkO397jSYfzl3Zh/XgpXoxDAAIT E+D6zMTJw3UIQOBSAujjpXgxDgEITEyA/fXtyfu6Bt3/83XpNvgTv94dNEgzCGxFYDV9PH+m+aSF X5JUKaIWgcuYqcirs/zshdGtJhLBLklgNX1MSerWBenYZsFr1iNS5dz4rFQH3pKy5AQgKAhUCKCP P+B0yuJPNcwaabM8qmZFMU8uWkf5gx0ITEVgF32sPE1hHkhI6astu75Fx6zODh8L0Y9AmDOD2U29 N1h5tCNbdb9FGaGcalri7EsIbKGP/gmB0jMDB6u89PZDpZ7Z/fjhQaO/WWfiPpcqKR9LEkqWky+Z f7jxbgK73N/zEYv0o5eH+shxmj59P7Ly9b6RdIpTr+aOu6sWfnFq3EsCKkOk9v5IfdD8e1a+Qvh4 3+QwjSGwJ4Fd9FFeo6Sf3k8HQ4lP4vj9k5Zm0b6BAbx7SRCNxvkjAdu5JkhkJzi67UVgF33U0pZW f93qdqbvYXHJmlQvddNnf+TQGg0gAIEzBPpl4syo1/U1e17/rid/JDnjV2o/nHTrR/3XyhWeyh5c C7TZ+Gs1TL5ljxxirEn5z4gOTdEAAhsSWE0fL0zhhIKSZDezUp4wlgszi2kIFAigjy2lscDF3wVC aMkYbSFwhgD62E5vxnsJZ/S5PTP0gMBYAujjCZ7vF533e3gCP10hcDUB9HEE4cDz1yOGObLxEjeO 3OTvEJiFAPp4TaZa3rLT5sF1ltv8oDUE1ieAPl6eY3uTzclnV37epv7xvvtGzssjZwAITE5gX328 9DbvIVUR8TDSpuLMye5DwsQIBF5LYLvnZ16bCRyDAATeRmDH9WP2GZvI03uVp3GyefWvw0jbYX/b dral2DTjmgdvIgY/pnTU/tUVZpPOuvJtExV/HiGwoz4m0F4C9BH57A9mmwX3sFoZK0NUPDQnHIMG Sz6jg4/MOgadhQD769+ZklXVoWp8GqSfjjRnL6cEDWZfGhS5PpNC8+vWDv/pAoF9CKCPPbnOvo6s x9B3n+EGvTPD3o12Jk76QmAqAujjj3SldVZkRSZb4LHprq9JuxetkbOrYwPBGgQWINCgBQtEa0LI 7jeNPprLGkYW60paEjv9vjLz7jJ/nUSfcDQOa9VLZ1SlcfZPyfn6EBJg/EtivcIgIgj8mghMA10K fvHYtJxcpqr2jHqZ9BHIKAJbrx+NMvrllVmFjYKOHQhAYAoC6OMUacJJCEDgAQJcn3kAOkNCAAJT EEAfp0gTTkIAAg8QQB8fgM6QEIDAFAR218fuOwrj2e17zCbZP9M37iEtIQCBLIHd9fGG25siQ9Tv lKR2IQCBRwjsro+PQGdQCEBgCgL73t8TfzDGtywdMa8aqzzE8ikO8+RMKpf6K9RKD8zw4okpJhtO TkdgU33Uz4fI5+DBbDM5V+h305X2Wg1L7/XJttE+a6mN7OWnq1EchsBTBNhf/yCfLteY5aEc8epj jjwiT48M+lS9Mi4E7iSAPv6gnX3PGG8Gu7MiGQsC7yGAPuZzIUtIfcrPX2Xm/pv3lDKeQGA4gU3P P8rpQgFaes9Y8DJOvZlce8k2S38111iM8mbdK12uGV4lGITAngT21cdH8q2v1TziAINCAAJxAuyv 46zOtkzLPbbkZznSHwJ3EWD9eBdpxoEABGYjwPpxtozhLwQgcBcB9PEu0owDAQjMRgB9PM4Y5w2P GdECAisS4PzjQVbTFWfzjKDuY5657igSc5vOIxbMoKOus58PrYNGvUs2NO/nKAJZZ8y9XANjzFq+ brhWz19YD/UQWD+2pviv9uluRHmw7+QTfun5nB4/vvqkmXzGgh96lLXhjnVTko6lB+QvfVQ0ezfr +ViCiRuVzZMOX1GoJ1067I4+HiAyUqhl0Xw+ZH11g5dMg6vDvM4+AK9jqy1PxJn9dWdJmP2XbMON aMY3FH5Dl930JXfN4zT6oI9Hb6/ks/+QOmYdNo/9ZA3Wu8uU0PYP4WTHza4EK6w8Lu9MlqqZxhEy Jfje52zBHAIRO5F4dTYNBHNSKB6ayUhp8hiDty2fOydzuRv62InU66MuQdEvPRXrX5tZwRXR8edA 45bTPPHtjcxp97LttZ2SwaxXh6FlcxAfwrcs+W9QaLzGh4jPlVHq1kS5dJ30WROdzea3lA6p1Upt xA1Wgo0H1TkPL+7G/noY4Kz8feoj/XQMY/rKXOqzlnVg+E4nEq8sXowGGQ9TMy3iFYaVcUfF6Ido 8tA7nz0TGqmW85Xgl8Zm3GxoJ+PtmAKPd0Efr03Bp6Tkp3Uk3zcJyqgJ3+pPpP2ZeLMKImJaH33s uKXvEp/KdGTUN1Y8irGVkB03G9rYeCMV9Wwb9PEm/memUOpbX23dFEZ4mHq8SVPqQi8WmgTIj3uG fGnjLxvz9KHJwwjCus+H6CJDdITWl5FuZ97QkfOPPVnQhZKUS+aJ/CqbIP2nelGalsasHig7LYNy Y3zQfvp5bqJIWmDUwccuzcw81x4eTnLdNzuosdZBzyD1wWbjPXSmkuVsVcg5BJ/xUnV6sFnU9WY+ kHpo2YzUS7qPVc+cvKYP+ngN10WtHopaMO5uO90dg47RDAKaAPtr6iFKQLb50Q65dpHrD/VF0/D9 8plw6Ls2AdaPa+eX6CAAgX4CrB/72dETAhBYmwD6uHZ+iQ4CEOgngD72s6MnBCCwNgHOPw7Ir9yf McDWoyaeDeSe0eP30Egqhjh2OG62wWGvw3rhiv8hokoD1o899Cq39fWYu6BP30Xe80/m9I37AZCm 8fAbrQ1aGaWOfHh+I+Om8I1j2YNN9XI+p03DVRp318YoBzrsoI8d0OgymIBe41wtkcn1p1TjqXEH J2wbc+yv21JdWlmkGe43YpH9kfQy3XXfyorGDFHxMCIN2UDqW78kN2fWXGYP6AOvPyqTTWEQi19g 6iP68Y++/MYTl8bNbof9wSwikzuftcNKq3xz+EB0uZZK93xttM3P0a3Rxx6ipXqVp8fMh1Ldy9hZ YfWTM01R+b8xq73yimOslcI2Ra/H0sOVxspO70PEWW+9J5V4vcxl4w26d0V+zcqxCeBhNnVVVBon gCKClVoqfeWYCsxG0RTaYW0824D99TD+2a3Tp1bSz+Ewvnu876HxNDG6PfH20zzRky3iQ2ubk0hb h6u3f5UzZ0K7eo9/T22cIRDviz7GWfW0TOfX009r/zN9s4rW7UnW82QtIv2tgR/q1NhAzrg3Nkdn POnuK3LWUaKlQZ+qjW4IpY7o43CkeYNndORMX+/NEGtipC6R8RWrGPR721KGhgQyKv3POmO2vU1B JeADxTFYG01OPtWY84+d5M15nGQlFVnlT9nB9NTSZerrTE8DM5z8KkOYza+2dqg4JhDft+RzNvzg 3BuIVNzQWCo+l75FNIdL86sd9rUk7gnJbEakPFJ7I9n6m8zE5e1XgCQ9lWRVRjmsyc65d2M39PFG 2AwFgfcR0Av2+OL9fXFc4hH6eAlWjEJgIgKRvcVE4Qx0FX0cCBNTEIDAUgS4PrNUOgkGAhAYSAB9 HAgTUxCAwFIE0Mel0kkwEIDAQALoYxvM4A19bUZPt87efJdc1X9qukfvkUibPPTYznT38T5C4HQt WAPnmZyxMDycmw2ij23Ag7fytRk93dp7lW7UMMebnG9qfDqCXwbODHpyGvuhzzgzCsh5O91RZEvo vD9zWUAf58pXs7fd06N5pEc7cOPeWPya5yYllAXI/T3NdVV6DCN4E5np7h8/EIe8QT90vc3HVPYJ kMoQnz+VRonME+1P+qyftaiwNoFksXjjYl/CrDuZzVGFqgHoY4nkKIs0XnZZMhGqkdqoI5UMxr1d rCX62JxQ/dUqn7MHvel4X9+yMoRfPWXXU+ZgkzOiFHWN0w/AmTkcWeKVYqxzzv61G37FBwMhmKNg beTXL1/nSdKfdJhauA+/EnSDuM/xIZqn0Dwd2F8Py9Wn8tJPxWKSjODXcsVgZCkXCSzic5onkRFl EachRDpGXC21ichu6pt1r2loH4sBmM1vU9KNPyWfr6Ya+TpsQjdpY/RxWOKSiBxKSWpQl1GZzxGD ZwII+hwfIqnVdbNX0IksivpEkA53zwPM5jee9NKy906k8XQv3xJ9HJ/iykSVPwUlUjZWxsuIFjQF Vjd4uC4WP6+bxvVVeUSU4yvNJnQ6R9n8lg5Gknipzx1h7taF84/NGS9tHvU0qGwG5U8iJXGDfggz x2Q7ZkbJNvu0yfrsGwdPCGiDmoD2qiSgpUFlKa0NZlWjlb/ecRtv486YQbOprByMfJ2UZPSQarA2 St9tEZ7Nk2e2Dujj8xljjZDNwfJYHgnwkUGfn2O9HqCPveQG9eNbuiSO2ZXjIOoPm4mvx8c6SrG1 8kQfW4nRHgIQ2IUA12d2yTRxQgACrQTQx1ZitIcABHYhgD7ukmnijBNI5+ki99/EbdJyRgLo4+Cs fSaVn1fZg4MHftrcMjGmK7xc5326oF4xPvo4OA3ZO9oit7kN9uN2c+djZL12e9IY8IAA+kiJQOAH gST05+UerAsQ4P6eniQePnZSejZGbnwzd8AFDWafxAgG4IcoOeMNBu+bk52p1pdIaNknPUpuyKOZ WsL0KBVrwUBKSNl0B4ttmWboY3Mq9SSRz00HzfIk2DfbLOh9qa+R6ay1+Ljamj+LV2f1GTqiPn4I 01GPa3yIBxKkSrPlCbC/bk6xPPfafb7M790+ptKPeCOvpREx9UeaXc91ONxINsV7aC2FI8FG2huv fZe4h57zEIYYWZUA+tiT2bQS6ZjbpcGSNWMz/WpE0xzp8b69z0Xxdn/BZLfekYxkObfzoMcuBNDH 5kxHtoHNRr87iGTIBxFEfyRtLQeqzOH+ujsu3TEbyBnLHRnRnK8GeCY0+j5LgPOPPfzNjJL9nbaV PegbpCNaMsyRtCHVbeSIHIysZCNDlFhk4zWNjf30q17tipNmReylsxROaQgDJxlMQ4sDhqFxJgIw jRJs2VNV9HkfAfL9vpw0esSkbQTW3xzU/ezm7Ik+zpk3tepkRTNxCnH93QTQx3fnB+8gAIHnCHB9 5jn2jAwBCLybAPr47vzgHQQg8ByB1fTxhvtdnksWI0MAArcSWE0fuVhxa/kwGASWJrCaPi6dLIKD AARuJYA+3oqbwSAAgYkIoI8TJQtXIQCBWwksqI+PvMHh1qQxGAQgcAuBBfWRh8BuqRwGgcD6BBbU x/WTRoQQgMAtBNDHWzAzCAQgMCEB9HHCpOEyBCBwC4HV9JF3nd5SNgwCgS0I8P6eLdJMkBCAQAeB 1daPHQjoAgEIQCBLAH2kMCAAAQjkCaCPVAYEIAAB9HHOGuCNbXPmDa9XILDa9Rn/r/S1Zum8hdYR 6+15HGgsT6xBIE5gtf115B+Jr9BJYnTpSyS5AylenbSEwLMEVtPHUTQvlchRTmIHAhC4lMBq++sE y+9J/a45+4/NC+vDf6I+tdTNSkOU3icUlGD215dOAIxDoLahDM7SuSAaTdG/ps/+SElYfeDZvhWD XkbjzBHHuQoPbxcjsMv+Ol0F9mvGG84GxtXQ1xbvslxsvhHOXAR20cd01UVfe7nhUsxcpYC3EICA IbCLPkrYacHIvpWZAAEIHBJY7fqM2S/L3rZyfUautOi+lU1xqVl9CH8lJ7jvRsoPi5gGELiIwGr6 eBEmbfZmwUqyGxTTG8JnCAjsQwB9bMu1XyS29ac1BCAwDwH0cZ5c4SkEIHAvge2uz9yLl9EgAIGJ CaCPEycP1yEAgUsJoI+X4sU4BCAwMQH08fLk3fCIzuUxdA2gH1jqMkAnCDxMYF99vE22um/NucHD S4foDvzhOcHwEPgmsK8+UgMQgAAE6gR2vL8n+4yNvrGxtKqqPI2Tpexfh/FpJq+cqLwbrf4UkHcj jX5oUA9dGsIEInen69vUs5/rVOvuff6aHSgdZx2Kij1FYN/i8xNPH5HP/mC2WSV/pr0oRWWIZC3r oRcaLZfpcykQ09cP4b8YjJrXfU5/9f834ZQAatl9aj4wLgQ0AfbXv2mIFhyuWdKVh9Iys15h2dVQ 0KB+/1BHHR8uxPRbjvRYhx1bnSnFO3ygVsdoDwH08WwNaB05a+ur/3CDQ7y6zshu8V5HEsuXEmD9 +AOvbA+D0PuWkBXjdYPdi9ZgOPc3Gw7w/hAYcWEC+55/TGff0tpNJ9hsrvUE7r4+YwpIzhLK6DKK d0Z76B3OuiehefvZeP1Bcdg4ph3ISps+/5iNOh308VYCYdO9sAC9PLSt9dHnxp95PDwX+WyCX+7e eTjLB3geERauI4A+/mKbXcGVlnXX5aPJ8svda4qFxhB4IQH08YVJwSUIQOAVBLg+84o04AQEIPBC AujjC5OCSxCAwCsIoI+vSANOQAACLySw+/nH7C0+Pk99V0L6eqXRzd0z/iFC4yTXeV84u3BpdgK7 rx8j99Yl6Ym0NNWQ7RW/I9o/ZFLqG7c5e73iPwTuJLC7Pjax7pDIJvuHjUvPbj/u2KHnNIDAjAT2 3V9HHoypbHJTsktPwmjBkp1vyVq2boLPk2jj9QeBZqxOfIbAswQ2XT/KltkLWdrVynnJ1EDvlHVf f/qyspQTI8Hduuyv+7bPLCqfnVqMvgCBTfWxlLmPEqWfSmplzdgnW8Giiagb12SCMGkGgT4C6OMP bv6SSGnzG1wD9mXl0ysivmmdeyjo3T7QEQKbE0Af8wVQkadXrdpE0DevY8KHwBUEuD7zi6q+0iIX Xsw6Tva82Sst/mD98s7hDlq6+3H9pZgURva60BV1g00I7EBgX31cPruvWucuT5sAlySAPi6ZVoKC AAQGEOD84wCImIAABJYkgD4umVaCggAEBhBAHwdAxAQEILAkAfRxybQSFAQgMIDA7vp4w83VkTu9 S5k803dAdWACAnsT2F0fD29CPF8ekSFKOhjpe95DLEAAAlkCu+sjZQEBCECguIHbdoWSfYGYf2Tl A863LB3RL/7RHc3DOSkZlYO+b+pi3JO3B8kHCh0CEBhIYNP7w/WzJfI5eDDbTMTLf99U2usHB7Nf VId9tTLywMzAiYEpCHwIsL/+UQb+dTjyjhxZ8ekORtQeWYw/MiiTBwI7EEAff2Q5+36zdJBLyTvM B2KEgCaAPubrQdRQn/LzEoloMp0gsDCBTc8/6msdKbt97zfLvvGs8hq07EWh5IC5xlJ/hVrWW67S LDxRCe0RAvvq4zO4v/6p2EeGZlAIQKCVAPvrVmL97dP6ji15P0F6QuBeAixn7uXNaBCAwDwEWD/O kys8hQAE7iWAPt7Lm9EgAIF5CKCPx7nivOExI1pAYEUCnH88yGp6aM8856f7mGeuvbm+x/6yT4I3 VeB5C03DSWMfb9aTPiwRl9a+z+md0b3Tq0i11NuwfuxhmO7RkTt16rfs9N3Qkx7a6XHuq09SnzMW uoc2g5Y8Getb5cbS7kD6Ol59f8JYbn0x+l4Rr64mMyoWbQd9PKBqpFDLovl8RXrO24wU7vlRIhbe 40nEW9pA4K91BlXbVwdmeyjbcC2apX2ljHgI34+S+uqOZpTsgzelGM2yq9Q3GEjQk9LG3x+PrAqz PmfTkZbVHqCGU6FXcq/0bH4lubIb9R/ESW82+LCWaVY//6P3xWaPnIU/MEeRdPTNzYG90MdOmFnl ksf+jH7pks1+ruhXva92o/S5ybg3kjVbGSv7zeF9qDQTdYuziqQjyKcpXqMpac4ffu1pEZQulXEN kGCOzCgny8CENiRH8fx2ztLT3dhfn0b4bSAyK9KXuZ9UQSdSX//Fbg4GrcWd8ePqISKBR1wyo8Td yxrPelUPJOKkb9MdfnfHrJ+l0PpGKcG/AmAf9nt6oY/3cP49yqfySjuyQ1dS3/QjjdM3efc0iDiT HffQ29YGfpQzrEqi6QG2+vnO9sNzlIU/fJR3whSv0MdbEyRLv4gqVTwTO8HdXGnFkY7HndFLVy3Q YyGmUUaxqsc+1vM3WMvmqNWxQ/hDRmn16v72oXMl97v18hF19ZiZLL960TFH6is+U3+psRk3UfIt /Qb8UCPEmWzf+rjZvl52K81MICbYZOqwJOSsRTY7FYDGcomeh1BvWfG55GFWdFLZSPGUqijunicZ L6H6KIeZkhxlM36Y4vsboI/3M3/1iGcWpK8OLOwcBMKo1m/I/nr9HMcjNBvbeMdlWkJgmVQOCYT1 4xCMGIEABBYkwPpxwaQSEgQgMIQA+jgEI0YgAIEFCaCPCyaVkCBwEYHdzs+ij/2F9KmV+l1gqYFv U+/V7xA9vwgc5gVOfQTkNqPI7VZ9Q7ytF/rYn5HDKik91nLYsd+nmXue+doo3Yr4Eh5nQntJCHu6 gT7umXeihkAzgfS9vtW3O/f3NFdJ2sFJN/9YiCkgfb9x5fED/VxE9mEPefbAPIRgAvDPQqQGfujD QGQydPStP5BzxudIX9kJmvmcDSRrUD+vkgUY5FxqVsqIL8dIsfna0JGaqLO/+njjE0NXeLzXFC3R x+Y0Gb0TLdOKoCXSV485EjdYV0aJRJ8n8ueMZLjguPVm2b+myS8Pxom+HD5SWeJ2OAM9Ui3uhzkq SaRBagIJchYaepQSN++Jr6tSRvyXQXff5lmxaAf218MS+6na9DPKYtZg9+7GW0v6ZTTXHxRxiYRm RskOMYpP3U4WVDxHvnu8bzDAiMESwDO1caZvMLRlmqGPw1KZrsaknyajsrUxi6Bug9nRs9bSQSN8 /mByTMcl89YE60fJDtHEZ2DjM0jP9I1nxLes5KhebPfU1cDsvNAU+jg+KZF1VtOoYw2KNfmgJdIf NKqt95iVb4JkJztEU+wXNT6D9EzfbDgVg4cAzzhTH/eM5Yuydr9Zzj/2MPcLLqMFIiLaenalJg28 DOm5oe1/Ph8KUxpLRtRDS18dRfxgGj3b10MoNStBT+29M5V4NUDjW+qlbRqkh2qlx82mI8JZF0PF 4HlnkgXDqq+uTCLqkyT7Ddozr97XB318X05m8EhPiYWnxwypeN7HhQsAfXy+vCb1ILIWmzQ03IbA r1V/ZOcCLAhAAAIbEuD6zIZJJ2QIQCBEAH0MYaIRBCCwIYHV9PFzUoz7EjasY0KGwBUEVtNHTqde USXYhMCeBFbTxz2zSNQQgMAVBNDHK6hiEwIQWIEA+rhCFokBAhC4gsCC+ugf47sCHDYhAIHlCSyo jws/7bR8ORIgBF5FYEF9fBVfnIEABOYlgD7Omzs8hwAEriWAPl7LF+sQgMC8BFbTRx6embcW8RwC byPA+83elhH8gQAE3kJgtfXjW7jiBwQgMD8B9HH+HBIBBCBwDQH08RquWIUABOYnMI0+8uKy+YuN CCAwGYFp9JEXl01WWbgLgfkJTKOP86MmAghAYDIC6ONkCcNdCEDgNgLo422oGQgCEJiMwEz6yIvL Jisu3IXA5ARm0kdeXDZ5seE+BCYjMJM+ToYWdyEAgckJoI+TJxD3IQCBywigj5ehxTAEIDA5gWn0 kReXTV5puA+B+QjwfrP5cobHEIDAPQSmWT/eg4NRIAABCAgB9JFigAAEIJAngD5SGRCAAAReqY+8 tYzChAAEXkvg4fUjby17bWXgGAQg8LA+kgAIQAACryWAPr42NTgGAQg8TAB9fDgBDA8BCLyWwPP6 yFvLXlscOAaBzQk8r4+8tWzzEiR8CLyWwPP6+Fo0OAYBCGxOAH3cvAAIHwIQKBJAHykOCEAAAnkC D+sjby2jMCEAgdcS4P1mr00NjkEAAg8TeHj9+HD0DA8BCECgTAB9pDogAAEIvPL8I2mBAAQg8FoC rB/7U8PL2frZ0RMCMxDYXR9PahzvZ5uhyPERAp0EdtdHBK6zcOgGgQ0I/A8/BnAiCWwZmgAAAABJ RU5ErkJgggA= --_005_F8D795413D494011ACDDC75E8850A169ciscocom_-- From nobody Fri Jun 30 05:49:41 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29184129687 for ; Fri, 30 Jun 2017 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqeQPRA6JuAK for ; Fri, 30 Jun 2017 05:49:37 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43F81293E1 for ; Fri, 30 Jun 2017 05:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4199; q=dns/txt; s=iport; t=1498826976; x=1500036576; h=to:cc:from:subject:message-id:date:mime-version; bh=I5OgBJ8h5bMMnS/gIDewF19db3iFbExLA9p8pPGiwY8=; b=B/VNI52ZdtzcwqycvHYzKDHH4efANIv8VINULlaayUIfWXCNkcifDT/o j/t6CcvSnZJUvlU2PDwQO6eSjvHtOY1wm+TcdfmTDhPtjxcXpLwV4noIk NhEDzywU8DJRKSXuV77uE4+fiGe5q0PJXPDRApiJV6PdGmJcpJsvMhdTQ c=; X-IronPort-AV: E=Sophos;i="5.40,286,1496102400"; d="scan'208,217";a="655782305" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jun 2017 12:49:34 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5UCnY7X020746; Fri, 30 Jun 2017 12:49:34 GMT To: NETMOD Working Group Cc: Henrik Levkowetz , "Carl Moberg (camoberg)" , "Miroslav Kovac -X (mirkovac - PANTHEON TECHNOLOGIES at Cisco)" From: Benoit Claise Message-ID: <640c0baa-aa94-d14f-08d8-47321608fb68@cisco.com> Date: Fri, 30 Jun 2017 14:49:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D1B065C5D73FDC425C0559E3" Content-Language: en-US Archived-At: Subject: [netmod] toolchains improvements: validators and xym updated X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 12:49:39 -0000 This is a multi-part message in MIME format. --------------D1B065C5D73FDC425C0559E3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Regarding the different toolchains... _On claise.be_ Now uses pyang 1.7.3, yangdump-pro 16.10-9, yanglint 0.12.186, and confd-6.4 Xym has been updated with a new ""--force-revision" flag. It will reports errors such as discrepancies in revision dates (CODE BEGINS and YANG revision), badly formatted date (CODE BEGINS), discrepancies in module names (CODE BEGINS and YANG module), missing the ".yang" suffix (CODE BEGINS), etc. Believe me, I've seen them all. Example: $ xym --force-revision-regex draft-fan-yang-mac-00.txt Extracting 'ietf-mac@2016-12-23.yang' ERROR: 'draft-fan-yang-mac-00.txt', ietf-mac model revision 2016-12-23 is wrong or has incorrect format Created the following models: ietf-mac@2016-12-30.yang $ xym --force-revision-regex draft-ietf-softwire-dslite-yang-02.txt Extracting 'ietf-dslite@2017-01-03' ERROR: 'draft-ietf-softwire-dslite-yang-02.txt', ietf-dslite is missing .yang suffix Created the following models: ietf-dslite@2017-01-03.yang There a xym pip installable package for version 0.4 _On datatracker:_ In discussion with Henrik to update the different tools. Currently: xym 0.3.2, pyang 1.7.2, yanglint 0.12.183 _On yangvalidator.org_: In discussion with Carl Moberg to update the different tools. Currently: xym version: 0.3.1, pyang version: 1.7.1 confdc version: 6.2.1, yanglint version: yanglint 0.12.140 Regards, Benoit --------------D1B065C5D73FDC425C0559E3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

Regarding the different toolchains...

On claise.be
Now uses pyang 1.7.3, yangdump-pro 16.10-9, yanglint 0.12.186, and confd-6.4
Xym has been updated with a new ""--force-revision" flag.
It will reports errors such as discrepancies in revision dates (CODE BEGINS and YANG revision), badly formatted date (CODE BEGINS), discrepancies in module names (CODE BEGINS and YANG module), missing the ".yang" suffix (CODE BEGINS), etc. Believe me, I've seen them all.
Example:
$ xym --force-revision-regex draft-fan-yang-mac-00.txt

Extracting 'ietf-mac@2016-12-23.yang'
   ERROR: 'draft-fan-yang-mac-00.txt', ietf-mac model revision 2016-12-23 is wrong or has incorrect format
Created the following models:
ietf-mac@2016-12-30.yang

$ xym --force-revision-regex draft-ietf-softwire-dslite-yang-02.txt

Extracting 'ietf-dslite@2017-01-03'
   ERROR: 'draft-ietf-softwire-dslite-yang-02.txt', ietf-dslite is missing .yang suffix
Created the following models:
ietf-dslite@2017-01-03.yang
There a xym pip installable package for version 0.4

On datatracker:
In discussion with Henrik to update the different tools.
Currently: xym 0.3.2, pyang 1.7.2, yanglint 0.12.183

On yangvalidator.org:
In discussion with Carl Moberg to update the different tools.
Currently: xym version: 0.3.1, pyang version: 1.7.1 confdc version: 6.2.1, yanglint version: yanglint 0.12.140

Regards, Benoit




--------------D1B065C5D73FDC425C0559E3-- From nobody Fri Jun 30 13:37:37 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A08A1314F0; Fri, 30 Jun 2017 13:37:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149885504939.4706.4328975624258153859@ietfa.amsl.com> Date: Fri, 30 Jun 2017 13:37:29 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 20:37:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : YANG Tree Diagrams Authors : Martin Bjorklund Lou Berger Filename : draft-ietf-netmod-yang-tree-diagrams-01.txt Pages : 8 Date : 2017-06-30 Abstract: This document captures the current syntax used in YANG module Tree Diagrams. The purpose of the document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-01 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/