From nobody Mon May 2 03:38:19 2016 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 9EC4F12D0E8 for ; Mon, 2 May 2016 03:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.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 D2AQvWRrTVye for ; Mon, 2 May 2016 03:38:15 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD3C12B059 for ; Mon, 2 May 2016 03:38:15 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 27F1A603A8; Mon, 2 May 2016 12:38:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1462185494; bh=QDYQZsPQbRAtPTUIL9kfrULl3PoERYrsQqC2Ta8P6II=; h=to:date:subject:from; b=wOskBOq9MxM0DxJ2K33dT79DHj/KVe7acSroxUTcq7XkgoxkVtGJHJpLpGVlzzHsc ku6wU+uXr66qN0YEfO1Ztx0cVGFU8KcfM7dPugVS35MgUfBNDgP9AxTjx+91O2AqJ4 +KRGtyTQoj/1JfHylHLInjSaZgtcPNzoEwqvOJdc= content-type: text/plain; charset="utf-8" to: netmod@ietf.org User-Agent: SOGoMail 2.3.10 MIME-Version: 1.0 date: Mon, 02 May 2016 12:38:14 +0200 message-id: <40a0-57272e00-f-75acf380@267752981> X-Forward: 2001:67c:1220:80c:c959:efa2:3c5b:83c1 from: =?utf-8?q?Michal_Va=C5=A1ko?= content-transfer-encoding: quoted-printable Archived-At: Subject: [netmod] ietf-yang-library conformance-type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 10:38:17 -0000 Hi, during our ietf-yang-library module implementation, when we try to gene= rate proper data tree with the correct information about a NETCONF serv= er modules we encountered some problems. Based on the descriptions of implement and import enum values we implem= ented module loading in the following way: every module explicitly load= ed is implemented and every module imported from a different module is = only imported. Naturally, a first-imported and them explicitly-loaded m= odule can "upgrade" its conformance-type. We believed this to be the in= tended way of handling modules. However, this may cause problems with deviations, augments, leafrefs, a= nd possibly some other YANG statements. Most obvious inconsistency (if = I understood everything well) is with leafref. To refer to a node in an= other module you only need to import this other module. But then you ac= tually cannot see the data itself (they are "protocol-accessible object= s"), which would force us to always mark target modules of leafrefs as = implemented. Similar problem occurs with augments and deviations. If a module with e= ither of those is imported, the augments and deviation should not be ap= plied. But, for instance, we can have modules A, B, and C. C imports A = and B. B imports A and also augments it. Now it is reasonable for modul= e C to expect the augment to be applied in A, since it imports both, bu= t it will not be the case if they all are only imported. To solve this,= modules with augments or deviations and their target modules could be = required to be implemented. This could trigger recursive changes from i= mport to implement in many modules. My question is, was this intentional? Do I understand it correctly, wha= t is the proper behavior? Thanks for a clarification. Kind regards, Michal Vasko From nobody Mon May 2 03:49:39 2016 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 BB1A212D1D2 for ; Mon, 2 May 2016 03:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlU23VSCN31H for ; Mon, 2 May 2016 03:49:35 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2811B12D1D1 for ; Mon, 2 May 2016 03:49:35 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id BA79B1AE035C; Mon, 2 May 2016 12:49:33 +0200 (CEST) Date: Mon, 02 May 2016 12:49:33 +0200 (CEST) Message-Id: <20160502.124933.61564378527800012.mbj@tail-f.com> To: mvasko@cesnet.cz From: Martin Bjorklund In-Reply-To: <40a0-57272e00-f-75acf380@267752981> References: <40a0-57272e00-f-75acf380@267752981> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-library conformance-type X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 10:49:36 -0000 Hi, Michal Va=A8ko wrote: > Hi, > during our ietf-yang-library module implementation, when we try to > generate proper data tree with the correct information about a NETCON= F > server modules we encountered some problems. > = > Based on the descriptions of implement and import enum values we > implemented module loading in the following way: every module > explicitly loaded is implemented and every module imported from a > different module is only imported. Naturally, a first-imported and > them explicitly-loaded module can "upgrade" its conformance-type. We > believed this to be the intended way of handling modules. > = > However, this may cause problems with deviations, augments, leafrefs,= > and possibly some other YANG statements. Most obvious inconsistency > (if I understood everything well) is with leafref. To refer to a node= > in another module you only need to import this other module. But then= > you actually cannot see the data itself (they are "protocol-accessibl= e > objects"), which would force us to always mark target modules of > leafrefs as implemented. This is orthogonal to the usage of ietf-yang-library. If a server claims to implement a module with a leafref, the expected behavior is that it also implements the target of that leafref. > Similar problem occurs with augments and deviations. If a module with= > either of those is imported, the augments and deviation should not be= > applied. But, for instance, we can have modules A, B, and C. C import= s > A and B. B imports A and also augments it. Now it is reasonable for > module C to expect the augment to be applied in A, since it imports > both, but it will not be the case if they all are only imported. To > solve this, modules with augments or deviations and their target > modules could be required to be implemented. This could trigger > recursive changes from import to implement in many modules. It seems difficult to implement a module X that deviates Y without implementing Y... so if you want to phrase this as "implementing X that deviates Y implies that you must implement Y" I guess that's ok. > My question is, was this intentional? Do I understand it correctly, > what is the proper behavior? Thanks for a clarification. ietf-yang-library is supposed to simply report what the server implements. If the server implements a module Q with a leafref to W, but it doesn't implement W, then ietf-yang-library shouldn't report W. /martin From nobody Mon May 2 13:53:19 2016 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 64E3612D518 for ; Mon, 2 May 2016 13:53:18 -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, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbsIWmzyBtqs for ; Mon, 2 May 2016 13:53:16 -0700 (PDT) Received: from p02c11o148.mxlogic.net (p02c11o148.mxlogic.net [208.65.144.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E5912B074 for ; Mon, 2 May 2016 13:53:15 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c11o148.mxlogic.net(mxl_mta-8.5.0-10) over TLS secured channel with ESMTP id 93eb7275.0.385698.00-352.1087711.p02c11o148.mxlogic.net (envelope-from ); Mon, 02 May 2016 14:53:15 -0600 (MDT) X-MXL-Hash: 5727be3b2353cb00-e0ea5b9c5628bafec7ce6af9cb31349449a35a23 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0279.002; Mon, 2 May 2016 15:53:12 -0500 From: JOEY BOYD To: "netmod@ietf.org" Thread-Topic: Best Practice for Modeling Special Values Thread-Index: AdGktKMVFA7ri4PQSe+GYX3KdNfoZA== Date: Mon, 2 May 2016 20:53:11 +0000 Message-ID: <26CE489EF4611643B3EFE43D06E02654E836CB73@ex-mb1.corp.adtran.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.108.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=D8JBX6lj c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=pgp4GKyM2coA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=yrkiwgmsf1kA:10 a=pddWyfA] X-AnalysisOut: [AuOY7cbAtygsA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.5200000000; CM=0.500; MH=0.520(2016050215); S=0.278(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: Subject: [netmod] Best Practice for Modeling Special Values X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 20:53:18 -0000 I would like to get some guidance on best practice for modeling special val= ues. For certain technologies, the management specification notes special i= nteger values to represent certain conditions.=20 For example, an SNR margin could be defined as an unsigned 8-bit integer wh= ere the values of 0-30 represent the margin in dB and a special value, 255,= which represents the value is unavailable (a valid use case when the line = is not synchronized). In the past, we have defined MIB objects using the same type and special in= teger value as defined in the management specification. This means that use= rs of the MIB need to be aware of all special values defined and how they m= ap to what they represent. We duplicated this in our current YANG model as = well. leaf snr-margin { type uint8 { range "0..30 | 255"; } } Recently, I proposed in BBF to model these special values in a more explici= t manner as a union between an enumeration and an integer. Given the exampl= e above, you could have this. leaf snr-margin { type union { type enumeration { enum unavailable; } type uint8 { range "0..30"; } } } This allows for all special values to be mapped to explicit values instead = of numeric ones. This proposal was met with some opposition on the implemen= tation side of things as being more complex than necessary as the special i= nteger value is sufficient and requires no extra processing to parse a unio= n of string and integer. I now ask this working group what are your opinions on this with respect to= a best practice of modeling? Should we continue down the legacy path of mo= deling special integer values or would a better solution be to use a union = of an enumeration and integer to define these special values more explicitl= y at the expense of implementation complexity? Best regards, Joey =20 From nobody Tue May 3 01:54:24 2016 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 88F6B12D677; Tue, 3 May 2016 01:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o08JEk6GhU9f; Tue, 3 May 2016 01:54:18 -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 D030612D63D; Tue, 3 May 2016 01:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6986; q=dns/txt; s=iport; t=1462265657; x=1463475257; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=FeT48D9o3jvaBVxC1hQvzSWtPkFwKfMpIQKhwOfN920=; b=U7G3HcedDm8norEyPyz7EGgTIlNz71XAwVMBPiYdF+k6ra+y7ncl/i0F z46CtIYMG6t1WxPqsbleNoNsIzEp1g02gXnagy4Aqskg/qTR8mS/q495z Ow1SxLlK59pee/QTVBFj2Sfjq+ZSX+zi2KUKK51uS3zzUPORDlixZUgnb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBADAZihX/xbLJq1dhAt9vBIXDYUiS?= =?us-ascii?q?gKCCgEBAQEBAWYnhEEBAQEEAQEBNTYKAQwECxEBAwEBAQkWDwkDAgECARUiBgg?= =?us-ascii?q?GAQwGAgEBBYghDrpxAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhg0qBAoQnhW8BB?= =?us-ascii?q?JgUhXyIHIFoTocFI4U0h2WHTGKDbTowAQEBiDkBAQE?= X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208";a="635452832" 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; 03 May 2016 08:54:14 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u438sDgn001723; Tue, 3 May 2016 08:54:14 GMT To: "t.petch" , Martin Bjorklund References: <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> <5718D6F1.5040902@cisco.com> <20160421.155857.43464387853940362.mbj@tail-f.com> <00ab01d1a079$3812d3e0$4001a8c0@gateway.2wire.net> <5720AE83.4000508@cisco.com> From: Benoit Claise Message-ID: <57286735.2020003@cisco.com> Date: Tue, 3 May 2016 10:54:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5720AE83.4000508@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-i2rs-pub-sub-requirements.all@ietf.org, netmod@ietf.org Subject: Re: [netmod] datastores Re: AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 08:54:23 -0000 FYI. https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ballot/#benoit-claise Regards, Benoit > Tom, >> I see that the definition of 'datastores' has cropped up in this AD >> Review, as in the e-mail below. >> >> Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last >> Call and redefines, or recreates, the term for us >> >> A YANG datastore is a conceptual datastore that contains >> hierarchical >> data defined in YANG data models. It is what is referred in >> existing >> RFCs as "NETCONF datastore". However, as the same datastore is no >> longer tied to NETCONF as a specific transport, the term "YANG >> datastore" is deemed more appropriate. >> >> I think that the concept of datastore has been troublesome to those >> coming to YANG lately, such as openconfig and I2RS, and that this will >> just muddy the waters more, especially as it is tucked away in an >> Informational document. If I2RS want to define such terminology, then >> it should be in the I2RS Architecture or some such; but IMHO they should >> not be defining YANG datastores at all. > Agreed. > Timely review as draft-ietf-i2rs-pub-sub-requirements is on the next > IESG telechat. > > Regards, Benoit >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Martin Bjorklund" >> To: >> Cc: >> Sent: Thursday, April 21, 2016 2:58 PM >> Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) >> >> >>> Benoit Claise wrote: >>>> Hi Martin, >>>> >>>> Thanks for engaging quickly. >>>> [I removed the resolved entries] >>>>> Hi Benoit, >>>>> >>>>> Benoit Claise wrote: >>>>>> Dear all, >>>>>> >>>>>> Here is part 1 of my AD review. >>>>>> >>>>>> I found this useful: >>>>>> >> http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/ >> rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11. >> txt >>>>>> - Do we want to mention RESTCONF in the abstract? From the new >> charter: >>>>>> The NETMOD working group has defined the data modeling >> language >>>>>> YANG, which can be used to specify network management data >> models >>>>>> that are transported over such protocols as NETCONF and >> RESTCONF. >>>>>> OLD: >>>>>> >>>>>> YANG is a data modeling language used to model configuration >> data, >>>>>> state data, remote procedure calls, and notifications for >> network >>>>>> management protocols like the Network Configuration Protocol >>>>>> (NETCONF). >>>>>> >>>>>> NEW: >>>>>> >>>>>> YANG is a data modeling language used to model configuration >> data, >>>>>> state data, remote procedure calls, and notifications for >> network >>>>>> management protocols transported over such protocols as >> Network >>>>>> Configuration Protocol (NETCONF) and RESTCONF. This document >> specifies >>>>>> the YANG mappings to NETCONF. >>>>> The first paragraph in the introduction mentions other protocols; >>>>> RESCTONF and CoMI. My personal opinion is that this is >> sufficient, >>>>> but I'd like to hear what others think. >>>> The current abstract doesn't even mention the mapping to NETCONF. >>> See Juergen's proposal, I think that one is better. >>> >>>>>> - Section 1.1 >>>>>> Since this document introduces the NETCONF mapping, the protocol >>>>>> change must be included in section 1.1 >>>>>> Example: no NETCONF capability exchange in YANG 1.1, we use >>>>>> exclusively the YANG library >>>>>> Any other ones? >>>> And this one? >>> NEW: >>> >>> The following changes are done to the NETCONF mapping: >>> >>> o A server advertises support for YANG 1.1 modules by using ietf- >>> yang-library [I-D.ietf-netconf-yang-library] instead of listing >>> them as capabilities in the message. >>> >>>>>> - Terminology: >>>>>> The following terms are defined in [RFC6241 >>>>>> ]: >>>>>> >>>>>> ... >>>>>> >>>>>> o configuration datastore: a configuration datastore is an >>>>>> instantiated data tree with configuration data >>>>>> >>>>>> o datastore: an instantiated data tree >>>>>> >>>>>> RFC6241 has different definition for "configuration datastore" >> and >>>>>> "datastore". >>>>>> I would just provide the pointer to the RFC 6241 definitions. >>>>>> If you intend to provide an adapted definition for the YANG >> mappings, >>>>>> then you should say so. >>>>> How about: >>>>> >>>>> OLD: >>>>> >>>>> o configuration datastore: a configuration datastore is an >>>>> instantiated data tree with configuration data >>>>> >>>>> o datastore: an instantiated data tree >>>>> >>>>> NEW: >>>>> >>>>> o configuration datastore: When modelled with YANG, a >> configuration >>>>> datastore is an instantiated data tree with configuration >> data >>>>> o datastore: When modelled with YANG, an instantiated data >> tree >>>> This issue is with "The following terms are defined in [RFC6241]", >> but >>>> you re-define those terms. >>>> So give a warning about the redefinition to the readers. >>> Yes, that's what my proposed text does. It says that "datastore" is >>> defined in 6241, and when YANG is used, it means the instantiated data >>> tree. >>> >>>>>> - Section 4.1 >>>>>> >>>>>> YANG models can describe constraints to be enforced on the >> data, >>>>>> restricting the appearance or value of nodes based on the >> presence or >>>>>> value of other nodes in the hierarchy. >>>>>> >>>>>> I was looking for an example of appearance. >>>>>> NEW? >>>>>> YANG models can describe constraints to be enforced on the >> data, >>>>>> restricting the appearance (for example, with the "when" >> statement) >>>>>> or value of nodes based on the presence or value of other >> nodes in >>>>>> the hierarchy. >>>>> This is very early in the document, and the text tries to give a >> very >>>>> high level function overview. I am not sure that mentioning >> "when" at >>>>> this time actually helps a first time reader. >>>> The first time I read this, I was wondering how YANG data models can >>>> describe constraints on HOW data appear, while you wanted to express >>>> WHETHER a data appear. Maybe "when" is not the best way to help the >>>> first time user, but something is needed. >>> How about "restricting the presence or value of nodes"? >>> >>> >>> /martin >>> >>> _______________________________________________ >>> 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 May 3 03:30:19 2016 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 278CA12D71A for ; Tue, 3 May 2016 03:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS2LW3K5wHsT for ; Tue, 3 May 2016 03:30:16 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6386D12D719 for ; Tue, 3 May 2016 03:30:16 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 261251AE034E; Tue, 3 May 2016 12:30:15 +0200 (CEST) Date: Tue, 03 May 2016 12:30:32 +0200 (CEST) Message-Id: <20160503.123032.866615071112936335.mbj@tail-f.com> To: joey.boyd@adtran.com From: Martin Bjorklund In-Reply-To: <26CE489EF4611643B3EFE43D06E02654E836CB73@ex-mb1.corp.adtran.com> References: <26CE489EF4611643B3EFE43D06E02654E836CB73@ex-mb1.corp.adtran.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Best Practice for Modeling Special Values X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 10:30:18 -0000 Hi, JOEY BOYD wrote: > I would like to get some guidance on best practice for modeling > special values. For certain technologies, the management specification > notes special integer values to represent certain conditions. > > For example, an SNR margin could be defined as an unsigned 8-bit > integer where the values of 0-30 represent the margin in dB and a > special value, 255, which represents the value is unavailable (a valid > use case when the line is not synchronized). > > In the past, we have defined MIB objects using the same type and > special integer value as defined in the management specification. This > means that users of the MIB need to be aware of all special values > defined and how they map to what they represent. We duplicated this in > our current YANG model as well. > > leaf snr-margin { > type uint8 { > range "0..30 | 255"; > } > } > > Recently, I proposed in BBF to model these special values in a more > explicit manner as a union between an enumeration and an > integer. Given the example above, you could have this. > > leaf snr-margin { > type union { > type enumeration { > enum unavailable; > } > type uint8 { > range "0..30"; > } > } > } > > This allows for all special values to be mapped to explicit values > instead of numeric ones. This proposal was met with some opposition on > the implementation side of things as being more complex than necessary > as the special integer value is sufficient and requires no extra > processing to parse a union of string and integer. > > I now ask this working group what are your opinions on this with > respect to a best practice of modeling? Should we continue down the > legacy path of modeling special integer values or would a better > solution be to use a union of an enumeration and integer to define > these special values more explicitly at the expense of implementation > complexity? In general I prefer the explicit solution. I think it is easier for the end user who doesn't to have remember what the special values mean, especially if you have more than one special value: "snr-margin": 255 "snr-margin": 254 "snr-margin": "unavailable" "snr-margin": "auto" (whatever that is) On the implementation side, well, that's an implmenetation issue. I our code the difference is really marginal. It is always tricky if you design (standard) data models based on the implementation in one specific toolkit. /martin From nobody Tue May 3 05:30:40 2016 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 484FE12D792 for ; Tue, 3 May 2016 05:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 xTSNaqXzVhp9 for ; Tue, 3 May 2016 05:30:29 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FBC12D767 for ; Tue, 3 May 2016 05:21:10 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D6832147C8010; Tue, 3 May 2016 12:21:05 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u43CL8cK001768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 May 2016 12:21:08 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u43CKpAV029577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 May 2016 14:21:07 +0200 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.182]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 3 May 2016 14:21:01 +0200 From: "Guballa, Jens (Nokia - DE)" To: EXT Martin Bjorklund , "joey.boyd@adtran.com" Thread-Topic: [netmod] Best Practice for Modeling Special Values Thread-Index: AQHRpSbQWjcrW77D102fpcgcr5WVKJ+nH2vw Date: Tue, 3 May 2016 12:21:02 +0000 Message-ID: <547EE95EB794FD4DB8062F7A4C86D0BC4A443D99@FR712WXCHMBA13.zeu.alcatel-lucent.com> References: <26CE489EF4611643B3EFE43D06E02654E836CB73@ex-mb1.corp.adtran.com> <20160503.123032.866615071112936335.mbj@tail-f.com> In-Reply-To: <20160503.123032.866615071112936335.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0366_01D1A547.045A1A90" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Best Practice for Modeling Special Values X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:30:39 -0000 ------=_NextPart_000_0366_01D1A547.045A1A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT Martin > Bjorklund > Sent: Dienstag, 3. Mai 2016 12:31 > To: joey.boyd@adtran.com > Cc: netmod@ietf.org > Subject: Re: [netmod] Best Practice for Modeling Special Values > > Hi, > > JOEY BOYD wrote: > > I would like to get some guidance on best practice for modeling > > special values. For certain technologies, the management specification > > notes special integer values to represent certain conditions. > > > > For example, an SNR margin could be defined as an unsigned 8-bit > > integer where the values of 0-30 represent the margin in dB and a > > special value, 255, which represents the value is unavailable (a valid > > use case when the line is not synchronized). > > > > In the past, we have defined MIB objects using the same type and > > special integer value as defined in the management specification. This > > means that users of the MIB need to be aware of all special values > > defined and how they map to what they represent. We duplicated this in > > our current YANG model as well. > > > > leaf snr-margin { > > type uint8 { > > range "0..30 | 255"; > > } > > } > > > > Recently, I proposed in BBF to model these special values in a more > > explicit manner as a union between an enumeration and an integer. > > Given the example above, you could have this. > > > > leaf snr-margin { > > type union { > > type enumeration { > > enum unavailable; > > } > > type uint8 { > > range "0..30"; > > } > > } > > } > > > > This allows for all special values to be mapped to explicit values > > instead of numeric ones. This proposal was met with some opposition on > > the implementation side of things as being more complex than necessary > > as the special integer value is sufficient and requires no extra > > processing to parse a union of string and integer. > > > > I now ask this working group what are your opinions on this with > > respect to a best practice of modeling? Should we continue down the > > legacy path of modeling special integer values or would a better > > solution be to use a union of an enumeration and integer to define > > these special values more explicitly at the expense of implementation > > complexity? > > In general I prefer the explicit solution. I think it is easier for the end user > who doesn't to have remember what the special values mean, especially if > you have more than one special value: > > "snr-margin": 255 > > "snr-margin": 254 > > "snr-margin": "unavailable" > > "snr-margin": "auto" (whatever that is) > > On the implementation side, well, that's an implmenetation issue. I our code > the difference is really marginal. It is always tricky if you design (standard) > data models based on the implementation in one specific toolkit. [JG] I agree. Using enumerations provides additional semantics. And if needed you can even add the value statement to the enum. IMO, implementation should follow the data model, not vice versa. Jens > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0366_01D1A547.045A1A90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/DCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYjCCBkqgAwIBAgIKE1mSVAAAAADt+zANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDI0MDYyNDM5WhcNMTcwNDIz MDYyNDM5WjBCMRAwDgYDVQQDEwdsdnBzYWFlMS4wLAYJKoZIhvcNAQkBFh9qZW5zLmd1YmFsbGFA YWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuZZTGrNK 9hSyYEI9w2lnABbWQBeU1DyJ9jX33JSOfgMGYaQ0ZZZFRwX5vDIgj499CxaWmpImbQTxdYa/vxpS U7SfqtYF7B2AB2irUYdCu/GGjTqHaXmPyyktPaiEOgR7AOz8oXxUdaECsKmTBANOpkE1J6yA3KPJ Yxde3h5bTqnjxvJB5IJhr9rIvcf5V3v6ZyW0MHOkDXn20xjEDJVMVdhhjlnwM4WmUiA/SNq7IiQ8 elmivF5NuEK9mwZEXqkR6aXHVcgPc1fuMxwsxJbdfdmMyIDV62kSTVlb/iXNJDByQJ/GRnuYHCFA qIld1HgdJCpECl+ohveGLG46CvD6iwIDAQABo4IEFDCCBBAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmBC/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYB BAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0PBAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGC NwoDBDAKBggrBgEFBQcDBDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG 9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFPUv0vuw2MQvQ81rxR/PDOlK po4KMB8GA1UdIwQYMBaAFNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFM oIIBSKCCAUSGgdlsZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUy MENBLENOPXVzbmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDovL3Nl cnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFhBggrBgEF BQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUy MEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NBQ2Vy dGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDgGCCsGAQUF BzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNydDBEBggrBgEF BQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJD QS5jcnQwKgYDVR0RBCMwIYEfamVucy5ndWJhbGxhQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAXRHvujXQqqJMH1wCrG+0UrRv0v7CpjhIyuLwJ5XDhTj9JcKsYLpWREi/zXhN Sy6TC61uUKLrAuX0uXAXW0zsBYgPDFkq481gTgdxG/brcg8lXF8Xm787ixPR8Mp8j80ZHZ5OnA1k +Xuw/QPsE4wp8RZrjqvoJQpSXtXPdX3+XBE0VsANBYszCWfrR0ByI4hZ9Saoc26umYnOY8sU0UZ/ 1XnEcRfUmVWRxTydYAFdTtOHRjBn3V7TZnfeGYpKSxrqdh6nTqk0FR832p8Z8RyNjEv3qdaX9BK7 jsjQgGNH0gxWPf+wARDdk5abnalyChTjv8B70KeLOYbsrF0greiw3TGCBCkwggQlAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPy LGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVj ZW50IEludGVybmFsIFN1YiBDQQIKE1mSVAAAAADt+zAJBgUrDgMCGgUAoIICaTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDMxMjIxMDBaMCMGCSqGSIb3DQEJ BDEWBBSGmj/9tD1dhvYWceqf+/LtFjKITTCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKE1mSVAAAAADt+zCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJ k/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAy MRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBAgoTWZJUAAAAAO37MIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzAL BglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAHUb qB5n4sEGkZqQoUcSQWGcCZNmWT/2LUSRi8+JuTh3fy+ga0bl9252O/y57tJIqQN2uyzl6Qrk46Ji PAVSukq0kzp708h2U/kd1tmeEbKpbbUbkK7wIZG5uzKQ1jRSGxiiD1Efh5xqi9thT8h4XHOfqvaI XaN/U+yEvIOdnLNg2hFIFlR1K4cDXMbHj76TmmoDW3/J9WF+LfmfsltgqqCfOjyyHqfrS7eWTKEf KRE6qWWmf5L4ZFQ6o7r+ctl5svOjgyplemVYqEhuFOIDCn09Z7dSUAKJlLbnuYXi5IdRXyw0EUVl aU52r2DdIdUWpR/z7xwF7XZI9Xjzf6olOfIAAAAAAAA= ------=_NextPart_000_0366_01D1A547.045A1A90-- From nobody Tue May 3 07:07:43 2016 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 0A9DD12D50A; Tue, 3 May 2016 07:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 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, THIS_AD=1.695] 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 EVcnH_AXiJDj; Tue, 3 May 2016 07:07:39 -0700 (PDT) Received: from s12p02o145.mxlogic.net (s12p02o145.mxlogic.net [208.65.145.68]) (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 8EE2D12D50F; Tue, 3 May 2016 07:07:37 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO s12p02o145.mxlogic.net) by s12p02o145.mxlogic.net(mxl_mta-8.5.0-10) with ESMTP id ba0b8275.7fb74ebfd700.7853.00-546.24209.s12p02o145.mxlogic.net (envelope-from ); Tue, 03 May 2016 08:07:39 -0600 (MDT) X-MXL-Hash: 5728b0ab634ccfa8-de83dccc30b87a48d5bda8fa3c8ebca71767e136 Received: from unknown [76.164.174.81] by s12p02o145.mxlogic.net(mxl_mta-8.5.0-10) over TLS secured channel with SMTP id 6a0b8275.0.6516.00-207.24021.s12p02o145.mxlogic.net (envelope-from ); Tue, 03 May 2016 08:07:35 -0600 (MDT) X-MXL-Hash: 5728b0a7655e5a06-30e0b8f0b9d8e2da08fb52a3264564934d301d79 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0279.002; Tue, 3 May 2016 09:06:56 -0500 From: STUART VENTERS To: 'Benoit Claise' , t.petch , "Martin Bjorklund" Thread-Topic: [netmod] datastores Re: AD review draft-ietf-netmod-rfc6020bis-11 (part 1) Thread-Index: AQHRoHm6ClZ+EO6CSk2riAIAgKrEyp+eETGAgAk0Z4D///zCEA== Date: Tue, 3 May 2016 14:06:56 +0000 Message-ID: <1220E2C537595D439C5D026E83751866E7B61BD0@ex-mb1.corp.adtran.com> References: <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> <5718D6F1.5040902@cisco.com> <20160421.155857.43464387853940362.mbj@tail-f.com> <00ab01d1a079$3812d3e0$4001a8c0@gateway.2wire.net> <5720AE83.4000508@cisco.com> <57286735.2020003@cisco.com> In-Reply-To: <57286735.2020003@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.118.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=RbGWfgZv c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=0eaKXOXVzoQA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=yrkiwgmsf1kA:10 a=48vgC7m] X-AnalysisOut: [UAAAA:8 a=u07AKapRAAAA:8 a=AUd_NHdVAAAA:8 a=GPzER9YQlTqF-_] X-AnalysisOut: [qAS2kA:9 a=bZ10d6K8CULQ4_gT:21 a=mg4_OA7aDC2lBfhw:21 a=Cju] X-AnalysisOut: [IK1q_8ugA:10] X-Spam: [F=0.5100000000; CM=0.500; MH=0.510(2016050308); S=0.259(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: Cc: "draft-ietf-i2rs-pub-sub-requirements.all@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] datastores Re: AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:07:42 -0000 2cents: The Yang datastore definition with the conceptual data store is clear to th= ose who already know what is going on. To me, the shortened term 'Yang datastore' might be misleading because I do= n't think Yang necessarily provides or defines the format for a data store. Rather, it defines the format for an access portal to a data store. The data store may have other access methods which have little to do with Y= ang. Perhaps it would be clearer to use a term with less preloading. Instead of Yang or Netconf datastore, maybe Yang of Netconf data portal? -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Tuesday, May 03, 2016 3:54 AM To: t.petch; Martin Bjorklund Cc: draft-ietf-i2rs-pub-sub-requirements.all@ietf.org; netmod@ietf.org Subject: Re: [netmod] datastores Re: AD review draft-ietf-netmod-rfc6020bis= -11 (part 1) FYI. https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ballo= t/#benoit-claise Regards, Benoit > Tom, >> I see that the definition of 'datastores' has cropped up in this AD=20 >> Review, as in the e-mail below. >> >> Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF=20 >> Last Call and redefines, or recreates, the term for us >> >> A YANG datastore is a conceptual datastore that contains=20 >> hierarchical >> data defined in YANG data models. It is what is referred in=20 >> existing >> RFCs as "NETCONF datastore". However, as the same datastore is no >> longer tied to NETCONF as a specific transport, the term "YANG >> datastore" is deemed more appropriate. >> >> I think that the concept of datastore has been troublesome to those=20 >> coming to YANG lately, such as openconfig and I2RS, and that this=20 >> will just muddy the waters more, especially as it is tucked away in=20 >> an Informational document. If I2RS want to define such terminology,=20 >> then it should be in the I2RS Architecture or some such; but IMHO=20 >> they should not be defining YANG datastores at all. > Agreed. > Timely review as draft-ietf-i2rs-pub-sub-requirements is on the next=20 > IESG telechat. > > Regards, Benoit >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Martin Bjorklund" >> To: >> Cc: >> Sent: Thursday, April 21, 2016 2:58 PM >> Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part=20 >> 1) >> >> >>> Benoit Claise wrote: >>>> Hi Martin, >>>> >>>> Thanks for engaging quickly. >>>> [I removed the resolved entries] >>>>> Hi Benoit, >>>>> >>>>> Benoit Claise wrote: >>>>>> Dear all, >>>>>> >>>>>> Here is part 1 of my AD review. >>>>>> >>>>>> I found this useful: >>>>>> >> http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=3Dhttp://www.ietf.org/r >> fc/=20 >> rfc6020.txt&url2=3Dhttp://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-1= 1. >> txt >>>>>> - Do we want to mention RESTCONF in the abstract? From the new >> charter: >>>>>> The NETMOD working group has defined the data modeling >> language >>>>>> YANG, which can be used to specify network management data >> models >>>>>> that are transported over such protocols as NETCONF and >> RESTCONF. >>>>>> OLD: >>>>>> >>>>>> YANG is a data modeling language used to model configuration >> data, >>>>>> state data, remote procedure calls, and notifications for >> network >>>>>> management protocols like the Network Configuration Protocol >>>>>> (NETCONF). >>>>>> >>>>>> NEW: >>>>>> >>>>>> YANG is a data modeling language used to model configuration >> data, >>>>>> state data, remote procedure calls, and notifications for >> network >>>>>> management protocols transported over such protocols as >> Network >>>>>> Configuration Protocol (NETCONF) and RESTCONF. This document >> specifies >>>>>> the YANG mappings to NETCONF. >>>>> The first paragraph in the introduction mentions other protocols;=20 >>>>> RESCTONF and CoMI. My personal opinion is that this is >> sufficient, >>>>> but I'd like to hear what others think. >>>> The current abstract doesn't even mention the mapping to NETCONF. >>> See Juergen's proposal, I think that one is better. >>> >>>>>> - Section 1.1 >>>>>> Since this document introduces the NETCONF mapping, the protocol=20 >>>>>> change must be included in section 1.1 >>>>>> Example: no NETCONF capability exchange in YANG 1.1, we use=20 >>>>>> exclusively the YANG library Any other ones? >>>> And this one? >>> NEW: >>> >>> The following changes are done to the NETCONF mapping: >>> >>> o A server advertises support for YANG 1.1 modules by using ietf- >>> yang-library [I-D.ietf-netconf-yang-library] instead of listing >>> them as capabilities in the message. >>> >>>>>> - Terminology: >>>>>> The following terms are defined in [RFC6241 >>>>>> ]: >>>>>> >>>>>> ... >>>>>> >>>>>> o configuration datastore: a configuration datastore is an >>>>>> instantiated data tree with configuration data >>>>>> >>>>>> o datastore: an instantiated data tree >>>>>> >>>>>> RFC6241 has different definition for "configuration datastore" >> and >>>>>> "datastore". >>>>>> I would just provide the pointer to the RFC 6241 definitions. >>>>>> If you intend to provide an adapted definition for the YANG >> mappings, >>>>>> then you should say so. >>>>> How about: >>>>> >>>>> OLD: >>>>> >>>>> o configuration datastore: a configuration datastore is an >>>>> instantiated data tree with configuration data >>>>> >>>>> o datastore: an instantiated data tree >>>>> >>>>> NEW: >>>>> >>>>> o configuration datastore: When modelled with YANG, a >> configuration >>>>> datastore is an instantiated data tree with configuration >> data >>>>> o datastore: When modelled with YANG, an instantiated data >> tree >>>> This issue is with "The following terms are defined in [RFC6241]", >> but >>>> you re-define those terms. >>>> So give a warning about the redefinition to the readers. >>> Yes, that's what my proposed text does. It says that "datastore" is=20 >>> defined in 6241, and when YANG is used, it means the instantiated=20 >>> data tree. >>> >>>>>> - Section 4.1 >>>>>> >>>>>> YANG models can describe constraints to be enforced on the >> data, >>>>>> restricting the appearance or value of nodes based on the >> presence or >>>>>> value of other nodes in the hierarchy. >>>>>> >>>>>> I was looking for an example of appearance. >>>>>> NEW? >>>>>> YANG models can describe constraints to be enforced on the >> data, >>>>>> restricting the appearance (for example, with the "when" >> statement) >>>>>> or value of nodes based on the presence or value of other >> nodes in >>>>>> the hierarchy. >>>>> This is very early in the document, and the text tries to give a >> very >>>>> high level function overview. I am not sure that mentioning >> "when" at >>>>> this time actually helps a first time reader. >>>> The first time I read this, I was wondering how YANG data models=20 >>>> can describe constraints on HOW data appear, while you wanted to=20 >>>> express WHETHER a data appear. Maybe "when" is not the best way to=20 >>>> help the first time user, but something is needed. >>> How about "restricting the presence or value of nodes"? >>> >>> >>> /martin >>> >>> _______________________________________________ >>> 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 Tue May 3 07:10:46 2016 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 64BDC12D15C for ; Tue, 3 May 2016 07:10: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=kuatrotechnology.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 DHeCvuQ3gJ3V for ; Tue, 3 May 2016 07:10:42 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0043.outbound.protection.outlook.com [104.47.2.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F03212D0B6 for ; Tue, 3 May 2016 07:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JL5aHsuUN/dqpC9n5xgNupITr1YYH282eZknrHeXGb0=; b=dwZ15jcFWJaxpmF5tR7eN5cX1ufL+5wHw4KaG5HkFt8rk5bbtjxT4GAPDZd82zMD9A9IHSZChwXDPWGptRLGNtt+31yPPPx15MIy8DNJf3QzhkaMuFFXR08t3fLkjj+Q1hjglP7J7D/YDbZ6P03putiIsLujQPeM/eT2KJITFb4= Received: from DB5PR06MB0950.eurprd06.prod.outlook.com (10.162.158.140) by DB5PR06MB0949.eurprd06.prod.outlook.com (10.162.158.14) with Microsoft SMTP Server (TLS) id 15.1.485.3; Tue, 3 May 2016 14:10:39 +0000 Received: from DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) by DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) with mapi id 15.01.0492.006; Tue, 3 May 2016 14:10:39 +0000 From: "Ing-Wher (Helen) Chen" To: Juergen Schoenwaelder Thread-Topic: [netmod] update on "rdns" URN for enterprise YANG models Thread-Index: AdGXJqT2atwqDO1sS7m+/GLgZx0D2AABBcaAAAASVyAAEV4yAAC5VLVAAASqeQAAKi2lIAAAm3SAAAAbDzABh27yAAEDL2mA Date: Tue, 3 May 2016 14:10:39 +0000 Message-ID: References: <20160419182250.GA3771@elstar.local> <20160420.164755.1169712416411367784.mbj@tail-f.com> <20160428093854.GA23908@elstar.local> In-Reply-To: <20160428093854.GA23908@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: 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=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 8ea6b834-0734-4b3d-9bb2-08d3735cb485 x-microsoft-exchange-diagnostics: 1; DB5PR06MB0949; 5:DJgZz+lptiN8ZNMlC2MaJnuTZv/e/YGLQ21ljCIUDR/GYRCA9SCAnfZdKAp1o2b07Yr908Jt4Ot6Bk2NO9KLijnury+KIwKHgavgV3YyaihtgbAefOYkDdG6nHN3XBVZTCyIpvb9BkdZxw4UjTIzQw==; 24:PCXv9bgzi5GdUEueFxm9GuNds5IvZLlcKwr4v7xUqzakekbr8jyVypycG10QZzLy/7EQ/SnHn5tpEWGqunc9yD15bPijcuAg83m2kiauPVA=; 7:hHDxx/UJ7H6E5P/ImM5aV4eL+krFEbWgon9lqgQTnx4+9sx1l2A+o9OxCHQJiPimqM2E4g4pUh6XAEvMsraJP/upB5C1fcmXoWCCnYaO5cCkJV0jAaGS0YmL5KujQM+WyzUpmdr89jp93voDYBG1sXpsfB0RenH6rbQuUirr49zCAfhrIGWLX2yyljE4E6I7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR06MB0949; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521096)(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:DB5PR06MB0949; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB0949; x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(13464003)(5003600100002)(76576001)(19580405001)(6116002)(122556002)(19580395003)(5004730100002)(15975445007)(2900100001)(9686002)(2950100001)(3846002)(5008740100001)(1220700001)(33656002)(10400500002)(586003)(102836003)(86362001)(7110500001)(77096005)(93886004)(4326007)(87936001)(76176999)(11100500001)(54356999)(50986999)(81166005)(3280700002)(10710500007)(74316001)(2420400007)(15650500001)(189998001)(110136002)(3660700001)(92566002)(66066001)(5002640100001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR06MB0949; H:DB5PR06MB0950.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2016 14:10:39.0806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR06MB0949 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:10:45 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, April 28, 2016 5:39 AM > To: Ing-Wher (Helen) Chen > Cc: Martin Bjorklund ; netmod@ietf.org > Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models >=20 > On Wed, Apr 20, 2016 at 03:24:25PM +0000, Ing-Wher (Helen) Chen wrote: > > > > The technical problem of generalizing is the difficulty in creating a > > URN based on domain names that is also persistent. Limiting the scope > > of the "rdns" URN namespace to only YANG modules means that there is a > > smaller persistency problem to solve and that it can be solved by > > taking advantage of properties specific to YANG modules. > > >=20 > Can you detail which properties specific to YANG modules make the smaller > persistency problem solvable? It's both what YANG module namespaces don't need to have and the limited case where a non-persistent namespace results in a collision. The property that YANG module namespaces don 't need to have is that YANG module namespaces are not used to provide global resolution, where the persistence of a namespace is particularly important. (Please see RFC 3406 top of page 13 for the Identifier persistence discussion.) The potential collision of a non-persistent namespace is described In the example in . When a namespace collision does occur, the problem is limited to a device t= hat has an administrator and the solution is simple. This is also stated in draft-chen-rdns-urn , in the "Identifier Persistence Considerations" sectio= n at the bottom of page 5 . Thanks, Helen From nobody Tue May 3 07:34:58 2016 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 925E612D83B; Tue, 3 May 2016 07:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 gYEvxdn4l6Z7; Tue, 3 May 2016 07:34:50 -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 BBEAC12D836; Tue, 3 May 2016 07:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18533; q=dns/txt; s=iport; t=1462286087; x=1463495687; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=6hapEK+4a5NqZEWnEcnwCcVDxluvGkBsuEWvYhVB5YY=; b=gMKK5CMKI/VhRpfuu3P9n9yWhPOF4kNfF8ROe7fbBv762fdU6gkfEqan wUT+rrldSLpB42Bh0G4MlPYYu7YVxZmN9c+udVUtRvZmihTFEeUxN1qho Ij+TaFRODtw4rmJBOVK2xXxtSX7eVPvBnRqeS1/EIQ1KIfOqyRTLWGfhi c=; X-IronPort-AV: E=Sophos;i="5.24,572,1454976000"; d="scan'208,217";a="677025390" 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; 03 May 2016 14:34:45 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u43EYifm013526; Tue, 3 May 2016 14:34:44 GMT To: "Tarek Saad (tsaad)" References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> From: Robert Wilton Message-ID: Date: Tue, 3 May 2016 15:34:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> Content-Type: multipart/alternative; boundary="------------57E5E5B11600F1732E20E271" Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te@ietf.org" , "draft-ietf-netmod-schema-mount@ietf.org" Subject: Re: [netmod] Use of schema mounts for common model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 14:34:56 -0000 This is a multi-part message in MIME format. --------------57E5E5B11600F1732E20E271 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Tarek, I'm also wondering whether using schema mount in this way might be a bit like using a sledgehammer to crack a nut. With interfaces, there is a per device global list of interfaces where each list entry can have a different type and different properties. Currently these are using the iana:iftype to differentiate their different schema modes, but there is an idea to use more abstract identities. I'm not really familiar with the tunnel YANG models, but I was wondering whether the same approach has been considered for the TE tunnel YANG models at all? I.e. rather than having a separate protocol instantiation for each different data plane technology, instead have a per device global list of tunnels that hold the configuration and operational state, making use of when statements and identities (if required) to manage dataplane specific leaves. Each protocol specific data plane module could also maintain a protocol specific list containing leaf-refs back to the appropriate tunnels in the master list. Thanks, Rob On 29/04/2016 17:17, Tarek Saad (tsaad) wrote: > Thanks Martin, please see inline.. > > > On 2016-04-29, 6:29 AM, "Martin Bjorklund" > wrote: > > "Tarek Saad (tsaad)" > wrote: > > Hi authors/WG, > In draft-ietf-teas-yang-te, we are driving the definition for a > generic TE YANG model that can/may be used (and extended when > necessary) for different data plane technologies (e.g. MPLS, > OTN, WDM, > etc.). > Reviewing the schema mount idea presented in > draft-ietf-netmod-schema-mount, we are thinking this proposal is > useful and can facilitate the reuse of the our model in multiple > places in the YANG tree (once per each technology), e.g.: > /mpls/mount-points/mount-point/module=ietf-te.yang > /otn/mount-points/mount-point/module=ietf-te.yang > > > Schema mount is probably not the right solution to your problem. I > think a better solution in your case is to define groupings. > Groupings are designed to be re-used at different places in the > hierarchy. > > > We thought of this earlier, and found groupings pose their own set of > challenges too.. Specifically: > - a groupings with leafrefs could not reference data nodes that reside > in another grouping > - a grouping with leafrefs of relative path were challenge when the > relative path references data nodes outside the grouping > - the augmentation of the grouping by other modules is not as > straightforward > > That said, the grouping proposal seems to > > one could also think that with groupings one could address reuse of > the a model (e.g. Ietf-interfaces) for logical devices or VM (see > below). In fact, in your draft (section 2) you explicitly discourage > this approach as not scalable solution > > > With the "uses" approach, ietf-interfaces would have to define a > grouping with all its nodes, and the new model for logical devices > would have to use this grouping. This is a not a scalable solution, > since every time there is a new model defined, we would have to > update our model for logical devices to use a grouping from the new > model. Another problem is that this approach cannot handle vendor- > > > > We have a comment/concern/suggestion and we value your feedback. > The generic TE model currently references data nodes in the global > tree (e.g. from the ietf-interfaces model to define additional TE > properties associated with a specific device interface). Our > understanding after reading section 3.1 of your draft is the > mounted > model can *not* reference any data nodes outside the scope of the > mount-point (e.g. global data nodes in the yang tree). This > poses a > limitation for us, do you have a suggestion for this problem? > One possible solution we thought of was to replace the leaf-refs > pointing to the global data nodes (e.g. Ietf-interfaces) with > context > names (e.g. the interface name).. This decouples the data-nodes > defined in the TE generic model from those in the global tree > (e.g. the actual interface ietf-interfaces model). Any feedback on > this or better suggestions? > > > If you use groupings instead, you can still use proper leafrefs. > > > Not in all cases as described above. > > Regards, > Tarek > > > > /martin > > > > Regards, > Tarek > Excerpt from draft-ietf-netmod-schema-mount > 3.1. > Augment and Validation in Mounted Data > All paths (in leafrefs, instance-identifiers, XPath > expressions, and > target nodes of augments) in the data models mounted at a > mount point > are interpreted with the mount point as the root node, and the > mounted data nodes as its children. This means that data > within a > mounted subtree can never refer to data outside of this > subtree. > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------57E5E5B11600F1732E20E271 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Tarek,

I'm also wondering whether using schema mount in this way might be a bit like using a sledgehammer to crack a nut.

With interfaces, there is a per device global list of interfaces where each list entry can have a different type and different properties. Currently these are using the iana:iftype to differentiate their different schema modes, but there is an idea to use more abstract identities.

I'm not really familiar with the tunnel YANG models, but I was wondering whether the same approach has been considered for the TE tunnel YANG models at all?

I.e. rather than having a separate protocol instantiation for each different data plane technology, instead have a per device global list of tunnels that hold the configuration and operational state, making use of when statements and identities (if required) to manage dataplane specific leaves. Each protocol specific data plane module could also maintain a protocol specific list containing leaf-refs back to the appropriate tunnels in the master list.

Thanks,
Rob


On 29/04/2016 17:17, Tarek Saad (tsaad) wrote:
Thanks Martin, please see inline..


On 2016-04-29, 6:29 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:

"Tarek Saad (tsaad)" <tsaad@cisco.com> wrote:
Hi authors/WG,
In draft-ietf-teas-yang-te, we are driving the definition for a
generic TE YANG model that can/may be used (and extended when
necessary) for different data plane technologies (e.g. MPLS, OTN, WDM,
etc.).
Reviewing the schema mount idea presented in
draft-ietf-netmod-schema-mount, we are thinking this proposal is
useful and can facilitate the reuse of the our model in multiple
places in the YANG tree (once per each technology), e.g.:
/mpls/mount-points/mount-point/module=ietf-te.yang
/otn/mount-points/mount-point/module=ietf-te.yang

Schema mount is probably not the right solution to your problem.I
think a better solution in your case is to define groupings.
Groupings are designed to be re-used at different places in the
hierarchy.

We thought of this earlier, and found groupings pose their own set of challenges too.. Specifically:
- a groupings with leafrefs could not reference data nodes that reside in another grouping
- a grouping with leafrefs of relative path were challenge when the relative path references data nodes outside the grouping
- the augmentation of the grouping by other modules is not as straightforward

That said, the grouping proposal seems to

one could also think that with groupings one could address reuse of the a model (e.g. Ietf-interfaces) for logical devices or VM (see below). In fact, in your draft (section 2) you explicitly discourage this approach as not scalable solution


With the "uses" approach, ietf-interfaces would have to define a
grouping with all its nodes, and the new model for logical devices
would have to use this grouping. This is a not a scalable solution,
since every time there is a new model defined, we would have to
update our model for logical devices to use a grouping from the new
model. Another problem is that this approach cannot handle vendor-



We have a comment/concern/suggestion and we value your feedback.
The generic TE model currently references data nodes in the global
tree (e.g. from the ietf-interfaces model to define additional TE
properties associated with a specific device interface). Our
understanding after reading section 3.1 of your draft is the mounted
model can *not* reference any data nodes outside the scope of the
mount-point (e.g. global data nodes in the yang tree). This poses a
limitation for us, do you have a suggestion for this problem?
One possible solution we thought of was to replace the leaf-refs
pointing to the global data nodes (e.g. Ietf-interfaces) with context
names (e.g. the interface name).. This decouples the data-nodes
defined in the TE generic model from those in the global tree
(e.g. the actual interface ietf-interfaces model). Any feedback on
this or better suggestions?

If you use groupings instead, you can still use proper leafrefs.

Not in all cases as described above.

Regards,
Tarek



/martin



Regards,
Tarek
Excerpt from draft-ietf-netmod-schema-mount
Augment and Validation in Mounted Data
All paths (in leafrefs, instance-identifiers, XPath expressions, and
target nodes of augments) in the data models mounted at a mount point
are interpreted with the mount point as the root node, and the
mounted data nodes as its children.This means that data within a
mounted subtree can never refer to data outside of this subtree.



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

--------------57E5E5B11600F1732E20E271-- From nobody Wed May 4 08:45:26 2016 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 63F7A12D9CF for ; Wed, 4 May 2016 08:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1usN7lmcygM for ; Wed, 4 May 2016 08:45:24 -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 B1D3812D7EF for ; Wed, 4 May 2016 08:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2013; q=dns/txt; s=iport; t=1462376366; x=1463585966; h=to:cc:from:subject:message-id:date:mime-version; bh=xmlSHhtmIxyig8ZYmJBqADTJ4CGCOypK70dkIw9pjGc=; b=GTVlZ6xHvYJxchSp4H7yyeNeHOgql75RG+ok/HlP4Z/aTNgHMXL8tsSf fqM/b/24sZdBrzcwAnXkus5sNthlir2kRzG7/gs4XG+wMMv6ThHdyaxtf TQi7onocqPJEiR1Az2EgAbe3KQIms93iwP9DxESxxTd4bAzapCRKtcGGv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEBQB7FipX/xbLJq1egmyBSrVHhnaGE?= =?us-ascii?q?IIDAQEBAQEBZieEa1YfAQk0Al8NCAEBiCasOZEEAQEBAQEFAQEBAQEBGoYggXY?= =?us-ascii?q?Iig6CWQWYGYEujGqJO4VYjzRig2w7iGwBAQE?= X-IronPort-AV: E=Sophos;i="5.24,577,1454976000"; d="scan'208,217";a="635477237" 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; 04 May 2016 15:39:24 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u44FdOWa013694; Wed, 4 May 2016 15:39:24 GMT To: Martin Bjorklund From: Robert Wilton Message-ID: Date: Wed, 4 May 2016 16:39:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------9A98916F7CC1F6932EBE19F4" Archived-At: Cc: "netmod@ietf.org" Subject: [netmod] Minor nit on derived-from example in 6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:45:25 -0000 This is a multi-part message in MIME format. --------------9A98916F7CC1F6932EBE19F4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Martin, As I was updating another draft, I spotted a minor nit when looking at the derived-from example on 10.4.1.1, page 165. The derived-from example is: when 'derived-from(type, "exif:ethernet")'; but the prefix "exif" isn't actually defined in the module. Adding a prefix statement to the module may help clarify the example, although I admit that it is fairly obvious ... Thanks, Rob --------------9A98916F7CC1F6932EBE19F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Martin,

As I was updating another draft, I spotted a minor nit when looking at the derived-from example on 10.4.1.1, page 165.

The derived-from example is:

when 'derived-from(type, "exif:ethernet")';

but the prefix "exif" isn't actually defined in the module.  Adding a prefix statement to the module may help clarify the example, although I admit that it is fairly obvious ...

Thanks,
Rob

--------------9A98916F7CC1F6932EBE19F4-- From nobody Thu May 5 07:36:24 2016 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 2D2C512DA1C; Thu, 5 May 2016 07:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 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 w194R4fI-ccy; Thu, 5 May 2016 07:36:14 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5E712DA25; Thu, 5 May 2016 07:28:23 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-0c-572b58864296 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 81.C8.12926.6885B275; Thu, 5 May 2016 16:28:22 +0200 (CEST) Received: from [159.107.198.150] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.248.2; Thu, 5 May 2016 16:28:21 +0200 To: Xufeng Liu , "'Joel M. Halpern'" , "'Tarek Saad (tsaad)'" , 'Martin Bjorklund' References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> <01fc01d1a259$71cfae00$556f0a00$@gmail.com> From: Balazs Lengyel Message-ID: <243c1632-b802-7125-3335-096db431d560@ericsson.com> Date: Thu, 5 May 2016 16:28:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <01fc01d1a259$71cfae00$556f0a00$@gmail.com> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2J7uG5bhHa4wY5PfBYTD9hbfOp4yWLx 8dQbJovu7mfsFreWrmS1mH+xkdWi9ccOFotPJ34yWVw5/ofJgdNjyu+NrB47Z91l91iy5CeT x7kp3xk9Nv5azBLAGsVlk5Kak1mWWqRvl8CVMev0CpaCbxEVTbdPszQwHnPpYuTgkBAwkbi9 lK+LkRPIFJO4cG89WxcjF4eQwBFGiT9b57NDOGsYJQ50PWECqRIWcJJY93IrM0hCRGAFo8Sl 158ZIap6mSROLZ7NAuIwC3QwSry5s4YNpIVNwEhiav95FhCbV8Be4sGXR8wgu1kEVCQm/q8G CYsKREk8Ob2WGaJEUOLkzCdg5ZwCFhJb1pwGs5kF9CWu37nPCmHLSzRvnQ1WLySgIfHwwl/W CYyCs5C0z0LSMgtJywJG5lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgVFxcMtv1R2Ml984 HmIU4GBU4uFVWKkVLsSaWFZcmXuIUYKDWUmE93m4drgQb0piZVVqUX58UWlOavEhRmkOFiVx Xv+XiuFCAumJJanZqakFqUUwWSYOTqkGRoa9u8t9D8mrZZYVMy+Yf+t+8hXprRuL3iu0i09e 9TGXb8Era7UvrOfiwy6UPIrXElR2+XjQwWHB7qK7Py8/Ztgja7SHzTzgX+ec61ssWXZNTdNe fIJVYnPN/A8hLrox6tqTdtguamoOmnQyxvum33t9g6dJeRF1Iuv9czj1zNLsHlm++DErTIml OCPRUIu5qDgRAOAWiFWGAgAA Archived-At: Cc: draft-ietf-teas-yang-te@ietf.org, mpls@ietf.org, teas@ietf.org, netmod@ietf.org, draft-ietf-netmod-schema-mount@ietf.org Subject: Re: [netmod] [Teas] Use of schema mounts for common model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:36:18 -0000

Hello,

As I see it the problem is that as we don't know the mount relationships early. All you can say in the constraint is "point at some interface". So having a specific path statement is not feasible.

Using instance-identifiers may help. While it is hard it is not impossible to constrain instance-identifiers. You can put a regular expression on their "string" representation, e.g. rematch(.,'/.*/interface[name=.*]')

This would alow you to point at an interface anywhere (as long as the list is named interface with a key called name :-( ). Note the regexp is not 100% OK.
regards Balazs

On 2016-04-29 22:55, Xufeng Liu wrote:
We still hope that schema mount can handle cross-referencing across mounted
modules. It is also needed when ietf-interfaces model is mounted to
logical-network-element  and network-instance models.

More comments for this case below in-line.

Thanks,

- Xufeng


-----Original Message-----
From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Friday, April 29, 2016 1:05 PM
To: Tarek Saad (tsaad) <tsaad@cisco.com>; Martin Bjorklund

<mbj@tail-f.com>

Cc: draft-ietf-teas-yang-te@ietf.org; mpls@ietf.org; teas@ietf.org;
netmod@ietf.org; draft-ietf-netmod-schema-mount@ietf.org
Subject: Re: [Teas] [netmod] Use of schema mounts for common model

With regard to leafrefs trying to point into groupings, would

instance-identifiers

work for your use case?


In this case, it would be hard to specify the must conditions for these
instance-identifiers to make them always applicable when the groupings are
used in various situations. If we are willing to re-structure everything,
the method used in draft-halpern-supa-generic-policy-data-model could be an
option to explore. 


Yours,
Joel

On 4/29/16 12:17 PM, Tarek Saad (tsaad) wrote:

Thanks Martin, please see inline..


On 2016-04-29, 6:29 AM, "Martin Bjorklund" <mbj@tail-f.com
<mailto:mbj@tail-f.com>> wrote:

    "Tarek Saad (tsaad)" <tsaad@cisco.com <mailto:tsaad@cisco.com>>

wrote:

        Hi authors/WG,
        In draft-ietf-teas-yang-te, we are driving the definition for a
        generic TE YANG model that can/may be used (and extended when
        necessary) for different data plane technologies (e.g. MPLS,
        OTN, WDM,
        etc.).
        Reviewing the schema mount idea presented in
        draft-ietf-netmod-schema-mount, we are thinking this proposal is
        useful and can facilitate the reuse of the our model in multiple
        places in the YANG tree (once per each technology), e.g.:
        ./mpls/mount-points/mount-point/module=ietf-te.yang
        ./otn/mount-points/mount-point/module=ietf-te.yang


    Schema mount is probably not the right solution to your problem.  I
    think a better solution in your case is to define groupings.
    Groupings are designed to be re-used at different places in the
    hierarchy.


We thought of this earlier, and found groupings pose their own set of
challenges too.. Specifically:
- a groupings with leafrefs could not reference data nodes that reside
in another grouping
- a grouping with leafrefs of relative path were challenge when the
relative path references data nodes outside the grouping
- the augmentation of the grouping by other modules is not as
straightforward

That said, the grouping proposal seems to

one could also think that with groupings one could address reuse of
the a model (e.g. Ietf-interfaces) for logical devices or VM (see
below). In fact, in your draft (section 2) you explicitly discourage
this approach as not scalable solution


   With the "uses" approach, ietf-interfaces would have to define a
   grouping with all its nodes, and the new model for logical devices
   would have to use this grouping.  This is a not a scalable solution,
   since every time there is a new model defined, we would have to
   update our model for logical devices to use a grouping from the new
   model.  Another problem is that this approach cannot handle vendor-



        We have a comment/concern/suggestion and we value your feedback.
        The generic TE model currently references data nodes in the

global

        tree (e.g. from the ietf-interfaces model to define additional

TE

        properties associated with a specific device interface). Our
        understanding after reading section 3.1 of your draft is the

mounted

        model can *not* reference any data nodes outside the scope of

the

        mount-point (e.g. global data nodes in the yang tree). This

poses a

        limitation for us, do you have a suggestion for this problem?
        One possible solution we thought of was to replace the leaf-refs
        pointing to the global data nodes (e.g. Ietf-interfaces) with
        context
        names (e.g. the interface name).. This decouples the data-nodes
        defined in the TE generic model from those in the global tree
        (e.g. the actual interface ietf-interfaces model). Any feedback

on

        this or better suggestions?


In this case, there are multiple augmentations to ietf-te.yang, such as
ietf-rsvp-te and ietf-sr-te. If ietf-te is a grouping, we cannot do the
augmentations before ietf-te is used. Using the grouping would be very
awkward when ietf-te is used. We would have to make the same many
augmentations at that time. Even worse, there could be future augmentations,
we cannot specify these augmentations now because they are not defined yet.


    If you use groupings instead, you can still use proper leafrefs.


Not in all cases - as described above.

Regards,
Tarek



    /martin



        Regards,
        Tarek
        Excerpt from draft-ietf-netmod-schema-mount
        3.1<https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-

01#section-3.1>.

        Augment and Validation in Mounted Data
            All paths (in leafrefs, instance-identifiers, XPath
        expressions, and
            target nodes of augments) in the data models mounted at a
        mount point
            are interpreted with the mount point as the root node, and

the

            mounted data nodes as its children.  This means that data
        within a
            mounted subtree can never refer to data outside of this

subtree.




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


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

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



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Thu May 5 07:52:19 2016 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 BFA0C12DB7D for ; Thu, 5 May 2016 07:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 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 qPFJpQPvtTL4 for ; Thu, 5 May 2016 07:52:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A56B12D8AF for ; Thu, 5 May 2016 07:44:24 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-d9-572b5c465bdf Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F4.85.27088.64C5B275; Thu, 5 May 2016 16:44:22 +0200 (CEST) Received: from [159.107.198.150] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.248.2; Thu, 5 May 2016 16:44:22 +0200 To: "netmod@ietf.org" From: Balazs Lengyel Message-ID: Date: Thu, 5 May 2016 16:44:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM2K7tK5bjHa4weKLBhbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoErY/L1RYwFq3krfq/7wtjA2MrVxcjJISFgIrFu8h82CFtM4sK9 9UA2F4eQwBFGiU/fj7JAOGsYJb6vWcMOUiUioC4xc+d6sA42ASOJqf3nWUBsYQF5ib5brUwg Nq+AvcTD1s2sIDaLgIrE7DvbwepFBaIknpxeywxRIyhxcuYTsF5mAQ2J1jlz2SFseYnmrbPB aoSA4g8v/GWdwMg3C0nLLCQts5C0LGBkXsUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGFQH t/w22MH48rnjIUYBDkYlHl6FlVrhQqyJZcWVuYcYJTiYlUR4d0ZqhwvxpiRWVqUW5ccXleak Fh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpgjP7wd9PFmor3AtJiJ7aqyZR6Wack m626fynsaLsk0+5la1i+OJnkTGLsK7p7Q25JcF7/uwqZpVGzr7qlMJr5v1qxzy18R8bkUpfv L12mJ26sd7uZ3yu5xSFR9nOqZurlQJ7a0Pkpxtma7ckPly7bePzd6+b9MeVBpQZ+M1jXNIa+ WWx2Z/kJJZbijERDLeai4kQA7rPJBCYCAAA= Archived-At: Subject: [netmod] Schema mount questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:52:18 -0000

Hello,

1) Will mounted YANG modules be listed in the base ietf-yang-library? Even the mounted ones?

2) What does conformance to a YANG  module e.g. ietf-system mean now? Do we need to load the module at the top level, or is it enough to mount it “somewhere” in the containment tree?

3) If the answer to 2) is it can be mounted anywhere, which modules must be present at the top level? E.g. ietf-yang-library?

4) If a new list entry is created can it introduce a completely new module never heard of before in the network element?

5) IMHO allowing such dynamic introduction of new YANG modules into a network element, with flexible mountpoints, flexible set of modules at each mountpoint, a flexible set of deviations and features for each mounted module makes discovery actual available schema tree difficult. I think we are providing to much flexibility, over-complicating the issue. Some more static mounting solution that can be read from YANG modules instead of run-time data would be easier.

regards Balazs



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Thu May 5 11:10:34 2016 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 BD56612D701 for ; Thu, 5 May 2016 11:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 SkmNSR7OegUY for ; Thu, 5 May 2016 11:10:29 -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 D978D12D0E4 for ; Thu, 5 May 2016 11:03:14 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id m64so104996170lfd.1 for ; Thu, 05 May 2016 11:03:14 -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:date:message-id:subject:from:to :cc; bh=nLcxTS2T/oVhZWaKWXDU/zq8zeaqTONkTI1Xrb1zQSo=; b=iz1OOSxLx6MMISHnyoJNDB4YFgDaMfEQrvfPNdyUCUDqUQElEJvgczhsxa2FwD5mRD QAkQ+BOOvt4Aa9KAQU9+PoGdRnilG9vLB6fU0DU9tTs4s3uv3BcCnWt6HJ5mGNDOrTV9 tft7s+csNpLNr8SwY5/fxHrnRC27A+qmvdjjiznLzGZB7dqeHfpXr7Hlx7BUNhQnlWxL STMWTDWEd/R9ivcqpmw0rTSb5ZK5tthqYWy+TP/XjDwqAJ4Pqa9pmONScFoOrnjxUq+E PD7v1GbyDKKhrwYyjO66FhJgYRYttovnB8MU5AXVU9hMKBt834R6WmhDwCjkHZB5Cgc5 6DcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nLcxTS2T/oVhZWaKWXDU/zq8zeaqTONkTI1Xrb1zQSo=; b=H7sZ7J6lg0NMF58oJ1zQDzoMYMGdM9AMBei3+emVI7wLp5Dz0h2Es//pjVw6vqPwfa P4P2k0OiLDPeFVE16X7aSi4xOIZB00uTkyRLR+RzxYDB/7NhuSBDNBUPVkSqeXH+bYNQ P6AnZFXjnYSObMt8cSGzy9OhUKLUhH0nT034K3Rncs3VcPyZ4uJH719zkBUZ8NxeMsXK uOyhNSq43uai8pczvJGbYZxYNiOJgcpvF94RR5Dff6UdU40LS7m6f9W+XTiHMiPmutR0 rbEEZPNPBvsy/bvhHs4h8IZJJmHvBUfHLrZ5HgliWo++Rrk7uOXNI8QOGy6xpc2ipDDj QH3w== X-Gm-Message-State: AOPr4FUICX/5MVexcZBKbScnXJCjDCnC8xhMoSM2Gvwq1lrdbPHsLzqCMULrqDNyIy1Aug43lCapxM2ePSYqkQ== MIME-Version: 1.0 X-Received: by 10.112.22.131 with SMTP id d3mr7486521lbf.145.1462471392888; Thu, 05 May 2016 11:03:12 -0700 (PDT) Received: by 10.112.198.70 with HTTP; Thu, 5 May 2016 11:03:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 May 2016 11:03:12 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=14dae947364fdecbdb05321c2707 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Schema mount questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 18:10:32 -0000 --14dae947364fdecbdb05321c2707 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 5, 2016 at 7:44 AM, Balazs Lengyel wrote: > Hello, > > 1) Will mounted YANG modules be listed in the base ietf-yang-library? Eve= n > the mounted ones? > Does the server providing the mounted modules claim conformance to those models? IMO YANG mount breaks the "YANG API contract" if even 1 tiny property is ignored, due to mounting. I asked for a conformance enum of 'none' or 'other' for this exact purpose but the WG did not think it was possible for a server to do anything other than implement or import a YANG module. E.g, we are building a special server "library-mode" that just provided\s the library and get-schema for every module. They will all be listed as 'imported' (so that enum essentially becomes 'other') 2) What does conformance to a YANG module e.g. ietf-system mean now? Do we > need to load the module at the top level, or is it enough to mount it > =E2=80=9Csomewhere=E2=80=9D in the containment tree? > It means the same if the server returns "implement" Mounting the module violates the contract because the module clearly defines /system as a top-level node. Any other location is non-compliant. 3) If the answer to 2) is it can be mounted anywhere, which modules must be > present at the top level? E.g. ietf-yang-library? > IMO the YANG contract only supports the data placement explicit in the module. > 4) If a new list entry is created can it introduce a completely new modul= e > never heard of before in the network element? > ?? this is fine for "anydata" 5) IMHO allowing such dynamic introduction of new YANG modules into a > network element, with flexible mountpoints, flexible set of modules at ea= ch > mountpoint, a flexible set of deviations and features for each mounted > module makes discovery actual available schema tree difficult. I think we > are providing to much flexibility, over-complicating the issue. Some more > static mounting solution that can be read from YANG modules instead of > run-time data would be easier. > mount is way over-engineered but schema-defined mount-points don't really help. A nested "root" works and has a use-case. Everything else is extra and an implementation choice without any real use-case. YANG is already complicated and slow. mount and sym-links makes it worse. regards Balazs > > > Andy > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --14dae947364fdecbdb05321c2707 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 5, 2016 at 7:44 AM, Balazs Lengyel <balazs.lengy= el@ericsson.com> wrote:
=20 =20 =20

Hello,

1) Will mounted YANG modules be listed in the base ietf-yang-library? Even the mounted ones?

=
Does the server providing the mounted modules claim conforma= nce
to those models?

IMO YANG mount brea= ks the "YANG API contract" if even 1 tiny
property is i= gnored, due to mounting.

I asked for a conformance= enum of 'none' or 'other' for this exact purpose but
=
the WG did not think it was possible for a server to do anything
=
other than implement or import a YANG module.

E.g, we are building a special server "library-mode" that just
provided\s the library and get-schema for every module.
= They will all be listed as 'imported' (so that enum essentially
becomes 'other')


2) What does conformance to a YANG=C2=A0 module e.g. ietf-system mea= n now? Do we need to load the module at the top level, or is it enough to mount it =E2=80=9Csomewhere=E2=80=9D in the containment tre= e?



It means the sa= me if the server returns "implement"=C2=A0
Mounting the= module violates the contract because the
module clearly defines = /system as a top-level node.
Any other location is non-compliant.=


3) If the answer to 2) is it can be mounted anywhere, which modules must be present at the top level? E.g. ietf-yang-library?

=

IMO the YANG contract only supports = the data placement explicit
in the module.=C2=A0
=C2=A0=

4) If a new list entry is created can it introduce a completely new module never heard of before in the network element?


??=C2=A0

this is fin= e for "anydata"

5) IMHO allowing such dynamic introduction of new YANG modules into a network element, with flexible mountpoints, flexible set of modules at each mountpoint, a flexible set of deviations and features for each mounted module makes discovery actual available schema tree difficult. I think we are providing to much flexibility, over-complicating the issue. Some more static mounting solution that can be read from YANG modules instead of run-time data would be easier.


mount is way over-engineered =C2=A0but schema-defined mount-points = don't really help.
A nested "root" works and has a = use-case.=C2=A0 Everything else is extra
and an implementation ch= oice without any real use-case.=C2=A0 YANG is already
complicated= and slow. mount and sym-links makes it worse.

regards Balazs




Andy
=C2=A0


--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20

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


--14dae947364fdecbdb05321c2707-- From nobody Thu May 5 14:15:45 2016 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 8146F12D0C0; Thu, 5 May 2016 14:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAcnHS-JmTqM; Thu, 5 May 2016 14:15:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74ED412D0BD; Thu, 5 May 2016 14:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yhdfjoSmEUPm88YGI0zmvHnewvaD0kvqwBWt78Pe2gQ=; b=dn47Q8U75frxjy/ar0OZYBF0pZgBi4wEGSkLE2lwjMrg3yd2liolf4PTjCqyJRn7KRPLec3TNhh7UbKJN585Znwj+gIbfgqAZYjMQhKwu5R2OBPm1z5Lvv8HUK6sj4iFPdzutJIKus1YjxDOpCw0cQDzX4akMhATKvdVap1cZL8= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.485.9; Thu, 5 May 2016 21:15:17 +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.0477.017; Thu, 5 May 2016 21:15:17 +0000 From: Kent Watsen To: "Dongjie (Jimmy)" , "andy@yumaworks.com" , "mbj@tail-f.com" , "dromasca@avaya.com" Thread-Topic: =?utf-8?B?562U5aSNOiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWVudGl0eWR0LW5ldG1v?= =?utf-8?Q?d-entity?= Thread-Index: AQHRpxM4dVrdVEiOvEquz0R/ATVCsQ== Date: Thu, 5 May 2016 21:15:16 +0000 Message-ID: <15884361-2DF2-4DF6-8519-68B2561C7B44@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: da58323d-8779-4088-e240-08d3752a5b53 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:5afFKVe8GTS9JEDLFojm6U3Xemf6vItme0g74RyeagSOsSh2if0D+1jTLKWUNwK7ppUVOKcvdODLaYdsysZyGn7SU2qz8ruHFU1eDbusYi9Hu+eBaA1H1uvyhwNcSw1l18GssKowUF+sV+uMauXgWg==; 24:rEB7imvgN6aJ6V67M2NSkMbLjenfOOAo7XYAxN3OKQUmsTRNqyAt6v6pSCfz57fIbFFRlYaI2rZvGQ1aTa6rKKvN/wJXjGo0ZNL9Jc0zci0=; 7:2Sy8tGYnRut16XrdxeIFsX1//+abKfvwYb3ebdgpk4k2a1SemiMqkS4iRrP0j7vidMSTW/AHNdJY5aTUyZg2i1cSR3LyFTdHft4EKZvT0WxUF2SJJShPF0LP8c3rf6WNmJl7prz5zIbx2BrdjyEXMgtTNvhrgq1A0p9LFhBM4yLKb21wsckgYa+JoJU1hxJ3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521098)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(4326007)(92566002)(19580405001)(86362001)(83506001)(2201001)(122556002)(5008740100001)(81166005)(19625215002)(19580395003)(19617315012)(36756003)(87936001)(5002640100001)(2906002)(10400500002)(18717965001)(224303003)(8936002)(106116001)(189998001)(99286002)(2501003)(15975445007)(1220700001)(19300405004)(4001350100001)(77096005)(66066001)(3846002)(83716003)(790700001)(3280700002)(33656002)(54356999)(586003)(5004730100002)(50986999)(6116002)(16236675004)(11100500001)(3660700001)(82746002)(102836003)(230783001)(2900100001)(5001770100001)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_158843612DF24DF6851968B2561C7B44junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2016 21:15:16.9422 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] =?utf-8?b?562U5aSNOiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWVu?= =?utf-8?q?titydt-netmod-entity?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 21:15:44 -0000 --_000_158843612DF24DF6851968B2561C7B44junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpUaGUgY2hhaXJzIHJlY2VpdmVkIHRoZSBmaW5hbCBJUFIgZGlzY2xvc3VyZSBmcm9tIERhbiBS b21hc2NhbnUuICBUaGlzIG1lYW5zIHRoYXQgdGhlIGRyYWZ0IGlzIG5vdyBvZmZpY2lhbGx5IGFk b3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAuDQoNCkF1dGhvcnMsDQoNClBsZWFzZSByZXN1Ym1p dCB0aGUgZHJhZnQgd2l0aCB0aGUgb25seSBjaGFuZ2UgYmVpbmcgdG8gcmVuYW1lIHRoZSBkcmFm dCB0byBkcmFmdC1pZXRmLW5ldG1vZC1lbnRpdHlkdC1lbnRpdHktMDAuDQoNClRoYW5rIHlvdSEN CktlbnQgKGFuZCBjby1jaGFpcnMpDQoNCg0KRnJvbTogIkRvbmdqaWUgKEppbW15KSIgPGppZS5k b25nQGh1YXdlaS5jb208bWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb20+Pg0KRGF0ZTogVGh1cnNk YXksIE1hcmNoIDE3LCAyMDE2IGF0IDU6NDAgUE0NClRvOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBq dW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+LCAiYW5keUB5dW1hd29ya3Mu Y29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+IiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb20+PiwgIm1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1m LmNvbT4iIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiwgImRyb21hc2Nh QGF2YXlhLmNvbTxtYWlsdG86ZHJvbWFzY2FAYXZheWEuY29tPiIgPGRyb21hc2NhQGF2YXlhLmNv bTxtYWlsdG86ZHJvbWFzY2FAYXZheWEuY29tPj4NCkNjOiAibmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v cmc+PiwgIm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1jaGFpcnNAaWV0Zi5v cmc+IiA8bmV0bW9kLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9y Zz4+DQpTdWJqZWN0OiDnrZTlpI06IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtZW50aXR5ZHQtbmV0 bW9kLWVudGl0eQ0KDQpIaSwNCg0KSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGll cyB0byB0aGlzIGRyYWZ0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpKaWUNCg0K5Y+R5Lu25Lq6OiBLZW50 IFdhdHNlbiBbbWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXRdDQrlj5HpgIHml7bpl7Q6IDIwMTbl ubQz5pyIMTfml6UgMjoyMA0K5pS25Lu25Lq6OiBhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFu ZHlAeXVtYXdvcmtzLmNvbT47IG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT47 IERvbmdqaWUgKEppbW15KTsgZHJvbWFzY2FAYXZheWEuY29tPG1haWx0bzpkcm9tYXNjYUBhdmF5 YS5jb20+DQrmioTpgIE6IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPjsg bmV0bW9kLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz4NCuS4 u+mimDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1lbnRpdHlkdC1uZXRtb2QtZW50aXR5DQoNCltU aGlzIHJlZ2FyZHMgdGhlIG5ldyBwcmUtYWRvcHRpb24gcHJvY2VzcyBkZXNjcmliZWQgYnkgaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzE1NTIw Lmh0bWxdDQoNCg0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiB0aGUg cHJlcGFyYXRpb24gZm9yIFdHIExhc3QgQ2FsbCwgYXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRo YXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPyAgUGxlYXNlIHN0YXRlIGVpdGhl cjoNCg0KICAgICJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0 aGlzIGRyYWZ0Ig0Kb3INCiAgICAiWWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0 byB0aGlzIGRyYWZ0Ig0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNv bXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2Njkg YW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/ICBJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ug c3RhdGUgZWl0aGVyOg0KDQogICAgIlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4g Y29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0Kb3INCiAgICAiTm8sIHRoZSBJUFIgaGFz IG5vdCBiZWVuIGRpc2Nsb3NlZCINCg0KSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUg YW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsNCmFwcHJvcHJpYXRlLg0KDQpJZiB5b3Ug YXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5z d2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3 aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9j dW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNl IGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRv ci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FH ReKAmVMgVE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0 ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJp YnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVURiBJ UFIgcnVsZXMgd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBh cmUgYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8g cmVmcmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNz aW9uIHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9u LCBwbGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZSBhbmQgaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQoNClRo YW5rIHlvdSwNCk5FVE1PRCBXRyBDaGFpcnMNCg0KUFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3Rl ZCBpbiB0aGUgaGVhZGVycyBvZiB0aGlzIG1lc3NhZ2UgaW4geW91ciByZXNwb25zZS4NCg0K --_000_158843612DF24DF6851968B2561C7B44junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PlRoZSBjaGFpcnMgcmVjZWl2ZWQgdGhlIGZpbmFsIElQUiBkaXNjbG9z dXJlIGZyb20gRGFuIFJvbWFzY2FudS4gJm5ic3A7VGhpcyBtZWFucyB0aGF0IHRoZSBkcmFmdCBp cyBub3cgb2ZmaWNpYWxseSBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNh bnMtc2VyaWYiPkF1dGhvcnMsPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp LHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJy aSxzYW5zLXNlcmlmIj5QbGVhc2UgcmVzdWJtaXQgdGhlIGRyYWZ0IHdpdGggdGhlIG9ubHkgY2hh bmdlIGJlaW5nIHRvIHJlbmFtZSB0aGUgZHJhZnQgdG8mbmJzcDs8L2ZvbnQ+ZHJhZnQtaWV0Zi1u ZXRtb2QtZW50aXR5ZHQtZW50aXR5LTAwLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5UaGFuayB5b3UhPC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPktlbnQgKGFuZCBjby1jaGFpcnMp PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxz YW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExP T0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBC T1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURE SU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBC T1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsg UEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTog PC9zcGFuPiZxdW90O0RvbmdqaWUgKEppbW15KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpp ZS5kb25nQGh1YXdlaS5jb20iPmppZS5kb25nQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXksIE1hcmNoIDE3 LCAyMDE2IGF0IDU6NDAgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86 IDwvc3Bhbj5LZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5u ZXQiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmFu ZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDss ICZxdW90OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJqQHRhaWwtZi5jb208L2E+ JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJqQHRhaWwtZi5j b208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyb21hc2NhQGF2YXlhLmNvbSI+ZHJv bWFzY2FAYXZheWEuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyb21hc2NhQGF2 YXlhLmNvbSI+ZHJvbWFzY2FAYXZheWEuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGll dGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0 bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFp bHRvOm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmciPm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZyI+bmV0bW9kLWNo YWlyc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PlN1YmplY3Q6IDwvc3Bhbj7nrZTlpI06IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtZW50aXR5ZHQt bmV0bW9kLWVudGl0eTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmlj ZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0 LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRh IG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1l ZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFuZz0iWkgtQ04iIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiPkhpLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+SSdtIG5vdCBhd2FyZSBvZiBhbnkg SVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+QmVz dCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkppZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiBLZW50IFdhdHNlbiBbPGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5u ZXQiPm1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0PC9hPl0NCjxicj4NCjwvc3Bhbj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiAyMDE2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8c3Bh biBsYW5nPSJFTi1VUyI+Mzwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTc8L3NwYW4+5pel PHNwYW4gbGFuZz0iRU4tVVMiPiAyOjIwPGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IDxhIGhyZWY9Im1haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb20iPg0KYW5keUB5dW1hd29ya3MuY29tPC9hPjsgPGEgaHJlZj0i bWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT47IERvbmdqaWUgKEppbW15 KTsNCjxhIGhyZWY9Im1haWx0bzpkcm9tYXNjYUBhdmF5YS5jb20iPmRyb21hc2NhQGF2YXlhLmNv bTwvYT48YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+DQpu ZXRtb2RAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9y ZyI+bmV0bW9kLWNoYWlyc0BpZXRmLm9yZzwvYT48YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmVnYXJkaW5nIElQ UiBvbiBkcmFmdC1lbnRpdHlkdC1uZXRtb2QtZW50aXR5PG86cD48L286cD48L3NwYW4+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2Nv bG9yOmJsYWNrIj5bVGhpcyByZWdhcmRzIHRoZSBuZXcgcHJlLWFkb3B0aW9uIHByb2Nlc3MgZGVz Y3JpYmVkIGJ5DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bmV0bW9kL2N1cnJlbnQvbXNnMTU1MjAuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzE1NTIwLmh0bWw8L2E+XTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmll cjtjb2xvcjpibGFjayI+QXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0 aW9uIGZvciBXRyBMYXN0IENhbGwsIGFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxp ZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT8gJm5ic3A7UGxlYXNlIHN0YXRlIGVpdGhlcjo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 Q291cmllcjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPiZuYnNwOyAm bmJzcDsgJnF1b3Q7Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8g dGhpcyBkcmFmdCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5vcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJs YWNrIj4mbmJzcDsgJm5ic3A7ICZxdW90O1llcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxp ZXMgdG8gdGhpcyBkcmFmdCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmll cjtjb2xvcjpibGFjayI+SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21w bGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+KHNlZSBSRkNz IDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/ICZuYnNwO0lmIHll cyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZxdW90O1llcywgdGhl IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVz JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPiZuYnNw OyAmbmJzcDsgJnF1b3Q7Tm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCZxdW90Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+SWYgeW91IGFu c3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbms8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 Q291cmllcjtjb2xvcjpibGFjayI+YXBwcm9wcmlhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50 IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZSBhYm92ZSBieSByZXNwb25k aW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3 YXJlIG9mIGFueSByZWxldmFudA0KIElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNl IHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJv bSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJRVMg VE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdF4oCZUyBUTyBMSU5FUy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmll cjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPklmIHlvdSBhcmUgb24g dGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3Rl ZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxp Z2F0aW9ucyB1bmRlciB0aGUgSUVURiBJUFIgcnVsZXMNCiB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0 byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFu IElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBh bnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2Vk IElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFi b3ZlIGFuZCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2ll c2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Ij5odHRwOi8vdHJhYy50b29scy5pZXRm Lm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eTwvYT4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJp ZXI7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5UaGFuayB5b3UsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNv dXJpZXI7Y29sb3I6YmxhY2siPk5FVE1PRCBXRyBDaGFpcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPlBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQg aW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIgcmVzcG9uc2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_158843612DF24DF6851968B2561C7B44junipernet_-- From nobody Thu May 5 19:49:38 2016 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 C3B2F12D0FC for ; Thu, 5 May 2016 19:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssZ1FShvpwY2 for ; Thu, 5 May 2016 19:49:31 -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 F088B12D0B8 for ; Thu, 5 May 2016 19:49:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COB37676; Fri, 06 May 2016 02:49:27 +0000 (GMT) Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 6 May 2016 03:49:26 +0100 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.108]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0235.001; Fri, 6 May 2016 10:49:23 +0800 From: wangzitao To: Andy Bierman , Balazs Lengyel Thread-Topic: [netmod] Schema mount questions Thread-Index: AQHRpt3ELPPsxAQ3N0icew8PaQiz8J+qHO4AgAEYQnA= Date: Fri, 6 May 2016 02:49:23 +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.13] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EAD253ADszxeml501mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.572C0638.007C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.108, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3d558259fe46e2c55743f53906157a5f Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Schema mount questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 02:49:37 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EAD253ADszxeml501mbxchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHRoaW5rIG9uZSBpbXBvcnRhbnQgcXVlc3Rpb24gaXMgaG93IHRvIGZsZXhp Ymx5IHVzZSDigJxTY2hlbWEgbW91bnTigJ0uDQpDdXJyZW50bHksIGl0IHN1cHBvcnQgbW91bnQg dGhlIG1vZHVsZXMgd2hpY2ggYmUgbGlzdGVkIGluIHRoZSBpZXRmLXlhbmctbGlicmFyeS4NCkJ1 dCBob3cgdG8gZXh0ZW5kIHRoZSBtb3VudD8gT3IgaG93IHRvIHN1cHBvcnQgb3RoZXIgbW9kdWxl cyAodGhlc2Ugbm90IGluY2x1ZGUgaW4geWFuZyBsaWJyYXJ5KT8NCk9uZSBleGFtcGxlIGlzIGRy YWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWw6DQoNCiAgICAgICBtb2R1bGU6IG5ldHdv cmstZGV2aWNlDQogICAgICAgICAgKy0tcncgaWV0Zi15YW5nLWxpYnJhcnkNCiAgICAgICAgICB8 DQogICAgICAgICAgKy0tcncgaW50ZXJmYWNlcw0KICAgICAgICAgICstLXJ3IGhhcmR3YXJlDQog ICAgICAgICAgKy0tcncgcW9zDQogICAgICAgICAgfA0KICAgICAgICAgICstLXJ3IHN5c3RlbS1t YW5hZ2VtZW50DQogICAgICAgICAgKy0tcncgbmV0d29yay1zZXJ2aWNlcw0KICAgICAgICAgICst LXJ3IG9hbS1wcm90b2NvbHMNCg0KDQpEbyB3ZSBuZWVkIHRvIG1vZGVsIGFuIOKAnG9hbSBwcm90 b2NvbHMgbGlicmFyeeKAnSBmaXJzdCwNCg0KYW5kIHRoZW4gYXVnbWVudCB0aGUgU2NoZW1hIE1v dW50IFlBTkcgTW9kdWxlIHRvIGdldCBhIOKAnG1vdW50LW9hbS1saWJyYXJ54oCdIHRvIHN1cHBv cnQgbW91bnRpbmcgdGhlIG9hbSBwcm90b2NvbHMgbGlicmFyeT8NCg0KDQoNCkJlc3QgUmVnYXJk cyENCg0KLU1pY2hhZWwNCg0KDQrlj5Hku7bkuro6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnXSDku6PooaggQW5keSBCaWVybWFuDQrlj5HpgIHml7bpl7Q6IDIwMTblubQ1 5pyINuaXpSAyOjAzDQrmlLbku7bkuro6IEJhbGF6cyBMZW5neWVsDQrmioTpgIE6IG5ldG1vZEBp ZXRmLm9yZw0K5Li76aKYOiBSZTogW25ldG1vZF0gU2NoZW1hIG1vdW50IHF1ZXN0aW9ucw0KDQoN Cg0KT24gVGh1LCBNYXkgNSwgMjAxNiBhdCA3OjQ0IEFNLCBCYWxhenMgTGVuZ3llbCA8YmFsYXpz Lmxlbmd5ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+ PiB3cm90ZToNCg0KSGVsbG8sDQoNCjEpIFdpbGwgbW91bnRlZCBZQU5HIG1vZHVsZXMgYmUgbGlz dGVkIGluIHRoZSBiYXNlIGlldGYteWFuZy1saWJyYXJ5PyBFdmVuIHRoZSBtb3VudGVkIG9uZXM/ DQoNCkRvZXMgdGhlIHNlcnZlciBwcm92aWRpbmcgdGhlIG1vdW50ZWQgbW9kdWxlcyBjbGFpbSBj b25mb3JtYW5jZQ0KdG8gdGhvc2UgbW9kZWxzPw0KDQpJTU8gWUFORyBtb3VudCBicmVha3MgdGhl ICJZQU5HIEFQSSBjb250cmFjdCIgaWYgZXZlbiAxIHRpbnkNCnByb3BlcnR5IGlzIGlnbm9yZWQs IGR1ZSB0byBtb3VudGluZy4NCg0KSSBhc2tlZCBmb3IgYSBjb25mb3JtYW5jZSBlbnVtIG9mICdu b25lJyBvciAnb3RoZXInIGZvciB0aGlzIGV4YWN0IHB1cnBvc2UgYnV0DQp0aGUgV0cgZGlkIG5v dCB0aGluayBpdCB3YXMgcG9zc2libGUgZm9yIGEgc2VydmVyIHRvIGRvIGFueXRoaW5nDQpvdGhl ciB0aGFuIGltcGxlbWVudCBvciBpbXBvcnQgYSBZQU5HIG1vZHVsZS4NCg0KRS5nLCB3ZSBhcmUg YnVpbGRpbmcgYSBzcGVjaWFsIHNlcnZlciAibGlicmFyeS1tb2RlIiB0aGF0IGp1c3QNCnByb3Zp ZGVkXHMgdGhlIGxpYnJhcnkgYW5kIGdldC1zY2hlbWEgZm9yIGV2ZXJ5IG1vZHVsZS4NClRoZXkg d2lsbCBhbGwgYmUgbGlzdGVkIGFzICdpbXBvcnRlZCcgKHNvIHRoYXQgZW51bSBlc3NlbnRpYWxs eQ0KYmVjb21lcyAnb3RoZXInKQ0KDQoNCg0KMikgV2hhdCBkb2VzIGNvbmZvcm1hbmNlIHRvIGEg WUFORyAgbW9kdWxlIGUuZy4gaWV0Zi1zeXN0ZW0gbWVhbiBub3c/IERvIHdlIG5lZWQgdG8gbG9h ZCB0aGUgbW9kdWxlIGF0IHRoZSB0b3AgbGV2ZWwsIG9yIGlzIGl0IGVub3VnaCB0byBtb3VudCBp dCDigJxzb21ld2hlcmXigJ0gaW4gdGhlIGNvbnRhaW5tZW50IHRyZWU/DQoNCg0KSXQgbWVhbnMg dGhlIHNhbWUgaWYgdGhlIHNlcnZlciByZXR1cm5zICJpbXBsZW1lbnQiDQpNb3VudGluZyB0aGUg bW9kdWxlIHZpb2xhdGVzIHRoZSBjb250cmFjdCBiZWNhdXNlIHRoZQ0KbW9kdWxlIGNsZWFybHkg ZGVmaW5lcyAvc3lzdGVtIGFzIGEgdG9wLWxldmVsIG5vZGUuDQpBbnkgb3RoZXIgbG9jYXRpb24g aXMgbm9uLWNvbXBsaWFudC4NCg0KDQoNCjMpIElmIHRoZSBhbnN3ZXIgdG8gMikgaXMgaXQgY2Fu IGJlIG1vdW50ZWQgYW55d2hlcmUsIHdoaWNoIG1vZHVsZXMgbXVzdCBiZSBwcmVzZW50IGF0IHRo ZSB0b3AgbGV2ZWw/IEUuZy4gaWV0Zi15YW5nLWxpYnJhcnk/DQoNCklNTyB0aGUgWUFORyBjb250 cmFjdCBvbmx5IHN1cHBvcnRzIHRoZSBkYXRhIHBsYWNlbWVudCBleHBsaWNpdA0KaW4gdGhlIG1v ZHVsZS4NCg0KDQo0KSBJZiBhIG5ldyBsaXN0IGVudHJ5IGlzIGNyZWF0ZWQgY2FuIGl0IGludHJv ZHVjZSBhIGNvbXBsZXRlbHkgbmV3IG1vZHVsZSBuZXZlciBoZWFyZCBvZiBiZWZvcmUgaW4gdGhl IG5ldHdvcmsgZWxlbWVudD8NCg0KPz8NCg0KdGhpcyBpcyBmaW5lIGZvciAiYW55ZGF0YSINCg0K DQo1KSBJTUhPIGFsbG93aW5nIHN1Y2ggZHluYW1pYyBpbnRyb2R1Y3Rpb24gb2YgbmV3IFlBTkcg bW9kdWxlcyBpbnRvIGEgbmV0d29yayBlbGVtZW50LCB3aXRoIGZsZXhpYmxlIG1vdW50cG9pbnRz LCBmbGV4aWJsZSBzZXQgb2YgbW9kdWxlcyBhdCBlYWNoIG1vdW50cG9pbnQsIGEgZmxleGlibGUg c2V0IG9mIGRldmlhdGlvbnMgYW5kIGZlYXR1cmVzIGZvciBlYWNoIG1vdW50ZWQgbW9kdWxlIG1h a2VzIGRpc2NvdmVyeSBhY3R1YWwgYXZhaWxhYmxlIHNjaGVtYSB0cmVlIGRpZmZpY3VsdC4gSSB0 aGluayB3ZSBhcmUgcHJvdmlkaW5nIHRvIG11Y2ggZmxleGliaWxpdHksIG92ZXItY29tcGxpY2F0 aW5nIHRoZSBpc3N1ZS4gU29tZSBtb3JlIHN0YXRpYyBtb3VudGluZyBzb2x1dGlvbiB0aGF0IGNh biBiZSByZWFkIGZyb20gWUFORyBtb2R1bGVzIGluc3RlYWQgb2YgcnVuLXRpbWUgZGF0YSB3b3Vs ZCBiZSBlYXNpZXIuDQoNCm1vdW50IGlzIHdheSBvdmVyLWVuZ2luZWVyZWQgIGJ1dCBzY2hlbWEt ZGVmaW5lZCBtb3VudC1wb2ludHMgZG9uJ3QgcmVhbGx5IGhlbHAuDQpBIG5lc3RlZCAicm9vdCIg d29ya3MgYW5kIGhhcyBhIHVzZS1jYXNlLiAgRXZlcnl0aGluZyBlbHNlIGlzIGV4dHJhDQphbmQg YW4gaW1wbGVtZW50YXRpb24gY2hvaWNlIHdpdGhvdXQgYW55IHJlYWwgdXNlLWNhc2UuICBZQU5H IGlzIGFscmVhZHkNCmNvbXBsaWNhdGVkIGFuZCBzbG93LiBtb3VudCBhbmQgc3ltLWxpbmtzIG1h a2VzIGl0IHdvcnNlLg0KDQoNCnJlZ2FyZHMgQmFsYXpzDQoNCg0KDQoNCkFuZHkNCg0KDQoNCg0K LS0NCg0KQmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uIEh1bmdh cnkgTHRkLg0KDQpTZW5pb3IgU3BlY2lhbGlzdA0KDQpNb2JpbGU6ICszNi03MC0zMzAtNzkwOSAg ICAgICAgICAgICAgZW1haWw6IEJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbTxtYWlsdG86QmFs YXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0KDQo= --_000_E6BC9BBCBCACC246846FC685F9FF41EAD253ADszxeml501mbxchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FtYnJpYTsNCglwYW5vc2UtMToyIDQgNSAz IDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiu vuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLmhvZW56Yg0KCXtt c28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0 IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YW1icmlhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgdGhpbmsgb25l IGltcG9ydGFudCBxdWVzdGlvbiBpcyBob3cgdG8gZmxleGlibHkgdXNlIOKAnFNjaGVtYSBtb3Vu dOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPkN1cnJlbnRseSwgaXQgc3VwcG9ydCBtb3VudCB0aGUgbW9kdWxlcyB3aGlj aCBiZSBsaXN0ZWQgaW4gdGhlIGlldGYteWFuZy1saWJyYXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QnV0IGhvdyB0byBl eHRlbmQgdGhlIG1vdW50PyBPciBob3cgdG8gc3VwcG9ydCBvdGhlciBtb2R1bGVzICh0aGVzZSBu b3QgaW5jbHVkZSBpbiB5YW5nIGxpYnJhcnkpPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYW1icmlhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5PbmUgZXhhbXBsZSBpcyBkcmFm dC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNlLW1vZGVsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9kdWxlOiBuZXR3b3JrLWRldmljZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7LS1ydyBpZXRmLXlhbmctbGlicmFyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgaW50 ZXJmYWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBoYXJkd2FyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBxb3M8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstLXJ3IHN5c3RlbS1tYW5hZ2VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYW1icmlhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IG5ldHdvcmst c2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgb2FtLXByb3RvY29sczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FtYnJpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkRvIHdlIG5lZWQgdG8g bW9kZWwgYW4g4oCcb2FtIHByb3RvY29scyBsaWJyYXJ54oCdIGZpcnN0LCA8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYW1icmlhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5hbmQgdGhlbiBhdWdtZW50IHRo ZSBTY2hlbWEgTW91bnQgWUFORyBNb2R1bGUgdG8gZ2V0IGEg4oCcbW91bnQtb2FtLWxpYnJhcnni gJ0gdG8gc3VwcG9ydCBtb3VudGluZyB0aGUgb2FtIHByb3RvY29scyBsaWJyYXJ5PzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJlc3QgUmVnYXJkcyE8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYW1icmlhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4tTWljaGFl bDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXQ0K PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7ku6PooaggPC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkFuZHkgQmllcm1h bjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe2 6Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDE2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+NTwvc3Bhbj7mnIg8c3BhbiBsYW5n PSJFTi1VUyI+Njwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDI6MDM8YnI+DQo8L3NwYW4+ PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj4gQmFsYXpzIExlbmd5ZWw8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gbmV0bW9kQGlldGYub3JnPGJyPg0K PC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+IFJlOiBbbmV0bW9kXSBTY2hlbWEgbW91bnQgcXVlc3Rpb25zPG86cD48L286cD48 L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPk9uIFRodSwgTWF5IDUsIDIwMTYgYXQgNzo0NCBBTSwgQmFsYXpzIExlbmd5 ZWwgJmx0OzxhIGhyZWY9Im1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20iIHRhcmdl dD0iX2JsYW5rIj5iYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkhlbGxvLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4xKSBXaWxsIG1vdW50 ZWQgWUFORyBtb2R1bGVzIGJlIGxpc3RlZCBpbiB0aGUgYmFzZSBpZXRmLXlhbmctbGlicmFyeT8g RXZlbiB0aGUgbW91bnRlZCBvbmVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+RG9lcyB0aGUgc2VydmVyIHByb3ZpZGluZyB0aGUgbW91bnRlZCBtb2R1 bGVzIGNsYWltIGNvbmZvcm1hbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRvIHRob3NlIG1vZGVs cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklNTyBZ QU5HIG1vdW50IGJyZWFrcyB0aGUgJnF1b3Q7WUFORyBBUEkgY29udHJhY3QmcXVvdDsgaWYgZXZl biAxIHRpbnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cHJvcGVydHkgaXMgaWdub3JlZCwgZHVlIHRv IG1vdW50aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+SSBhc2tlZCBmb3IgYSBjb25mb3JtYW5jZSBlbnVtIG9mICdub25lJyBvciAnb3RoZXInIGZv ciB0aGlzIGV4YWN0IHB1cnBvc2UgYnV0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoZSBXRyBkaWQg bm90IHRoaW5rIGl0IHdhcyBwb3NzaWJsZSBmb3IgYSBzZXJ2ZXIgdG8gZG8gYW55dGhpbmc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+b3RoZXIgdGhhbiBpbXBsZW1lbnQgb3IgaW1wb3J0IGEgWUFORyBt b2R1bGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5F LmcsIHdlIGFyZSBidWlsZGluZyBhIHNwZWNpYWwgc2VydmVyICZxdW90O2xpYnJhcnktbW9kZSZx dW90OyB0aGF0IGp1c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cHJvdmlkZWRccyB0aGUgbGlicmFy eSBhbmQgZ2V0LXNjaGVtYSBmb3IgZXZlcnkgbW9kdWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGV5IHdpbGwgYWxsIGJlIGxpc3RlZCBhcyAnaW1wb3J0ZWQnIChzbyB0aGF0IGVudW0gZXNzZW50 aWFsbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YmVjb21lcyAnb3RoZXInKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT Ij4yKSBXaGF0IGRvZXMgY29uZm9ybWFuY2UgdG8gYSBZQU5HJm5ic3A7IG1vZHVsZSBlLmcuIGll dGYtc3lzdGVtIG1lYW4gbm93PyBEbyB3ZSBuZWVkIHRvIGxvYWQgdGhlIG1vZHVsZSBhdCB0aGUg dG9wIGxldmVsLCBvciBpcyBpdCBlbm91Z2ggdG8gbW91bnQgaXQg4oCcc29tZXdoZXJl4oCdIGlu IHRoZSBjb250YWlubWVudCB0cmVlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pkl0IG1lYW5zIHRoZSBzYW1lIGlmIHRoZSBzZXJ2ZXIgcmV0dXJucyAmcXVvdDtpbXBsZW1lbnQm cXVvdDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TW91bnRpbmcgdGhlIG1vZHVsZSB2aW9s YXRlcyB0aGUgY29udHJhY3QgYmVjYXVzZSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+bW9kdWxl IGNsZWFybHkgZGVmaW5lcyAvc3lzdGVtIGFzIGEgdG9wLWxldmVsIG5vZGUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkFueSBvdGhlciBsb2NhdGlvbiBpcyBub24tY29tcGxpYW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIj4zKSBJZiB0aGUgYW5zd2VyIHRvIDIpIGlzIGl0IGNhbiBiZSBtb3VudGVkIGFueXdoZXJl LCB3aGljaCBtb2R1bGVzIG11c3QgYmUgcHJlc2VudCBhdCB0aGUgdG9wIGxldmVsPyBFLmcuIGll dGYteWFuZy1saWJyYXJ5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SU1PIHRoZSBZQU5HIGNvbnRyYWN0IG9ubHkgc3VwcG9y dHMgdGhlIGRhdGEgcGxhY2VtZW50IGV4cGxpY2l0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmluIHRo ZSBtb2R1bGUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyI+NCkgSWYgYSBuZXcgbGlzdCBlbnRyeSBpcyBjcmVhdGVkIGNhbiBpdCBpbnRyb2R1Y2UgYSBj b21wbGV0ZWx5IG5ldyBtb2R1bGUgbmV2ZXIgaGVhcmQgb2YgYmVmb3JlIGluIHRoZSBuZXR3b3Jr IGVsZW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4/PyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+dGhpcyBpcyBmaW5lIGZvciAmcXVvdDthbnlkYXRhJnF1b3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+NSkgSU1ITyBhbGxvd2lu ZyBzdWNoIGR5bmFtaWMgaW50cm9kdWN0aW9uIG9mIG5ldyBZQU5HIG1vZHVsZXMgaW50byBhIG5l dHdvcmsgZWxlbWVudCwgd2l0aCBmbGV4aWJsZSBtb3VudHBvaW50cywgZmxleGlibGUgc2V0IG9m IG1vZHVsZXMgYXQgZWFjaCBtb3VudHBvaW50LCBhIGZsZXhpYmxlIHNldCBvZiBkZXZpYXRpb25z IGFuZCBmZWF0dXJlcyBmb3IgZWFjaCBtb3VudGVkIG1vZHVsZSBtYWtlcyBkaXNjb3ZlcnkNCiBh Y3R1YWwgYXZhaWxhYmxlIHNjaGVtYSB0cmVlIGRpZmZpY3VsdC4gSSB0aGluayB3ZSBhcmUgcHJv dmlkaW5nIHRvIG11Y2ggZmxleGliaWxpdHksIG92ZXItY29tcGxpY2F0aW5nIHRoZSBpc3N1ZS4g U29tZSBtb3JlIHN0YXRpYyBtb3VudGluZyBzb2x1dGlvbiB0aGF0IGNhbiBiZSByZWFkIGZyb20g WUFORyBtb2R1bGVzIGluc3RlYWQgb2YgcnVuLXRpbWUgZGF0YSB3b3VsZCBiZSBlYXNpZXIuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5tb3VudCBpcyB3YXkgb3Zlci1lbmdpbmVlcmVkICZuYnNwO2J1dCBzY2hlbWEtZGVmaW5l ZCBtb3VudC1wb2ludHMgZG9uJ3QgcmVhbGx5IGhlbHAuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkEg bmVzdGVkICZxdW90O3Jvb3QmcXVvdDsgd29ya3MgYW5kIGhhcyBhIHVzZS1jYXNlLiZuYnNwOyBF dmVyeXRoaW5nIGVsc2UgaXMgZXh0cmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YW5kIGFuIGltcGxl bWVudGF0aW9uIGNob2ljZSB3aXRob3V0IGFueSByZWFsIHVzZS1jYXNlLiZuYnNwOyBZQU5HIGlz IGFscmVhZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Y29tcGxpY2F0ZWQgYW5kIHNsb3cuIG1vdW50 IGFuZCBzeW0tbGlua3MgbWFrZXMgaXQgd29yc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyI+cmVnYXJkcyBCYWxhenM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM4ODg4 ODgiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiM4ODg4ODgiPkJhbGF6cyBMZW5neWVsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVy aWNzc29uIEh1bmdhcnkgTHRkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM4ODg4ODgiPlNlbmlvciBTcGVjaWFsaXN0PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 Izg4ODg4OCI+TW9iaWxlOiAmIzQzOzM2LTcwLTMzMC03OTA5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGVtYWlsOiA8YSBocmVmPSJtYWlsdG86QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tIiB0YXJn ZXQ9Il9ibGFuayI+QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPC9hPiA8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2Q8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E6BC9BBCBCACC246846FC685F9FF41EAD253ADszxeml501mbxchina_-- From nobody Thu May 5 20:48:46 2016 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 00AF312D108 for ; Thu, 5 May 2016 20:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.215 X-Spam-Level: X-Spam-Status: No, score=-5.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_RATIO_06=0.001, 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcV15xGdupj8 for ; Thu, 5 May 2016 20:48:42 -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 A4EFC12B00F for ; Thu, 5 May 2016 20:48:41 -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 CJH39302; Fri, 06 May 2016 03:48:38 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 6 May 2016 04:48:37 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 5 May 2016 20:48:33 -0700 From: Linda Dunbar To: "'netmod@ietf.org'" , Dean Bogdanovic , Susan Hares Thread-Topic: Is there any common module (like library module) for matching all IPv4 or IPv6 header fields? Thread-Index: AdGnSivmLLx0IgKPS1WS7wjcSUgVAg== Date: Fri, 6 May 2016 03:48:32 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E81CA0@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.230] Content-Type: multipart/related; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F657E81CA0dfweml501mbb_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.572C1417.000E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: faf23369bebe28e888a3d6fa1b740ffc Archived-At: Subject: [netmod] Is there any common module (like library module) for matching all IPv4 or IPv6 header fields? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 03:48:45 -0000 --_004_4A95BA014132FF49AE685FAB4B9F17F657E81CA0dfweml501mbb_ Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E81CA0dfweml501mbb_" --_000_4A95BA014132FF49AE685FAB4B9F17F657E81CA0dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear YANG Model experts: Draft-ietf-netmod-acl-model-07 has matching criteria for Destination Addres= s and Source for IPv4 and IPv6 respectively, like: [cid:image001.png@01D1A720.430CA7F0] IDR FlowSpec also has defined YANG model for matching criteria for IPv6/ I= Pv4-prefix plus other header fields. I2RS Filter Based RIB also define vari= ous header matching. Is there a common library module that can be called when any IP header fiel= ds need to be used as matching criteria? Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657E81CA0dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear YANG Model experts:

 

Draft-ietf-netmod-acl-model-07 has matching criteria= for Destination Address and Source for IPv4 and IPv6 respectively, like:

 

 

IDR FlowSpec also has  defined YANG model for m= atching criteria for IPv6/ IPv4-prefix plus other header fields. I2RS Filte= r Based RIB also define various header matching.

 

Is there a common library module that can be called = when any IP header fields need to be used as matching criteria?

 

Thanks, Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657E81CA0dfweml501mbb_-- --_004_4A95BA014132FF49AE685FAB4B9F17F657E81CA0dfweml501mbb_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=42974; creation-date="Fri, 06 May 2016 03:48:32 GMT"; modification-date="Fri, 06 May 2016 03:48:32 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAYkAAADrCAYAAACclmpYAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAKdeSURBVHja 7P13eFZHuuaNzh/nzJxzvvn2zLdnXzM7ddzd7dRux3bG2AYjcs5RKGeUs4QiCiABQgIlJJKEJJCE QIASIBDKGeWcc85Zv7Pe91U22ODddmN73RfrusRbtaqeeqrquSutp/4L8IXw2PzSn7Jr+jZ/eF/f 5mHH1E9Q/gmbpJPyNr/9x3+0+cd/+O82b+91sSkb+p5pTRTZ6H6+0ma/4z2biR9U5jGbno4um6Gx 59f3SE2sjcoH/2Dz//nHvTbhJUM/im778i/brP7LP9r8z//+jzafq0TaDPzIdTvRlm5js/Mjm/8p qVvh+eeNxjapHYvjtNw7afP+n3bbRFVNvFj6Hek2Cmv/LE33v//TqzbyQUXf3keCzG0+EOL+wz/8 b5vdl3P/5mWdKgu3Wa1/3Ca2YeQXb49epue/zPzxi8dEdSzH3COpGJz+Sco/PT3F1NQULYneGJrZ k93zfVMaI8bbh0uxZUz+YNKOknZGh1dffx/L+y0vUkqmetPQ2GVDcE7fj6rfwnAPtitfo/tHrtc8 dzPs3O8ItTKjgYlRxiaWtNG2LE46XuRJ54vW2LS0zUxNtBNw2pRdAbnP8c4kcd7qHLqc+bdvw+Xh yOkdJ7ZhVDRILxF+QJIYpyI5AgddHXR0TDgd+oCM+yFYORwjsrKXvsJo7HSPYGBxnISGEegp5aqb BUdM3Ego65lJY4qGrNucsDYU0tDB2PUCmXVD0pDWzOtY6BngcjGDQWnbbeamozmG5i48aBxjvCaB o0aGOHkmUFz4kDM2sjTsA+NoXtAGh+pS8TbUQdfIArfAJDom5sP6KxOx1tXH+cJdigrTuOhqKqRh wOmoLAYWlLS/RkjD1kSavqXXdVLTHnDW1RyX6HwmnqdzDLeTcy+UE2a60jTMnC/xpHVkSaw+sm4F YKEj0aclpwOvcu3CDUo6xxfF6kz2w/h7kcQIudGeQtp6mNue5n5R+4KwAdL87NE3tickvYjMaF+M JHIYOHEjs1EaozEtGCN9fYyMjTgVlsqwpI6yb2JhZIShgS5ON7OYLVFb2hWsNLTZr7EH83tNLybm UDY6B45xKT6NW4Eugry6nAxJpXtqQZypLjJu+GMlkVHvKAExhVJ55lpmTy0PI89jp68jfd/R5zb1 SwYHw/UZ+LmYo3NET2gXd4i+4MFetfB5kpjqIfOmPxaSNI4c5WJM/oI20UdykCs6QtuxCLhDm2C7 23JucUz/iNA+oqkfeo420V/FNXcDNr3zFp9+tQMdQbf6+q5EZ3fOF7OzQJDREF0DU0743X16uv21 3L3gJm1XR8yPczOn8SmRerjoaf5MkmjJvYu7ldA2j5jjE/mIUG9tFIKz58JHm7I472wuzcPQzo1z gRcIfFzN1Is2wcpIVum6crdeJIlfAEmMkBnihraGHg5ufgQKjcbL2YRPX/lH/nW3NZmtQww35BAe cAr57Z+z2fo058+44n7WBxdzC44FpAsUM03hjZMoqBngeOqskMZ5jtuZo6VlRXRRD31VaXgZ7OPt VZ7UznTarNDT7Nq0HO2YJibbC7jqrMIr/+VXfL5TD9ez/kIanlhoqqJlFUDpTIca6ygn/nIg54+p 89aHViR3zpv1kdZigpzUePfXf2DV4aN4BQiN38eOXdt18YlvkBm87BuCwVPF2NFTSD8Q/3MnOPjl H/hv76zlXFrdc43GxxoyueJ3ijO+lwgLC+OsjSbbj16guGemm013cNfDAnWhk57wCiTQz4/jlsp8 +ft1XClcbBnaHvlg9L1IYpyanFihDD7ofrEKw5P3GVlQnxUCiels/Av/7fefoWZ1HF+hrOdP2nL4 gC5nbxTTXZGM71ElVnzyNS5xFdKRb59A1EorV7JyuzkRWVVSwpxqfMxRS3uup2Rw/rQOpnENL0gS +WjKLefdtWq4+Qr1EeCEwteH8Y6tQmrmJ5u46e6ItY0bgcFhhFzyw9HUkBOR2XPl6SqM45yXB74B VwV9X8TJWJWDHrF0zVRWb/Ft9BW0sXDxlOrD/agWn/7pHb5Uui4jgvEWYbZlg6HDKS4EhREW6I2t lQWOQbNEOEzZ45ucd1Tlrzt2Y3PaEzfhCfA+gYGOE7fyO55j4NBGWvQFjNbJsf2AMT6CvgMDb5Ap DLDmSKK/nntRV/BzN2HH+/u5VbN4SDLdkYenow1WTme5LLSrKwGnMdO0JeRxzWIDPtVJoIfZU0mi Ku4syhoCkZ72JtD/LHbaB/jz26+y62KONHyyJQMHTSOsnD25EiTI4nWcA5s/4zWzW4y/YAscy7/A JmGQmNL2w81hRbwkJDFeEY2+gSGXF4x6GKvHU0OObd7JC2JOEG63jdfXmxNb2Dwz6p5ioG+YsZpY lPcZczl94XLEEI997dHUvEibJMm8UHbsC6BmLryHy6c1MbhbJ/tvzR32/3El9rer5pPoysRYSRv7 GzNGZRbt9zmw3Z3ktiVNu+42BgqHCMjomok/RoS6OUePpTIx1cwFR3VMrubPLQdIwlPOKPK5thvV z91LJuhqrqboSRElJSXkxnmy4msTbpQOzhj+c8jrOvJwwQhruisXbzUrYisHn5MkJumqLyYlJWXu ycqtY/Ap/THVxgSXMwkMLvk97pQ6r621I79vXnMVkcfYq+dMvnSo3sgZB3u8E1tlgc3puFnZEDmj /umxZqLPnMT7boNUT0GeOhxN7V+cydQwNcW5i+QsqGmfNzgD2WhslMf0Quac0X/sooKBzz0pIbcn nUVRXhPfqEfkFZcIs8gc7l09xu5lpiQ1zepvmObacgoLigV9F/LosjWfrXejUJLgdDuhhkewDUxm Ttvj1Rw/uJaPFUKlOunOusDmvbr4304iv7CEksJsYi8e4+BBdW7XLVBo130Orv2CHVahVPbNtJDR IQaHx6XtvLuhfFE5Mwuq6BtfWhemnArI+A7iLODMDm3u1IwtNLlkejtw6IAl1x+kUyS0q6K8NCKP a/KZli8Vg99NEtM9WVhqmeAZO99/ptoeobHyLXb6yWTqz73Al1v1CX/SyvjkNJOj/aTcPIeeMNN4 EVM/1lPCeV0VzLwT6H3hKYiInxxJ9CR7o2YiGKrhxb+n+Wmw0yt+fglGGJFdcFVC7XrZN9JovefC OvsL1C/pNCNl0dhq6/OwSxjxpVxg695A2UxC2gEb8DuuimFMvUyO7Ej0lzuQu0iOYW6bOmBj94CF k9qJipvs3iqMYtoXZ9ibG4KFiTnJXXO/EKVpg5NzGsOjJRw3UMCnaHGrHkw5zXZzV3KfawF7mq4n iXhb63Jg63a2b9/O1jWf8uvXNbldJev0aW7G2J+5zfBzpPZskhgmLcRemv7so3zkCtUj34wXb6qH k+c9Fs9R+rh6xowtZ5asRbclsM/UlqulsoSKr7hhZB9Eh2AwCiI80DEKY3aoUH7DlZUfr8Hcwwcf L0d2CyPOVToniM2omyeB8UYu2B9ZIOcOLAIeMMdL/Rlo7rEnNHd2RD1FiqcWRufvS/9X4GOI3Fuf sX3vLnbMvL9r924OHHYltXFMajzrE8NxNlBjzxZZHuuWv8frX7hQLKnGgTS0t9gRXbKYIlMv2vG1 0jWpTsqvGfHqZ1+xe89MHjt2sFvIY5eOPfca5g31REkYh01Niax+2j7XKJnXTi6qDwUzHwp7nqcu lqTUnMLxrVpLSKKbIKPDvPnXtezdvVOWx46d7BFk3m8aTNXId5PEcI4/O2zcyVjUjvsJdxT0eSF9 ppDtxHuZoqiuy1E7B5yPn+DEKT8SKjp4EXRnX2LfR5s4l/iCy48ifpokQU8BLsKowMjjLk3SdjtB Tcpltr33O74+Eb9gBN/B5VNq6N6t/0YSg8IIZauSK+ntiztY84OLGCo6Skd9XY/82bg7gLlV1rFq Th89jEm8rKH1515D4V0FIqoWGP6pOs6YW3LsauniKXfNbfZuP7WkQwhyFFzD0tiMx53zneSmti1O LhnSTpxwzpj9Op7ktMo6aH91Ovbb3+J3u+0oex6rPlyBk74uZgGp88s7NZFsXWVGVIXsl8pr9qhY +1OzdINjaozRqcX66Urxx8TCkfzB71t5EzwwN8D13MMlywX9XHPRZpn2tUUzjMGsi6hbuPJ4Zolg uvMhZtp2hN9Pxf+oAW4pHXNk2JQbg4O1FeaC4TQ30mT1l+/w8R5DriaUMva84g3noL3Xnqs58xWV 6qUtzCweSv+uDXdG3yWIzme93/kYdXl9vB9Uz/PcfU/kNrhTKNHvWAkOO3U5n9iwyFhHOarxhXK4 dGDRdE8w7laRTzfc0wvqoyIcZVsbYpq/b12MP6MuljSD9gzct+sQ27CwLQxw28EOO/ekZ7y1MG4v l7ws2HOxYHHuVZEcEAZE0eULh1P1eCh/zb4LWbL6r88kICGLqvpaYSacS2Z6Elfsddizy4/6iRcp 6zC5F2xRsL1A9RAifvYkIWl2JY/wNNcQjN06NqzbzEF1Y5T2f80W74dS4zw5Okh3SyEnrXZxUBiV dHR00NE9yPis5R5rJdROj0Nm53hUUCOEt1KYeB0rFXXcr5VIZyODRTdRXa5EQFIZHa2V3D2jzR9e ex21sGKGxqYYLQ1nw//4dz49cJyHJQ10tJUSdcoaeU0PsvplLXhiZJBOIe+WtAusWWlFdHGzkFcP w8L70xMj1Nw7h4aSKhHF/YxNTjE2XM/5/UcwNLxJ18gUk13V3PKwZN+mTWzYsI4tinoYKK7nE6OT FD3PAZzxSlx1jqB7OoGWrg5KH9/AzWALv3lVmSsZLYxKpvB9+RzXVULfLYTsihY62mtJjvLHWtee hFoZE40P90nLUXTDGWV1A+KEkVxHVy8jE895Wmt6gsGeTqHs9YSqCURrf406Ib3uvqGZZYNR7rjs 4f/+t48xv3Sf2rYO6rNvY6qths3VTEan5w1b6mlzYVa0mR1q52l4lqEYreG0/SH0njJAeKaIk2P0 18ewf40uZ2KrpPUxPtTDLdv9qJy4RtvQOFP92ThramHrHU1Jk6CD1hrSYoJxsz5JcosgTE8qWvt0 cbuRT1dnE9m3L2B0QI4/fGDF45YBoV1NUBzmwl5FW26mlgr6kMQ5zfJ//3de3+pD08AIk71Cuz2i ipn/Xcoa2qX1kXH3EvZup7hbKamPKUb6e2h57MN2bS0uZrcJ6XTSOzjGc5+dmxpnoKdhUV10dHQz ODq/iDM5OkSP8HtjQTQWKw9wJatJiNMlxJEpfajwJnqqRzh5PZkGIV5bfRn3r53Dyi6Uyv4paR59 PV3SfuFuq85qtwRpP+zsH5YNoKZ6uXXCUJgNefCwsJ6OlirifQz4w7/8P6w8cY/+4Qk6Hh7n/7y9 DdeoTFp6BoU21MAdHxv2ql+l7UWXjaquIafvTFzDi+5miPhJkoTMAvdTW1JIYWEpDd3DZIUZsNP7 nrSjND06z+ENK/nskw/48PMVyMnJsf7wOcGwznej6eEabnk7cHDrGiF8FTsUTAiMyZ9fdpkaIv+a OweEdOQ2KeDocwlX4y189IUiFx+3MVQZi8GHOrifPY7itrXIrZLjsJk3WbWzQ5VpymLOsUnIe9WK z/nr+5/w5cpVQl46hGV1M1B9F/lVy/joo4/4Ysdxshp7SA134PMPP+aTjzfiert4trvSVl0mlLOQ ciFOV6Y3ux3cye58LtNHX2kizqrb+Voo415jDxLuRaG7cwMrNpjzuEnW4ccas/G302HDCkG+Ves5 qO1I2INC+kellEt+qD1bhHKs/OIzQd6P+fJrOdbsNuBW2cDz1dVIJRfUt0j1vPyjD/nk0y9YJaSn YnGVRqldGiDcz5QvDY9z1l6LtYIuv159GNewNLqW9Onp+ji0t+zF4Wbl0/mhOgHVfWv5VKj7j5Zv xOFS+nMtpY23pOOsLMeHf/2YrzZZkNrSR2GQKxs//ZCPPluD3tU8abzhqjR8bbTZJuhAbtVa9qlb czE6k+6xaamu6pNCMdy9VijfRrSOXSIx5hK7lq1gu/pZKiSCTPeTdt0T1V1Cm5Fbj4a5JxfOWPP5 B1+i5x6LZBdlrDkdH9sjbF0rqY/V0jwC76TRLq2PLu64abDqq8/54OOPWS6pM7ktmJxL53nP7Ux3 F+J5ZOuiupCTU8E3fn6G0/zoAuqStrvySz55/8OZfA7im1A91y7rc+/idEReaFtCvNWbUTZzI/Jx JSOSOu0rwkFvryD/13z26Uf89bMvpf1wu3MUc3vHw7Xckhh9IY7c6h0Yul3A21mR9z/bhlNYBb3V t9ijoY+xoSY7hTYh9/Vm1OwCyPzG6bznQEUEq3SPEyOebvplkMRQbxc9/QutRy8hpgfRupwmHaVM T00yPjbO5NS0MIgdZ2xsjLHxiUWz9VlMzoRPTD59HDYlDZ+YG6VNTcj+nqq4j9XXZ5kdq0ryWTq4 mZ6amM9bCJ2Q/D0jlxDI+Pik9Cz5hBA+JQg3NSmMNaXfJExI5ZkYGRBG8IunDIWBZuy39KbqhabN k7IyTs2ThyzPxYQyJ98SVUjkkpZjQibv+DPifRtZTY6PzcgwNZeepPyzSURfdmBPSPVc/PHx77nD KNWrTMeSupuYnHru9yakbUSYwU3I6mN6UlYPEnnHF6WzQAdTT2000vLN62cm7W+0qwVxpieZECpo +ht5LKy3GV1K3pXoTtp2ZHHGJ6ZeSEeS9xbWxVy7nIsyKctf0k6k7UWWz+SSJUiJ3LPvLwqaXvCO oKTpyfG5NrS02cjaxoL+M6P3hXnM6vv77jtPl4axwsCNhJYJRPzsSWKa6qRr2GopsuewMqqqqigp KaNj5Et+0+CPUrC+0hiM96/g1f/5DlsU1FB3CaF04G+fz0B9Br5mWuxXUJCWU0VFEUUVO26m1vHz aer9pPiY89VHb/AvH29CTU1XGK2W8dP87FDES4umePYeNOdKVruoi5cIP9hMYqS7iSep97geFkpo aCgRd5Ko7v3xzOZIWwl3oyOJjr1FuESG+CxaRv72Zm1qpJea/FRu3bguLWfo9dtk1/7Y3+X+0Bil OjmWqKho7kaFC+UM53FJK+JJRRF/287Uz0NvO/ZuUedafpeoj5cEolsOESJEvDyYHKS1voHOIXHJ 6WWBSBIiRIgQIeKZEElChAgRIkQ8EyJJiBAhQoSIZ+InQhLTdFfkcC8mjgcpOTT2v4Qf20z1kn8/ hpSKH3DDbaKHvEf3SC7uePnKL0KEiJ8lfjIzibKI02ju28oHn36CQWzDyyfgeAFmH/47671SvsfL Qzy5EUlyUdu3RxvOR2f1MtYcTRZbrggRIn4U/MSWm0YI89JE93b1SyhbL3kxESSWf59RfifB++Vx D33y7dGE2UrWA2E2VSDOJESIEPHj4OUmidEGbvvYsX/LGtas3if1729ieRij2BlX4ExRn3ETB42D rF2zBrk9R/CJzmHe+fQUnUW3sVDexRohfONOBTQO62NvG0fPbJTpEcofXEZv71ZpnB0q+phqGuBx MVnqVC0t1EHIexVfbHLgUXUrJQ+uoL1vDSt2mRNXNcI0g9z1MmfN2vVs3HUQ90d18/JPdHLTQ5Wv v9yF46lg/E4YsVHIY/XmAzgGpTAg/WJ1jAxfaz791a95/d1lUhkkzzrzi1TMfbE9xCN3XTavXcfG TWqcfRpJTnaQFHoa1T2bZO8fNCAwvkhahqHSm6huX8XqjTZcjQziqKKgj9VyqNgHUTkgfu0gQoSI Z+PlJQnBwEYcO4K8tS+PCyqoKUrnosVO/uX3bwgkIfP72pYdjo2BC7ezKugZGKCx8CFn7azxvV0l dUo3Vp+E025lzsbl0dzWSn3pY04dOsBWOW9kt1SMU3j3DCrKRlyMzaampoaSnBgsV33FXs1LSHYX hnrbqCmMYvfy7ezRssDR6zoZpQXEXwkkOrNeyGeK/s5W4d1CvK13sPti1nwZpifp66zEd99y/ukf P8LiUhxFQh6lWXewP3wQ3cBkJDQz3FXGud37sD0XQ7UQLpGjprWbsTn7PcVgRzO1NTm4ax/hsN3j xV87T/Zy96QZB/ROcOtxvvB+NemxV7FUUefE9WLGxvtoSD7P6v/xCnJap7mfU0pN8UPsDQ+jfb1E 7AUiRIh4Jl5akhgqDGaf9kky2xeMdDtT0Nu+Av27EpIYJsp8Kyv2auHs4oKrqyuuLs4c2bmRLVu8 kHhnHm9MwlRuP8bn75D1pJCS8ipy4+K4FZYvdXc90fOEU7oquD1evHzTmHib2zcz52ck44Vord7M QbubdDxz4D1GjK8Gh4Nzlvw+zC0tVQ5qXGHhlnZf7hW2bT1Odo/E3PcToabJuZtl36GVAa47OaLh lLKIJEZLw9h92Jb4msUOt5sSL6Kz34F8ib+0hgcYf2rFo9Y5N7vc8LdkjYe4vyFChIhn46UliaY4 RzY4X6Zp4UGm8Ro8THdiICWJDgIPrGeXpiUnXF1wdnYWyMIVdw8vIu4Vztw3PEZF6nVsrI/iYO+A g50tpsaWeEXmSb2OTjQlceKwNvEt3yFMfzoaux0Iy+v9lkgD3Dqr9hSS6OaaqhmOLimLb+pqe4zZ SjuSmqekcUKV1PCKKPoOQboIcbD7Bkl0JZ1ig60P5UtcqY7X38dZW4O7kvLVxGP8mSNpnbMk0U+4 ryUbvFLFXiBChIhn4qUliZGyCPYrWBNdNr/DMFIazu6vPsPskcQ30gQPPA0wuZLzjXdHBwekzvWG Sh9xRvMChV3DjIyOMTLUTU6oE4f2G5Emsfdj1fhaKmMUnLfoUpehphqqGtoX3PFcjO5+Z8KLvt2F 8b1AHVRvlC/5dYAbWntZtdWZsgXek0uiTrDT6Aoyr8jdhCge5nhY4Vz41Eg/nT2DS66AnODmCRd0 T+Yv+nWyPg7lA5KrXlsX/krBdQ90FE5RIWGUlmSslh8nf2g+rTuX7dkSkC/2AhEiRDwTL/HGdT8P /SyQ17HE++I1IkIv4ayzjX//9f/ha7OrFDQMMVj9EEclLaxP+nEtIoJrF31xNDbCzu26dM9hNPcK a/9/7yBv6831GzeJjg7jtJkZVkfDaJQOqKdpzriGobIipq5+hAtphAaewUhJHZfLSfQJhrapNJ2I K8f47C8bUHMMICIiksTMqvn7D8a6yXt8R/g9CMODn/KBhovwdwR3ssoZlOYxRLTeXl79t49QsfPk ihB2xccJ1d0mBKXN3qk3Qe5lc/aqGnPuqlCOoACOO1hh6f0A6WrURA/ZiTFCuhfR2ryJz7bZS/OI SaqYuSVunLzrbhxSMcLN55IQFk6ghzO6aoYEpzYz3lPFXV8zVv3LZuyvJVE/NE5PxQMMDq/lTweO k1XcITrrEyFCxFPxkh+B7SPrhg8GioooalkTdC+bR5EnUFO2IixN5k54pCmbQCczlCVxlIw5E3Kf mi7ZiH+0uYAwp/NcuuCJkYYQrqiGo3+MYCQX59JT8UggDx0hXBEVbQdCHpUwKF3PGSMr+qzwuzJq 6mqoKEvSUMLB9x7ds+s9A1VcOaEve1dVHXUVZenfev53aZf6KOslQsMOJ+tQbl09hbqSEM/AiTsF S9whT7SRcMEVFUk5dMzxiXxEbdcMFQ3XEuBgPJOHGmqqsjwMXWNpX3AjXHVypECSGtIwfdtzJJbK dkGGq+5ja6SKmoYqylYnSe0Ypib2HNpCWhqqhvjfKPsZuTUXIULE3xKiW44fGFNTbQTJm2B3LEVU hggRIn5yEEnih8REJ1Gn1fjojbd4551lrFq9DeNrT0S9iBAh4icDkSR+UEwx1NdFZ0833d0dtLa2 0T04JqpFhAgRPxmIJCFChAgRIp4JkSREiBAhQsQzIZKECBEiRIh4JkSSECFChAgRz4RIEs+JqdZs zjic42H14Au+OU7ZnSBsTU0xszyKd3Amfd8Su78iCW8zUyysbLmSVrPYkd/fohxtWXi5niOmuPcX WY+9ZfdxP2qFc8Bjun6kLwhb86KwNTfD2saT+PxOsTOJ+EnhZ08Skx1ZnFA3xOtmAWmRHuibhFA3 64NjvIkIF022b9/+zccigILeBVak7hZr39yKd8qL3uUwQX1qLOfPnuWY5n7Wvu9EybcZp65y7gb4 YXrwE5Y53WDkb80SjTdY99k2HGOb/+a6Hq55hMuBpbo0JDhFdpnScNUDnPcvDt+vakVYet0S9yPP VbPkX3XikJ4r6Z3Pr6SBumwuWB7klQ/syB3+cdrgcGMWVwLc2PPlZuRd0n/U9j9afR99XXNCUgqJ 83HA4GQ0nZOIEPHc+NmTxHRbAjve/Qxl7wzuehzkT1+4Uj1rpKeGacwKYcOu7exxjyIlJZWMzEzS rx/jtd0mhFaNSuM0VBaSk55Mwv0smvqf/m3yQFst+bm55OaX0jLw9OtVh7NuYfL1KYqf1kknBqgv e0JeQSltI1AdZ8/ec7dnvvyWYJy22lJyhTzyisqpb26huWfo+d1pCOVoKX1CToakHJnU9SyQcWKQ 6uJCiqtbGZ0ap6uhXMgnj+K6jhcy3pODHZSmp5AS58f+3+/AISBG0Gk+dZ2jM+Ht5AYa8Mkeec7c EuKlpBATchoVeQuupdbR0VhBfmExJSWl1HdKPoufoquplpKyEooKC6jpnrfqPYV3MF3zMf+xaT/B 5S/4vXhdLPv3+PKkp4+60gKhzkpoHVyaxiSd9RXSOs0rqqZrZFGrYmywh/rKEll9FFTSMfwUohrt pLwwjydFNQxN93PD7QRHjqctrBRB1xXkSdpNQRXdC0YEE/0dlAm/F5RIfpfF7agpJe9JGe0Dz399 71R5GJ/8YSUesRl4H97IJ/t9F3ylL0LEd+Pnv9zUk4HGvoOYhpeRed2KTxQvsuiS0NEyjGytcUyR LQJNTQhmsSGe/aau3KqblAzF8LM5zObNq/n8vb2EFSxdphmi8FEoFuoKbNi0mU2bt6Ng6Elaefc3 RGm+fxV9gSRKllje6Z5yQjwsObBzk5DPRvYc1kdFcQ0bPGORmtepfvIifNDcs4UNmzezYec+dm5b zfumoTz3vGaslmD9fUL6crzztgIBC2dE/cU4a2znL698wEFDR2wNlIR4a1m+RQPfxLoX9+s0UYTz l0eJLfumQ8TJ4iscdHQja95vI6luOhw9F0b0eUu+fOc13vjLV7jGVkiEJjHQjDd//Rrvfr6FE4k1 shf68jhtb0vgVT/0HEy5UjL6QuKNloSz/gt5zJwd0VXaw/qVqzigfZ6qgZmKmegjPcQLQ8UDgh42 s3bLfgycAsnvnfnGZaqLpAvH0Ti4S1of61ZtQ9M6kIreeePd35LLWYsj7Ni+mc0btqGmpcXm1YfQ 9ZhxSDneQ85NL3RUDgptRqjTtXvQdgkiu0VWlp4ntzHavIFlry/D0juWjNgQbLXlWb18FZo+Dxl8 XvZuvsfhjxUJyy4nyugIyjrX5y/cEiHiOfDzJ4mBJ2gZG2AeX09ZnDOfWN2YcSM+g758jlhZ4pQp GaW2EuF1nGihQ2XnFtK8aNZQj/8uZS6ltS5KvivvLjY6dlzPm/XFNE5+kDsazqFU9i/uyU8niV7i BII4bOpDwcxlFS3ZV1j/xj/zse1N2Ui+6S47dhgQlD1LPIMk+unxjsEVWl94VFiFtYIVJ6Nrl/ze iKf8Mr5S9iCzUTZiz/RzQn7fJdpeNIu+LOw+Nycq75tEOZTtzz57gSRmtnamewpxU1XjeHiBrGSp AWgc9eHJbCUJM0GjI8eIr5w1wN3cOeWIdWgho61JGNgaE/SCM4mxkmssf+MzlE7cplVi94cLcRGI 1ytZVtKmJD+MjU+T0TQ7c+ki7pw9Vk4Jsv2k6UHqCktomd2emq7FS38vZndqZP8faSbUQkNoA9G0 SkUbo/imA2/8619QOCv74r4+5QpHTNx4XD/7cWUH0efssD4XTceCiUKyzSFWfrEd69PXKZQE9FXy MLuEvuedTPRlYPmeMbHldcSZ2WJhcGdx+5dilNJ7IbidvkZRh/ixp4jF+PmTxES/MGUvprRjhKGO KlLLWhcvoQxXYKm2lteXr2frpi94893VBBQ9pQdOVOC9S4Ur6QtN5iTpPmb89ZXP2LF/N9u3bWPb 9p3s3/YVv/lKn5jaxR3uqSTRmoiOiSVBBYtHw/ec97LRNUrmrnywGFdDBeSNHDh/JYyo23EkxMZw p7CR8RfWRzEWh604fadu8e+DpfiYKOA/70ucqusBGG7wofZF8/gWkhgtCmGj3LssX7eVrVu3smXz Ho6cuElN74yhH6/mpLYpvgmSXKfJ8DqGqUsksmswJim95YWugSdP2gaFqruFmokOfgJ5jk08/3xn qOA627d6MKfyqRauHj2E6z2JV95xbpts4r3PV7Nnzy5pnW7fuZutcl+wcqUDxdIqnaY59y4Oeops k4Rv38Inyz5AOVzmJn6o5Baa25zJX7RE1cRxdRUOn8yVZMit4/v53Qdr2b9npzSNbUIeO+U+5hN5 a3LmJqvj3DNX4JC2JzXf13ZP9FCaVELH0AgdZRWUlbY/xZljF6E6K/i//mktwUUDolUUsQji6aaB IgyNNVHxiSM9ORx7I0Miy56yozle/hSSGCHxjB17D3qQlp9LZkY66RmZZD8poaahk5HJxcP8p5JE 7R2UTEwJqVhs5B57HGbziSiZS/JJyZ5BKjevXyXQzxuvsx44GGmiZxtJ8/gLTiXGi55NEkbynEuf XYaapizUD/3NftS9qE6/hSSG8y6wU0cb37uCrtLTySmooncJ01VHOKLqfJPuliccMzfHe+7mwD7C 7ZT46yefs3qtHKs+f49f//63vPmpAldSnn8jXkoS286Q2z+j8/EGLpsf4sSDJqQ3HhocFIgrhJzc bDKEOs3IzCK/qJSG9j7Gp6apfxyAuq4DV6LiSc/M5klyBLqH16IaLrtZsD83lP2bTlG6+JYpTutq o3AyR9purrursskhnLw8IQ9BDxkZWeQVlVHb1ivkMact4k0NcPN9/OKDgRfCNBMjA3R39TA0LjqN F7EYIklM12Dq5Ih74XyHmXqq3e3gykEdosoWLyG1PL6KkbIN8Q0LxmfDjaQ8yKaxZ/HsYDQ7Gou1 fixasBIMlJ+VHlput5k9HDnacA/FT/+Dr9weyH4oC2e1ggXB+fMXoHak+rP1Mxsyul/0qEozjmpO +D9eOmJsIchalUul8+ao7c5VLHZe/R5r2JWc+MqeB09jl6pQDp84R/m3vd6Xi6uSAQ4Othgb+1Iz MV83kxPjDA8PMTw6KWFddG2MuVr1gkRZH8fe3f6ClHMZcsNehXNZsn2pyjuuAnH7ULFgrDDaUkF2 Sh7dUxOkeiqx+8SdubCGpCAUdq9CJ15Ws1M9hZw6rIxtaP7cqL09w59lr3yC+gXZvKzszjkUdLwo XnCieqKjhIeZ+bTMn1Ygw9YcjwtZ31qcoeZi7t6KI6fu+x5rnqCxOItHGQvuSREhYga/bJIYbyPe U4tX//Jn3tqogLFLNE1L5uJDNcmcNdBBR3M/n/37f/DlNkV0dEy4GFeKdAVgqot7IafQUFRDVVsS Tx1VDQ3BeAVT0iEhiXFKogIw0dFBYeMKXvtfH7FXS4inc460WtnSzmDlPVxM1Th0UJK2Dkf0Ddix +nX+n79uwT20mJHaG3z0yResPayDoc4RdI9oC3noYROWzcBz2sfxpkxcTfQF+fbw5u/+wkdrD0nL ce6mYConG7hkr85nr/+WT7dZcTO7k97aB6iuXcZr/7wM8ysPeR4uGmnMxM9YKJvqDt75n2+yWph5 6ei4EJ0ro7/R+nS8DnzOr956jy2KOlg4hVD51NWNSZ74q/Hqn1bhEF3/1Lzan9zGWGkjr779BisO OhJb8HzfH/SUxOOo8DX/+i8foSbMVlpH+0g+a8lXb/6WD3aZEVEozH6Gm4h2tUJDTQNNoU61VdRQ UT2C4+kbtAh66C2NEsqoyGEVbfQNzLGxsObw9rf5w2odQpIks5FpGnIjMVRSRlFVXdC5Pqb6Gnzx 9p/54zIFQpOFMg02EONjiZKqJlpCnWurq6OuqoGpbxS1AnEMlD3CXUedDX9+jfc+2Yi6EEfn2DnS 275ZETVRFvzzf/kXFL/vLYMjxZiv/DPvKl6ZvydFhAiRJCS2qI8n929wLewaYUGXCIrKoWsJSYy2 lxF3OZDAC5cJCb/O1SsXCQwM5uGT5gVru6PU5tznygVJvCCikwroGpuaM3iNWQ8IDgzkUtBVrkWG clkaL46KBZuEY52VJIRJ0g4iLreevo5ybl8PIzqlkfGxDrIKnpCd8YioK7I87qSU8yJneia7q7gZ fElajrDwMEIlfwvliMtqlRLdo5vXCbkWTsiVKLKq+xnqKBL0EsK1iBChPMUzt+x9O8a7qrgXJMh3 8QphN64RfFlSnihyamRMMN5ZIRBqCOFhoVy5GEjIjRRaR56VVi1JD7Joe0Yhu2uyuHQ5iOtC3V29 HEleXf9z6WGw8Qm3woKJiAgl8k42vePDlCVES8seeu0WGQ2zO+q9FDy8I63TCxevcT+7koXnELrK Ugm9eIHgG4nU9o3RV5vB9eAIUkrml9gG6nKJCr4g6DyCrIo2OuvyuB4SSkrZzPLZdD9FSbe5JLSN C5dCuZdVxexJ3JHmEqIDLxB07RqhIUFcEOIE3oinsvebFTEq6Co9MZWKtqHv1Q36si+z7nU5TqWK H/qJ+CbE5SYRIn7RmCIryBq5g+eoFa8nFPEUiCQhQsQvGhPUFaQIs5t2URUingqRJESIECFCxDMh koQIESJEiHgmRJIQIUKECBHPhEgSIkSIeGkw1lbE7ZBwshoGRWW8JBBJ4meGydEhenoGGJv8uwpB X+/f+evd6UmGBBn6h8YQj/7/RDBaT4CJLgeV7HlY1S/q4yXBS0wSY2QF2bJ1/XrWrZFD7XgkbT/U Eb3pIfJuenJg0zrWS/Jbp8WlR00vnMxkVz5eChtZt1aOHS5Xafob+kob6mygprX3Oz2yNt5xYc8h Ax51/AB6Gh+gqaGe9u9yQdr0APVN6lxIa+PvhvE6vAxVUPfI+IEzmmR4aJixib8DFU0N0VTbQHv/ 38kpX9cTbLR3snq1PvFVQ//p5Karb7BWIIg7DaJrkJcJLzFJTDPY0UBpSQmJPvrI6zlQ+EP5Hmu+ i5KpGRce19De3k5tRRVN7d9vujsmGPO8UFO+MnQip+tvJ2JVjCMqwd99Yc1ouj/a2lakdP0Aehos xOWUNUHf5fFvtADLw2aEZP0QTPXcwhLiYoaRX+4PmMcEJQIpf/7mWk7fa/g7lLGGY9onCc0Z+fuo WCCphrK7mH++g4CU1v98jy+7xkoDN+KbxxHx8uAnsdzUmeiJkbXr00lipIlH1y9w0s2Nk4FRFDQv 8D4zPUpbeRaRl31xk4R7XyencaHxH6cy/RbHdLfx5tfr0Xf2wsvrLOHxhS/mw2a0neQbgbi5n8Q/ Mp2yR+c46OJBzoIPWEdai7l52UuQwx3/0ESalmQw1lpEpN8pqZw+VyKJiY0lp0Zm6furUnE8vIw3 NivhLIRL4rifvEFJ+/wIcqKzlKCzp3H3OMuF2Aw6FwwuR5pzuODtyaXIXFpbK4i55C3I6kFEUsUC x3FjdFTlcDPIH3eJrrxCyaxdMOWf6iPnqjXLV3zMJr1jUhnc3DwIvV08r6uxDpJu+Atpn8bncgyV XU/p7NP9PLl3DQ/J++5eRCRXzsnQUnCP0x7nuJNTRXNlNtf8TuJ28jwPSl/kDP84VffCOON2krM+ V0kpXciWw+TGheJx7hKZNc1Upt7GW6LL05dJKpX5PerIjeP8qTN4+/oQHJGHpLX0VTwiQPi/j6cH YXGFzI6ZewrjOWqmztYPt3L2TvlzSzjRUcxFjzNcvJ1GY0sND8J8BF2c4uqDIhaPx8eozbiD10mJ rny4k103/5X/9ABZd91Y9tYKtqhYz9SHG1fi8qVpTAnt4e75c5w7e42s6tmOM03do0i8fby5HF00 U2+DFD+6gae7rD6u3y9mnnKGeHIzGPdTHlyIypS6GB+szeDSyVP4hSXTIRWmlvO7VLkqNPZRoQ1H CW3L8/RJfK/cp/lFuasyklW6rtyt/zuRnoifLkk0xZ3EwOqbJDHWVkygtTkmZtbYOjhgbGSIodVx 7tXKiGBqpIE7Xk5YWFhjJwnXVEdd14WM1rE5g1LyKBRTpfW8sXwlCgbWWFtb4xOaSu9zrh5MdxYS 4KSHgqah8K4VRkf02CX3Fq9rnqB0ho+6C+/iam2MoeVRqdM6C/0j6Lhep7xb1uVH61NwtTVEXcsQ W5ujWFoasu3Td1DxS5aup/eWPsBy78e8vmYvZtYyGa1tgnjSMu+zYqLtCT7OdliqbeKN3ZrcbZwv wHBDGh4mO/nDf32dDapmONjYYG2sxq5DGvhnyQzw9HgzcT7HpbqS6NJMWxNVLQcez9wtwVQPqYHG fLr8A1armMpksLbn/LX8ecM22kp8sLvwuzZrX13NuUdLPLMO1hB22gJF1SMYWwrvm+mjqqCJa/Aj uiahMTsa/b3L+MOfPhFmjrbYOxzFWvsQGw4d53Hd887sximNDsDR2oRty9ewy+rhgiW6QdKjzrN/ 2av86a9yqOiYCrq2xlxHGwVVQwJT6mnPiMJVbQuv/3o55t5pUsPYU3KLw2vf5PerFAiIypESx1R3 CectLbhwP41wbV18bhY/P4215nHG6ABv/+YV5A6a4OBoh7WFBpu263A2bsYr4lQXD6+fQU8io60D DkJ5tNQthPyfyIz4VD/JEY58/ObnrD2gO1Mf1ngLxlwi32RbCvoffsiHX1iTWjFAZ2MFVR3DVMed Y8db73LYLYXR6VaiT9uirqKFnqmkPozRUVXH9Px92qXMLRDRVV+hLexD7q978QoKw8fJDitDXfYr GBEi7ZBVeO9UJ6J8mMHMc3z22uusPqTPCe/bNLygt8CpkiA2GJ/gYYv46bdIEn8TkhglPcAYZTNv cmvaGB4dpa+5lGBbA3QNbiAbP07S19JES2cvI5LwusdYauzA8n7L4gwqgznk4vn0a0W/lSEGeXzZ mcMGAVTO2rCJVgLVlvHHnUcplXDRRB1nbfXRcY+ktLmP0dFh2qvTOaF9EPsbsgtoGm/bsl3NmrTZ AfN0LzEn9Tl+I3vu7ouKaCv2X0z5bpnaYtGwteJmzZJ13a5UdN/ag9udGceEgum8fkaXDV6z12lO 0t/aTHNHj1SX/c2ZOGhvw/DuAleug/nYuRgTWPNdQvQTJq9OQOJCN7AjpAe7sltFmGG1zU9zBmpi Md2py8UHMkd+wyln2LdbhZCcWWXU47Jaj3NR1bPKYaSng6bGRhpnn/Zexp6yjP3A2w0l6wffuII1 79xhXvtCjZiaWSs2Rd7VYxzceWLGM2wLFy3NuFIk8wrLWA3nDSy5OushV5gNPb56ArtgmXfWO+ra nI9f4vJ2eoL+rtZ5GYWnrXNwXpaBTKz3b8QitIDZphMnEJae7m1p/XRl3cBgtx6Bj0voGR5ldKid J1Gn2KruuEDuKqwUnbmc+XRrnOPvwSmvRMklqXjp7OKQ9MKjZnz1/SkeGqU8/CRqio4kL5hdjzQ/ xk5VgdMPFlTycDamH77JRmNfMqtk0+OJwXaaewRJJyrx363IibM+ONvZ4ZNQxovdEzjT+kaaiLI9 gq57FO0iR4gk8bchCcEY71/Ou5+vYuP6taxevZo16zawTk4ORYNgJGPY8aEmYcp9HIXdm2ThK5fx 6oefYrGEJAayfNl91IWUF91nHarklJM2FgntS+y0AxsNnCiQDPm6k1HZ8RHvrdjAhnVrpHKsXb+R dStXoHMlXTpTmO4t5NwRVZTUjDnmdgqvcz74XYqkuHm+wDkhhuzwuvudy2ATpddQtLLkVu1iqzlU FovJ587kzK0gDRDpb806TxnxTA4Ls4DLJ1Hes1mmq6+X8/r7f0VvIUm0JmN6VJszOd+1OVRLwF4V Ah4u8OA61oC3swbaUd/0H558QtChT7zUgDbccsbAyYeGyfm0zq03wS+8YjYhMrxN2SbIuHr2MfSh sG/6G0QV5eaI0tHEJSQxTqK7Mlr+DxadeppuSeG4hjLXq6akRJR/ww1li3DpLKkt0YN95kE0zxiv 1jQ/Nn19CLfQWOJjwzBdtRYtm0DSi9rm8xprJsRFeV7G1Rs4YnOX2cWv4coYHIQR+d25ydYwiTZO WGrfli6/lYXa8/avP2D95g2skby/Zi0bN6xm2UYTbs1OUUfyMdxvzbmExqfWQm/aeXSdvUgpSGD/ v/87nykEUFEUicbJKHom2rliZImVV+433ssKMWetWzyzVD5ccw+b9Qpcr3iK+Z+s5uyGj3n7L5+w ap8L2d3fz8J3ZgSw868b8Hn0n9/bEPELJInm+FMYWh+naNGCbSfXTJQ4FlPxjLdGSb1girx1EBWz m9A9WZhr78QsYfHJpaFsP/bYuJL6ou5rRuvwctBGL6xqsYkMM2GVpgOFkl7Wm4qekRn+Wc9eLumr ySMzK5OC/CwS42OJib6Oq648O91j6Z+xZFnBeuz0TeC7JjtTZdeF0bMV0Uts8XB5HCafOZDWMTVH EhF+Vmw6Kzn9M0V+sCUHzQMoaZ4ZPQ8UYqe3gyO3a+YTaUnCWCAJ78LvOk1TR+A+VQIfLdjMFYzS JdcjKPs9WRJ3jDvm2tgGPJYuCzXedkHf3pOqOTaswWu9Kf43Fuh4elr4t/j5Jga56X4MZZuHS47A TvDATdDtsYhFhDtSHo+tghkPO2SxR4RZp72OKRFVNVwzM8AjtmwublN6EFrK8sgfOsjBgzv5/A9/ 4sOvdnPsYs7iUfQ35FyQX3UcDvraRNVOz5HEfQlJHLkrJYnyiLNoKgbyrU1yOBfdfTb4PnrG6EaY rRjpOGDldFSY7Vpidvoo1lYWnL0pmT0OccPCFBOX+0tOzE3xyFeXPeceze1/DNc8wGWHAQ+fls1E BWe3H8LnQTE5N30wMA2krOd7EMVUF/dPmkqv/W36PlMREb9wkohzQ9fCeQlJTFFz3wtFRTsSSmZG HyNtpEcFc+FyLB1Cd71/Som97rLR92h7KVGCkfp8zVeY3ls8kxjK8mG7lRMpL+zjbJzSu+c4dNiE G3kyGbrL7qPzxb/xv7YcpWJmXTfe6yiqZmfJapQVYKSrmviws3jFFkkNWHmQLss3KRKeP9sLh0g8 q8kGpxv0zNiQ8mh7vtD0oKB7XLppWZYWy1X/W1QMLOniZWHIW5hz6xskEYvBR7akLCCJ6z7CiNFT RhJJXqrsco5EMtGY6K7k9kkTVqxexpGFM4n+AqwMlNC8mC8lq9GucmIvBRGdWMrIEpI4v0uR8w8b FtVX0+NglPbr4hs/s0E71UNGuBuqB224Vyqb4tTfPIaOzWkqF5CEx2ojfCOqXrBuBrlx3J7DVolL SEIwgif28C+/W86xm3nSPYfRlgL8TNQwdH0wt/QjWVK64+eM/LY97DXzIe+ZayDj3FTWJPD+ix2Z HqmOxVZHnciaeZK4Z+WAmWa0VDdjzWk4aWhgF5o5M1CYoLnwHmfdg0itnCHyyRpO7FHH3OOh7J3u WhIjArn6qJiRaVkd3zQ8xJu/W4FHagm3Tivwb/9nDRdn7mnvzg5Db68mXtHZSO36ZD9PYoU+pWIs zFZ65mWtuY/jJm0Snnb533g557YqEpQtkamPBF8ntF2jaBz+HkeCK0JYY+DCvSZxvUkkiefCGFlX jrJ5zRpWfPI2r//5Lb6QW8PGQxbE18yYpPEBsq95on1gJ2uFeKu/3oaSniNh92Snk4abUjl25BCr hfd2KBjjef4Sttpf8edPlbiSIjmeOU1a6DHkPn+PP7z5FstWrmGNMK0/4hRF+/O28QnB0EWdRnHr OuHdNWxTt+a4MLv46NP3WK12hfoJiU2v4ZavHYd2bpTGWbtpP3o2HtwukrFSnTB63rd7BypqymwU wtes24qqhRfZC5abJgYq8bfWYMNXq1izeguHtY7iF5pE+5hM0NpEb3ZtEnTw5Ye88uc/89FXQjrb 5fHN72Wy6i6a2z/ljV//hWUKltxvGRRGqnZ88d6f+f27m3ALLmGgu5BTRgqsXiWU4aA+p/2v4KS/ itc/OSAY9YY5g1iZfBWNLWuQE+Rct00RU0c/Hha0Skedw1X3sdsm0eFXvP/HV3j/0xXC31txuJg2 M2ofpjQxCGOlfaxeLYm3BUU9V2KKZPeOl8V6s/ajt3j9zXfYoH2V5v42Qk+q8c7v3uC9LxS4mvsc R2pHhZmHMMNcs2YVH739F15581OpznfrXpXWhYQkHnuocUBDDwsdZTYLcny9fg/Gp8OpG148Txsr vcPBj75C83L2U2dwI7UPhdmHHB/86VXe/Wgtxl6pPM+5nDHB6GpuXM5fXn+Nj9Zac7+ih+J7Hnz6 5l/482vLsQ7NEvKbpK3kHi76yqxfu0Zahq2Hj+DsH0tNz+xMTojz+BpG+zaxQghfv/UwJg5niHnS xOxnG3W3bfhwuS5Jgg1vvXmU5Ws1iWmcmq/PR9c5qnFQWu9r1m7m0BEHrmc2zZS3h7sOeqz76lPe +o/X+GSFTA6ty8mypaieJ1irb+DdV7YTViCj15wzKrz2H2/w6cr9uF4rfUGSkJxuOk6MeLpJJInn wzTDPa3U1tRQ29BES3MTdbWSv1sZGFtowafoa2+WxqupbaJ7cPFSyORgF/VCWENrt3QaPz3aS3N9 Mz1DstHKUG87tfVNtArp1wvp1whxm9v7eLGxjCBDW6P03cbOAUHyaQa6mqlv6mHuCuqpUTpb6qVx 6hrb6B+dL8Pk2AjDQ4P0dbVRJylHXSPdw0/ZiR3rp6WuVkijgfaeoUXLBONCOSX6kbzb2txMQ53k 7wa6RiaZFt5rbmygpV0iUyuDE1OM9rXT1NRMW1MTHTPXrE4PdUt1UN/cJTMCY320CLrvGhhfXC9C 2WTlaGdwwVfVU2ODtEnyramjsbWFxvo66d9t3YtlHRF0Li1nrSDf4IKrmwaEumpoltZ1Q3MvE1MT 9Ha00NTWTGNTCz3Dz1Er02OCniV1UUuDUL7WZpnO65vn6yLPTx+nW7Jlr76OJmk5hp76/dYk/X39 DI89fcQgLW+DrKxNDYJ+O4ee6+vuaeG95oZGmltaaKgX6mNsUlr2BqHemgXZ23qH59KZHOyeaZe1 NHf0P5WshnrbpO1f1q4WF2R6cpT+oVHZe8LfgyMjLLl6ndH+TmkfkdRHx6IP84TyC7qvFdpRs1DG hpn+0dQzU87JEVqbGoT66Zn5wn9aqNsu2lskfUloo70vtm40XXqNFQZuJIinm0SSECHi74MhMm9f 4OCXr/PeukPYOZ3iRmK9qJaXBNP1t9kib01EmXjT9ssEkSRE/IIwRE7MVdxOe3LmpBsuzqcIT6hE /L73JcFEB1FOJuzeocet4h5RHy8JRJIQIULES4PpoRaepGVS3SUecXpZIJKECBEiRIh4JkSSECFC hAgRz4RIEiJEiBAh4pkQSeIlwuRQO4U5edT3vtxHAEc6a8jJKaN7TLzOR3LPR1lJCSXCU1nXzsiS o7Rj3XXk5pTSMSLekSDip4mfOUlM0FiYxf20OiZ/AtKOFF1hy9tvY5PS/bdPfGqY8twHPK7q+U8n VX/HilffUyfmB/0ydpKmwkwe59Xxcm5hTtJdlIDVvq2sWr+e9evXclDvHMVL3Fq13XfkjXcUCa8U j3WK+GniZ04SUzz2O8EBk4c/DXFHq7kVeJ6kxh/ii9M+QjxU0Ipp+s8n1ZKO/4VYqvp/uNHxQP1d 9n30Jh9uOEblS8nwk9xxtUPZamHbmvjmcdrOHAIu3KG0W/xATMRPEz9rkmjJusrqD//Cb15dzvZd u9glPAe0XUhuknoeIiPInj07d7Fb4xix1bKR3lBlIs6HdrNzx05p/F27lXH2vMP9aF809knSOITN hUQW9vmJniqivGzYK4m/XwP36+m80IrRcA0+Vtrs3nsQZeuTPGpcMHbuLsLLSp7dux249SCRSy7G 0nyUrfwpaB9bZKDq06Ow1VWUyq1ifobEsu45g1YQ7sjyt3/PHz5bKyuX8KjqBVPzAnw0XJeM2+Fd 7DmggK59JLULBseV9z0FXR3k6ImbPLgbiM5BSR77sfCLp0vgkomae+gd2MXO3bvZbRVIsfDuREMS J+SF/+/aySGjq/OyDFRwyf4ohrr6WCi5UvycHzL0l8Zht2s3e2z9iX8QhauhTBeaR/3JaZnVVSd3 jhkJv+9G0yaEhqERyhIC0BLagbLFRcpmZgJDjdlccDBin/D+TiUzLt0rmXe50VuMj/o+Pvrzn/nj 23LskZTpsCaB2fPOv8ZaMjmjLOhq/2E0rUOpXECo010FeCkfZMf2HRxwvoKkOfbmR6CwYzs7dpoS mdGOCBEvC37WJDHcWcZpQzXk9pwg/uFDHgpPUnoBbUOStfQpOqrSOK61l1UHPagclK2vT/Vmc3Tz BvYbnpfGv2qxl1/9t9+xzfgMEfFCGvFhOKoqonUiktZpSfxifI/ZYucVTnJuPrmpd/A0P4pbcCr9 zzsCnhygLDedh7f8OaCwFetHC660G+ulNOcq+3/7Cm98ocq50Ns8ehjLSZNDHPC6N+OQboqaB5cw MHMjLDaJ/PwsYsL8sDJw516dxJJP01P9GGvNDWw9FiQtl+RJzahmYKmM0nsQ2mjt6GN8yURhcrCN omTh3VAnPvvUgviGeYbpbykhzO4Qv/l//YoNuu5cj0vk4b3rOGsqo+kUSm1vCxkxfuzdugU1n3T6 hHynh1sJM9jP5r1GRM3JMsADb2uOXb5HcWwQDopOFD0nSYz3NZEf5sIrv/sXfrdWm/PhMUI5Y7ng ZsKeQ06kSolilMYnWdy9dIwDH63DyOEkZzwCuHXrOu5uHkSXDTHRmoq7oRVnQ+6SkZ9Pclw4btbm eMdVytyLjPdSlnqXo0oKbFY5S6JEn4/TqOic18fUcCclKcLvESf4/BMjbpbPewGeHu2hNCUWd50D rJF3p3p4nOpIZzatV+DczSzqOhYy9zQjfZ00t3YxPCHuAYkQSeJvjAkeB5xEweLRs2M03MPexI67 MpetNKQFYWjuzpMZR5u1wU5s+FCL+20LOmjDXQ7usuBmaSeVtzzZveowbpdDiIyKIiryOlecNXhr uyUJ9S94Qf14FW5OGtg/7lwSUMcpOS08rpfM+UBquO/GR6ZBtEjEmqzipDAyVjRxJ+RaBFFRN7ge cp4jBzez/kTyzDu9hHlpohfb+O0yjJRiu/oV/vVTA7J7nxGn8xHy2125X7d4nb056hSb3lPmTuOC aVTLfRR3G3MhQ6bQ9LOuOHjESb3NMlHFOYejeMTOeuUdp+FxGDanI5D4w53ODsdZzYPFzkcnacq6 R1hQEEGzT3w27bOTr/Z7rPt6N7bR1fOvTLdwwVIerZD8ed9KzffQfPddlH0S6ZqrpikmJsdJ9VRj 42Ejzl8N44ZQpzfCQzkpzEq2rj5BxVzRRrjh6swRt9xv1+dAGko7jnG77Cl3cEw2EuHmgomuJZam ztyvfNo9HT2E6snx33+9ldDSH+qSdxEino2fOUkMk3DOhYMmcTzbXA8Q63EUs7P36B9s5YK5Lg7R NXMGKdfnFAb7LrPY/2g9Z7Zac/1eKQ/9rPjw/W1o62ihoaEuPJpoHdHF8FgYJT0vuJjeU4CTvRoO S0lisoTjX5sR8nD+QpbqhFN8ZhGC1Lz2pqL8+To2H1RDS1MDdXUNNDS10dW3xPd2qWzTfqKNy+4q aN+s+HYZxtu5d8EdF9+7ND1rKao+lv1bXbhfv5Akpim+cha9bf5LjHozPgKhel+T3ccwXh3FEX0n klpG6U0Lw0znOPmztm+4CKs9X/HpWmUszEzR3LmGT99cjtLRYAraZ6cT4xReO42+urpQzpnH7TqV AzPmv+oGazScub2QqATZUq/bsPbk/EVDfcV3sN9uRHLP0sL1Ea6xGbkN+9HW0kRDXVanOrp6OJ2N ZW7Vii5CHOzQcEr5dqd+rQ+Q3+bI7fKnG/jhbD++/O2v+cr0LlPPaMP5ty9gezyIJ+0vOOgQIeJv gJ89ScR7HmOfQdyijjw5OcnUgh8mGmIx17XA3tEKRasLNI3NG5eiAFs2fqa/yJhM1d9BRdWZe7U9 lEb6YG4QwlOvFJp6wY3d0QpOOGvhkjm0JKCaU6stuJY8Tx6NDz353CYC6a7DeAWn5U0Jmb92bh7T M0QlkMSF4wqoR1UvDGRyYpIXXsRoT+TQDneSlyydV4S6sPlDTe53LEhRMmJXs+NazuydbD1cP2rM ics3CTptjan/k3njONpJ5r0wAvx98Pb144T+YTZ+uh2HSw+ofd5Nntpo5Fbsxzl+wV0WU80E26lj dWv+4qDx6nu47DIj4xsVN06ylyGmVzKekvg08ys+Q0S4OKFzIvvb5elLQWmnqzCr/OaAYbw+FQ9h JuV1NQR3J2e8YkoRF5REvGz4mZPENBW3fFFae4QriZnkZiZx3e8E9l6XKOhaHDPnggGvvbUN7+ye Rb9XhNjw1v/4D7YZexOTmkPu4wjslTUxOXsfyQLKdHc+7qZH0HO5wqPsXHIzkogIPIGugQ+Zjc93 7HFyuJPyojxyH4agrLAWRb/75Obmym7UmxiivjQS9T/vwsb7Po0D40z0txJ7Vos/7LMnqaJDMGtT VN314pCaFRejHkjffRR7neNHj3LMN112hHR6mAcXLZFTcSUuI5fsx7EEnHDF4+xdFl0YOVLF6YOf 8cY6K3KXLDcNdzfxREg79/ZpvvhQlbO3U4W8Smjqlq311N905a//8Ds26J7hTnIWuclROKlrYXgy ho4FNnIg7yIbtsgJjzEPO59hFke6SQlwQFWou9iaDobGn9N8NsQh98Ef+Z2kzu8kkZudRJCbEbuM zlHcKxFinPbKUpKunUTx4x343MuV6qu8tW/OQA/X3sPqsBbOATdIzZHoKo4L7o7Y2gdQLqnSiQHq Cx9hp3iY9crnyZHoJL+Qht75kf5obwsFkt/jzrHiIyXcIx4L+RTT2DXK+FA7BUmh6Oxew163e9L6 GXlymS3rtmF8Po6ihs4FrurbuKS1nY36QYjb2SJEkvghMNFNcpATe7duYvOmA5i4XuBRQf2Sj54m yThnziGH63RMLP49/7wX+ptdCAp25/CWzWzecgin4ORFp5eG24u4etyE7ZuE8E07ULf2JC63jtGp 5zNsw1UJmKhsE97dxIYN69mwUZB18xYso4uZ7ivD03w/G9ZvYOMuJfyfdNKXew2t3RtYt2EzenZ3 kc0vxih7cBUztf3Cu5vZeFAH96A4KjpG5ozf9GAt11302CHIuWmHGo4+keRWdy1e5hhvJMhSib36 /guuEJWh9tEl9m2WlHEj6yXybJLIeYSLj2R7CuUhfuivO0ZQmAdK2yXx9mN3MZGub2w8txBso42x f/Iz7u0YIjXQiq0bN0jLvenACVIbn/NriapbbNCzxu1iANaaewUZtqFtc4knXbM5dXLLVo8tQhmk OpXUmVAm0+uLLxbqq0jCy1JLWqebNh3E5MRlUsvaZHcx9BbiqbCXjRs2sH7DRjZJdLJHEe/0ebpt Tg/h0Dd0pUnAg2a6q25zeNd66cVLWqfuSPdnurJC2Cu5A33dRtT84pm9snuqOZ4tr32MWkAO4ud4 Iv4eEL+4FjBRewsTJVsSK7458i8N8MbsYATiavB3oyYsAJOdIQz9PYVovss6o1Mk9v08dFodYcb7 awxIbBYdmov4++AXTRLTfaWc19zFqr++wm9ee4udp+KYuwJaGLcV33FH7t23eeXXH7Bu61YUPGLp EheNn4qKBC82fPQuf/r391kr6OrAiVu0/cgfwfWVxGCz4WP+5U9v8umazezTOUF62095/D1G7vWz eEWk/n2JV8QvGr/smcTEAHX5mWTlPqGw4An51W3MuyOapr+1ipz8fAqK8shMTyenqk2cUTwDg+3V 5ObN6yq7ooXRH5lQJwbaKM3JpVioy9ysDLKeVNA9+lNm9SnGRkaZFNeZRPwdIS43iRAhQoSIZ0Ik CREiRIgQ8UyIJCFChAgRIp4JkSREiBAhQsQz8cshicEGbgf54+MfwJ2UCoZewv3M8c5iIi9dIeV7 ugqfmp76zrP0090lXL8cTmqN6AdIhAgR341fDkkM13DZzRb1bStYv9Huud1P/5iYKLnCxjdew/Jx 14u/PFJPjEcg2W3f4b6iOoTP31qN9e2ml08BIkSIeOnwiyCJsYFeOrv7paPskZwbOB92IH/RYH2K wd5uOjs76Rl82iFXSXiXLLxvkJHRcSYnl0xFJobpFsI7O7sZGB5lfHzWP9QUQ/09Qv49DI3NjPMn R+ju6qJveMagT08wIOTfXlfM4/sPqeiZZ7Cp8WF6u4R3JxbK2UX/8EIymGSg9j7WX+7C/3GtVE5Z WUbnfQFNTzIklKGjoYTE+2lUdjz9C+bJkYGZcvQscoUxMTpAV08/0p+mx+nvEuJ0f9OduAgRIn5e +HmTxNQIZbEB6B/YidxqOTYo6WJ5RAtdeReKZ7hgYqCZe4EuqGzdwGohzrr9hly8XzD38dLUaCdp oa7s3rBGCF/N9v0H2f2lEsf98uZuIesqT+aMiTJyq1azet12NHXU2LTFnrhqSYxWzjuqsurLT/l8 9zlyBSKI9DzK1rVfskrhOLkS/x5jVZzSlxfSX8Xnu5S4XDS/FNSVfR29FZ/yp22aOJ10QnPfJiHe 12xXtCQstUnm1mK6hVDd3bz2f37NO8u+lsopcfmg6P1w/iOssRqpD6DVa1ax7AtdruUuvSJ1gvq0 6xxVP8B6STlWbeSwqQcPS3qkoRVx7ny97GNWbzbH09sV1U1rkPtiLTqnomj6SX+LIEKEiG/Dz5gk pmlKDUBpvz7X0quF0f8w9cIsQum9V3hrvQvV0nsY+km+7Iql0zUqZ6xpX2k8LiYOhKfIPCLV3DyH zi5zHs24aR5oTsF6xX4Mjj6U+voZa03FWU2Noz7x1PePMjrcTdFtF957Q4kLOT1SOSYmhJF3XjAr 392Igukx/CMzaO9rIi06mpzGIVmc8TFGW7M4aqmAzaN5x+TTU5OMFYfx/u9/xVuHT5Fd18voaA+5 tz3Yt/0It6pk74+1ZXBiiwph+V1C+Kj0GZuYWqSPSUkeAzkY7DHBLbp2kbbac4JQOayB990cOoUZ yGh/HfGBThxScyKhVZiRTE5Qce0YH/+vj9EPTKBBKOtgZQyq2hq4fuP+CxEiRPxc8DMmiU7CLVVx uL34/oQngXbCrMCRcsl/BINpt/kDvtqrhvbMPQxaOupsePtLNO3uSUmgMyUUlfWHsfALJeHBQ5Iz MnkQHk9mvuRanHGyAk+grXeFRbsI0508uJNOadv8mtZ4SThyHx7kXGLds0XuL8LZ4Zv3SUxXhLNi myHXyhaukfUT7q7OwQs5sji9eXhs1+BG2Xd4np0qwVLBmtN3FsrRS5RATkZBOUsitxFgYYyRR5b0 f1VhvhhsC5j3GjtagZmNKfrRdWJPEiHiZ4qfMUnUcV5egfMpLYt+rYnwRHOLI9KbBTqSsd24AXPf 64RfCyM0NJSwsHCi4x5Q3NArW88f7yE7/hqnT53E7fgJjjvZoKtjxvl7FUwJNJJ42oUjJgl8l5ui oYLr7NzhTfG3OTN9xqVDk6VhrFR24X7rwmWdceIvmbPDV3bvwVRXNie3aHCz/Du8/IwXYXHYaglJ tBKkIc+ZuOolkUeJtXXEzCxBqovKUIEktp6nfjZ4sATTo6YY3akXe5IIET9T/IxJYojEs0dQtL8+ f5fBRAsBqptZvuW0bOQ/WstFBx0coqoWvTnR0Uh9S5dgGKcoueqPlfJFakam59K956SOoqm/1L9/ ++PLHDlowp3yBRf+DDWTlphFffeCkX9DLHt3+1P9rTI3cNpNF/eCxWv8U5URfP7uCrQuZs+51h5v eoyttgb+WbJbBqZ6czm+5SAXnsztptDeWEt181J3qE04qB3D//HCC4rGybxkwh5zPyr755eoBmse YKxhwIk4GQm0RQdjsSuE+RQbsXWxxfpxj9iTRIj4meJnvXE92pyNh7Ya6kbWHHc7jssxc/Z88hf+ 9JsVWN5IplOwuC1Z0dioaGBs44ybmxuORy3RUdHHJypPOjso9rHg4//nM7Qc3Tl5+jSn3R3Qkzcj 8GbRjLO/LuJ9HVE5rImJ/XFhtuGEpYk2itqepNcPSe+zeHTrIk56e/jdb+TQcTgh5HOWmKyGudnH WFsBV/2FmYq9Hl8uf5PlarZCHHdCM2f2Daqi+OKrv/LeZiUsHVyEPOwxUFdFx+c+3bM2faKTOC8d tivq4yyU45jDUQxMbfCMLpPOAiY6irnidQo3VwM+fu1T5A6ZC3l4cT2xRirHdG85l2y1UT5ixjEX N9yc7NDT1MXG85706ta2wnjMd2/g/d9sxCbqMe3DAzy54cRHn33EB4fOkFXdL/YmESJ+hvjZH4Gd 6qkgwt8Na2trPMPuU1lTQJTbMeyv3qdt5nhSX30mV046SePYufgTl1vL7MShqySPuKt3iI4MxEEI t7ZxJzKtmsWfWQxTkhjKsaNCuLU9Z689omV4xnpLjHeoF9a2Dri6HsNWGseZyOSauVmBhMz83G2w PmrLMScXnOyOSmU5/3hmP6UqkjUWntzOTCfU24WjRx0Eksr55pWpw43EXfSQvmt/5hKJT2oZnmGi 8dZ8zh0TRv3Wtji5OHHMXsjP+hgX71bMX/wz3s7jcH8cJeW0dicssWjudFRzThROxxxxdnXE6WoC rUN9ZEWcxdnJGWd7f5LLfiYXOIgQIWIRRLccLzkmRwdouX+G9w+aE1bQxpB494wIESJ+RIgk8ZJD 8p2EodyXfLxsOStWrWa75nGyOsTvEkSIEPHjQCSJnwCmF/w1PS0ShAgRIn48iCQhQoQIESKeCZEk RIgQIULEMyGShAgRIkSIeCZEkviZQerraWzWA+3fS4hJxifGmJgS909E/NQwxfj4BBMTYtudhUgS f0NINpV/qH3lsYEeOnuH+a7kWxJ90TNyIqPrBxBicpTe7m4Gxr7DP3hrGkfVrQnP/fs4/ltaD9L/ L4rw49TZ3wwjtYSZK3Pg4CFUT4ZS+xTPK/UpISjvP8BBeUNCUxrEzvgMdBXFYK9xiP379wuPBr6x ZYtd6gwUcdZADY+kRlFZMxBJ4jnQkRHIATltriZlE2CijprdPaRu9MbqCLLcy2fLlvH5ilUyF91r N6PpGERJ58jfVIbqBHf0r2V+Z7yeOCe2blflXvsPoIiBYjzOOXOt9jvi9aag9LUCvkmtP35ljdbg Zawodbu+fPkyPv1S5jr9SHDazAeQo6ScMWDt8s+EsJWyOpPbiLK1L2l1wy+cXUOSHztWHcT/cfMP WqzW/GRivHX5VNmAuKansNpgCykP7mCzZgPmZxIZFbvtU1DFscNG2J4NJyUlheS4BDIrWll0TddU CY7bvsLkTtUPIsFEbQKaa3Zjn5DHw5MabNL3p27i5daaSBLPgb6MM7z/590EPMrE5fA6VurFykYf 0+P0VcawS1kFvbBcGhsbaazO47qrPgqGvpT0zI9RpgaayXwQTUREJHGPi+lb6hGwv4n02ChpeMyD NPLyn1DTIfumeqilBB/DtbynYE5IRIQQJ4LIG6k09M63rsm+Bh7cjiI8PJxbj5+w4N4ixrqqSLhz m4dZDQwOtJFz/w4RkTdJK13IJJP0t9WQkRhLpJD+jduPqepakMj0EJVxHmzY+jXyx4OlMkRERPEo o565a5om+ihMjSFCkCE8Opm63qd9+TdOQ0EyNyOF9yOjSSubl6G7No+o6Bjy6zvpb6/mcUwkEVHx FLe+wFWrQp30tLfSWJuNtYkS690TpPXS1j8yM4GYZri7Cl/r7Ww+HSOrs8ocQj2OomHoQ1ZhFvei oolLiOVhShUSqh9qKiQhLo74O7dIyqmbM8AjtakcM1fkq9fkOL3E2/B3yzlGV30Jj+JuS3UZfS+H tm+MK8aozUkkMjKKuPRKeoquo+HkSGz9PEmMddeQFB1J1C1BT51dPLQy5aTvQ6mM3eU53Bbq6M6D PLokTWW8g8z4aG7ezaBlcL4BdgptNk5SHzdiyKrs/maNdVTy8LZQFxE3iE/K5ElBIQ09C2hovJ2c h3el5biV8JisJwUUNPby3RO0CZqF8t26c4+i9gF66vK4e0MiRwJFTfN13i38HimUIyY+m3aJjiY7 yRb6UlRcOo39832gV2g/d6Ik7eoOmVUdi/LvrX5CbIANy97bzVH/GyQkJHA/v4KB6fn2XZrxQChD OBE34yhuX1AZ0yNU5j3ixq07xN/LoFHSeUe7KEhP4E50FPcKm7/TwedcL2u4w743X0P/QQkPjL7k LQV3miZ5qSGSxHNgrCSYFVsNicgrxcdOg63HU+cb4EA+WpZWuKQu6FwTZbjs0OLcXdloZLg2Be9j xqioKKGsrICivArG5+JoGpSlMtFRhP8JUw7s3IuSkgLKaipsXvYh2hfSpOFdeTfRXPsmv/tEjkOK iihKHhUP0urnR77jTenYH1FDYftXvLZHl4Tm+S4yWJWApcIqfvcPH3HAwApTLXUU929ls7wh4SW9 M7a1hThvR7RUlVFQVmb/9n2oGZ3hSecMBUx1knBKhb+88zofbz4ok0FRHRefVOa683AD188YC7/v Yvmr6/FPWTKTGG/j/hVXVA4f5sBh4f1D+9gnr49f7BOpi5HqpCD2rX6X199fh7axNQbaSiju2MRm zbPktr/ozKyTcyctkA8pf0rYENHeGqiEl87/1JHOaX0lTvv7Y73tS37/r4L+ne8j0U5nTjDbv3yF f/twA64XHyP1UjVUT5iDNZ6R8QRr6uJ7q+TF2lRXCSFOpqgoKQttQpldm/djcuIaTbNVOtbKvcuO KBxWQF7Q9cFDGijtWcHbqpY8bpPVbVdhAif0VJDfdwjFwwc4rKXCtve/xvbCjGv3uxc5oriTz15d y8mrcdw454KhuhKbVu/h2N1qKQkV37qItY46yvLKKEnqRM2UK5nzLmMGG1I5cfQIB3YdkLZNJWV5 1n72GUdnRtrTA/VEHj+K0oEDKCopcVhJkfVrl/OhfSzfPUAeJeeCIxs++SP/+8ud6Ohqo6QgyLBn D3tUbQlPk83OqpODUFTYztuvbONoQDTXLnhgqnuYzcKI/ERUieQ2FUqSgjHV1BLyF/rY4YMcUrEi JK5sZvY4Tf2DEEz2ruWPv30fuR2y9qvmHkTlrG+b6S6ifRwEPe7l8y8/Red2zQKS6CX+ijO7V73L P/9xJ1ESB8oDyRz6/FXe+XIb1tdzGXvOep/qSMFiuxzHs5rI81Rgh+0VOl/y2x1Fknge1NxitcFx 4spqCfK24uDFJ/NhPdlomJlz7FHbQmtIopMqlpdSpaOs4JOWGHnepnHGzk12POGkkRYe8TID1nTb ju3a9mTP+sib7uC6tTyWV1PnRijl0Vbsu5D83bK23kXd1oqomiUtrzMZTcFYmFxIoXemg15102SL d8ZM6x2hraaOrllbPFzKCd1dmMctcAMuEKKtsxEB3zkT7yP0kBoBi+7OGKcoypO9B+0EPc4TanNW MNo7jbieLptRDKWcYeuaHZyJr5gpewV2q3Xxjq55sTqbaMFTIN6DV4q+GTbdxw1PVRSCc5mcnGRy uJXEIBdUVdxk94xQw1kDCyKrZiz2ZDNXzUzwzh6YM255Uacw9bwjEMYY0Wpa+N59seWJydF+mqvr 50ay09V30FZXxLdgVGrUKhP8kVewI6F2RobRRvxVP+FfVmqQJmknw1V4W2kIg42HM/UpVH2KLyt+ 8zbq5zKZr/0BLu/6nOXbdLl0O0dGcAN1FNR1M1hxB2s9U4KSauYGPXUP/dA+4E5Om8zs5QVqscXM n7kb0YfK8dXfj2ucrLz9OQF8udWah3PjgX6BgI1Yc+Iez7uKUhhkwP/6/Tq8U2eX7EZIOW/JPg0X 8nvn0z2jsocP5TQEXefLytHbQGVtOz0VSTgom+CfPLsOOk1NQgCKQp+Nr18wuBjLRnXPSZK+dSl2 jIizGmhFPWVwMVpH0GkHnEISiAnxxcruGtUDL1TtAt8U4GmkyMXSXsouG2F47hZ909+UofDmadSO OPGgZlAkiZ8Exvqoamqjf3Scns6WxS7An0oSkySf1MI6JEN6z4PGzo9596v1bFy3Bjm51azdsIlV H7+PvG+StHNK3H47Hj6Emp4tZ3wDuHL1GteFKXNpy7xn1ZwQQ3Z43eW7Vs0nSq+haGXJrdrFJDFU Fovp587kzbW5QSLPW7P2TMoMSQySH3OBI4e2sVpOjjVyX/GXDz9Eb+G9E63JmB7V5kzOd/WMWgL2 qhDwcAHBjDfj56yFRthSYzrNAwctLH3vS0mh4ZYTBs6+zC+71+G93gTf8Bdczvk2khC0eNd9F796 6xOhPuSQ+3oNuzWPcSuvc8ZYjpMR4oCK413pSLQ73Z/9ev7UzKywdBUIOt6tK5SvhKrydNy27eLo uVjqWwd43kHh5GibQExuyO/YIJVhzcpP+I8VmzknJYlegk/rohG6uMz9yafZqm7Eoz6hSRaEY61u SfqiTeweLh5QwMojacHItg7fnds5Gpz9jSWRihArVr7xDnKbNrJ2taCH1WvZuFGOT95SJLJYVse9 hVEYCbMIPUtnzvkHEnztGhE371E7s9w02f0EN4PDyOtZ43HOj4tXw7gWEU1SXc/zdi7uBVrxpeXd xfJ1p6BuYoxXdt8si+KgoMURj9RvlKM6+gQf/ts7rN0yX45NG1by1udKXMhaIEfrA+S3OXK7/Fva 73grl9xU0L75jPbWm4nR+k95fZUFKe3f48TD5DAdTfV0j04y2t1MU2ffU5aqhkhw2cOvXllPYG63 SBI/eTyVJJrxOqDJGYmB7U5Dx0CP0/eFhtHRRktLC63tnfSPjDE5c0R0uL2GwqxkHiXcJTz0KsGX fLHWVELDP4nhmXaYFazHLt+E7xydfRtJGH/mQOrc5Rr9hPtastErXWqoS2+6ctjQg8ScMlrbOumr foip+haORC+4AaMlCRMbHbwLv2tb9Gkk0cJ5Z23Ugr45Qrtvr4213wMZSUQ7o2/vOXedrGAC8BRI wi+y8m9HEtP9RJ1RZq/3PWl9tLS00bvEc+JARQLWGpbEt3Vw11Yf56iC+dF24lm2rVvL5s2b2LBB jvd+/Rv+8sE6zM6l81yLYpM9xPmYoWITRFZ5HW0dXbRmXGGv4kHO5I1ISeKKmxbKQaWL7dOjk2xW MZSSxOiTa5grmpKyaKDZxfl98lgIJDG+oC4C96lzecnlWxKUBzugbXSS3PZu2lslemilo6uP0Yn5 I9T9TeXkZiSTGBfNtavBXA7wQl9ZFfOIIpkL+v4m0nIzeZwYR+S1q1y5fJ5jempoW9x8zmWUMe4H WPC5YdTizfa2RwIxWXC5eKaAUxXYq9ngFrX0FsRpym+eRX7nKYo6u2mbKUd7lzDHG5tg0VG2vwFJ NCWHYrR9N/vUdAl8XMcP7W/zZXDDI5LEfxZjJRw5KjTe7Fnz0EfOVUd2HXAiuUXShHqIOG6B9rEw 5me+/Tx5FEFocqW0CVeEGLPxsBEPFpyuSffX5qujYXTNdLTiCAu+MDhP40ybaS/PIu7GQ+qGlvTE xmhU7e24t/QIbGMSlsuE6fuc8Z3gziU7tpwvlP7vgfth9pyMm2U+MoKc2bBpJcaJHQsIMQdTfUWM omaM/2Q7WXdjSMqqWXKapovggxoELxzFCflVxPiyf78Fkbktcx286lEAWrtNicqW5dN17yTGzn7M m7RW/DdZcTnmRU8PDeJ/xhqF8KddrTpBrL8W6re/5Ua9yS6uezqgrqaNopEHaY3PIsZJotV1uJT4 Aie5xurxM92NzrUZQ9RfR4ybJh/v2Mv5GS4sj/dhv7wldytmRtK95Zza/zb/tEoX6Z1Uw5WcM1VB /1QcsweNq+NP8sk/v4nuxZLvqAsZRhsSMNHUwzdufnY32lZKfEgEOc0j0vpJPnWYDUfcKeqZbWcD hLsosOHUQ+msqTPJg9c3GHGjZD79gjBXtm70ova51pumSfXR4H/+egVuCTNyTLYScdIIdfsrNI3O twMXLXtO3m77RgpDdckcU9bi5IKbFSc7S4i6eofsqt75iMMZKO08wYOWb5NnmGueGugnfLM+29JC sDE+RmJDL4M1jzhhYkZwess32kNdehQnzwQLOnzx03IyjFOeGMn58CTpnTciSfyUMdrAdbu9/Mer r/LmV5vZtWsX27ZuZ7+SNTcy6+eWHsbbcrngasTBfbulcXbsOoSmoQ2X0mVGqibSmjVyqzikqs5e IXzXrr0o6zkSXz5voEc6cnHSUWDzuq3sEoyJooYJbudu0zAz1WhIvoDSfiHtNR/z29de47P1O9l1 WItLhcJ0tjYBw31f8Mr/eoMVmo4ktQ1RFe3KV++/xr+8ux2v8HK66pOw0jzE5m27OKhswDFXd3Tl P+JPy5W5mDizIj09RPZtbw6sX882Qc6d+5TRMznBrdRa6fLGcG0Sx+Ul8q/nr7/6HX/9coPw9yHc QrJky2TCCDo13AP1Q/vZtlOIt3Mvh1UtCEoql47AK+9fYNtnb/LHN95hh3EErQMdRJ7T4Z1/foX3 V6gR/uQ5Pv4YreO87RFBRxt5561X+c2Hq6U6twjPnjsCm+Fnzop3fs9vP5ITwpQ4F1301BHhQG44 W199l/2+j5+6MTkq2dQ9so2Pf/t73lu2DdvzWc959HScmvSrqO3bxdZdO1HStuakqz17Nr/F+3JH uVchMPlYJ8mhzsIIeSfbBfl3qxphqrePN95/g6+VAigXFNpT/pjTBkps2rJN0OVBdCzNUf7iHWFW sxr3x2VU3QlAbVFd7OKwWwjzY5EJahJCOKqlyJ6tQn3s2M6eQ5pYOl0SRuWykmScU+GLtZtRUVER 2u0uQZYDaFmdJr1ZNhrvSvPmrS82sF9FFfkdQhrCKPuAji2XMpp4vjHwJMnB5ryy6SC6OqqCDEIe 63ahZHmOpHrZiKYiMYDdO9fyxu9f481P1knLoW0dRM3IvD6rMiKx1FAWwoR2v0vQh7wqhseukNck S6M27iLam77gN//2Z5at3SZNY79jAGUzK7rTHXmcNj8s5L+JD976HX/4bK00jl5QEr3dVVyyPshH v/8XfvuuEVkS3h58gvG6P/GrVz/gwBEvnnTPlnaMROed/MM/fMrZjO+5VDRaivGqd3jzgB/tIkn8 xDE5RG1hFlmZGWQkP+Lhw4c8fJxFVftTvnYa6aI0J0Ua53F6PvVd8wsTY33ttDTVU1NeQLI0jQwq Wr85CpnoriP7sRD+MJXCqpa5pSgJBtsqSUmSvJtKVkbGzN9pVPWMMz3QTE5GCpm5GSRnPaFtZIL+ hmIy0jLIScuktFY2Wh1uqSBFyD8lp5yeCckpv2oyU7KobF1YnlFaSrNk5cgopKl3Xs7JgTYKpfIl kZadRVpykvD3Y4pqOhesu07SUV3AY0k5H6VR1jy/79LfIpQhJZ3MjHRSc+oYnhihriyP9JxM0jJy qOt+DhM8NUhFXoaQ7yPS0zPJTn0slTWnrnOGtKfoKM8XwoR6k4alUCqMDJ++MjJEXVUNLT1P76mT g+0UpieRmiWUNSWVvIpOnv804xRdVU+ksmUVN0hJtK+hkLTH+bTMHesco7FYpuuUgloGx0ZoLs8R 2k8FfTNRJvoayU6W6Dydqs5BxrobyEsTdN7WR39jBamL6kKos6IaBpcI2SfoPeOhrN6yi2rn0pa2 ie4WmpsaqCrK5ZEkTmou9Qv0MTncTXVzE/WVRaRJ00ijpKH3hbpR2o3jbPDNFppWB0+EdvpIqoN5 IftbK6SyZWRlkJ4qK0d6bjUDS8ox1FpJmqTdC3WfUVhD/4KvpgeaK0l/lExWtqRvyPpq0hNBj7Oj g9FuinOSpe+mCW0jM0WWT0ZVG2Nj/VTlppCSkUV2ViXSLcmxHiqKc8lMl/xeSvfcKGJaqrPqygb6 Rr/fsaW+nEDWfbwGl6Qf4mMnkSREiBDxk8EEDRl3MFNYza+2mHD1WiSpFZ2/cJ1MUhDsirLiaSpe kgvGRJIQIULE3wlj5AW7Y6iji8ERbTTUtTh1I5vhX7ROJuioKaOo9u9/qmkWIkmIECFChIhnQiQJ ESJEiBDxTLz0JNFZkcWNm2m0DImue0WIECHix8ZLThLT1KdFoLx+F7YX79H7kjvCEiFChIifG34S y00jmT4cNLUlqU2cTYgQIULEj4mfBEmMFwVxwNqWuAaRJESIECHix8RPgiSG8y5y8Kgd95rEChMh QoSIHxM/CZKYKAxml5kdMSJJiBAhQsSPip/GEdjhIo6pHcHaP43BSXHJSYQIESJ+LPxkvpOoCLLh qw90iKv+ZX+PKUKECBE/Jn4iM4lyThrqY3v+MX1T4kxChAgRIn4s/DT2JIokexK23G0UK0yECBEi fkz8RE43XZCebrovblyLECFCxI8K8TsJESJEiBDxTPwkSGIo4xwHjG3EL65FiBAh4kfGS++7qS45 DPk1u7C7/ED03SRChAgRPzJe+plEd3U+MXE5tI++zFKKECFCxM8T4n0SIkSIECHimRBJQoQIESJE PBMiSYgQ8QvARHsuZy1dCIyuQNzaE/EieIlJYprR/i6am5pobu2gb3icH/Rs0+QIXa3NNAn5NTW1 0z8idqVnYaynidKSWvrGxdNmP1BjZLC7jfbOHkYnpv7zyY23c9NLm61HzpJW0snUT19BIn5EvMQk MUbWlaNsXrOGlZ++x2YjP+rHfpicpkdaifa1YP3Kr1kj5Ce3SpXABw1i63gGGmJseftjHeKaJn7A XKbprComr7yFsR+9hGPUFaeRXtPz91HwVDu3nPfz17fWYHml9D+vyZ4nnNI7iHfeoNh4RbwwXu7l pulp4d80DXePc8TMiYKBHyifmjB2m9lxv3UuY8ZHx8XW8Sw0P+a01w3Ken+4Melwyz0OL3ubjza7 UPWjT+rGuO2ngWp03d+x6bfgY2KB5omM/3xaPfl4Gh7GP6dXbLsiXhg/iT2JlvhTGFq5UvgUkhhs zCbQwYTD8vLIGx7ndk7T/LLU1ABljyJwMTuCvCRc3Z7IjIZFxiAn2ot96z/it+/8lY37FFFQUMTB 5x7dLyDfaGs+AUd1pHmo6Fpz4vhxAu+k0Tc5n09lcjj2WgrSOBpmp7hXJsuhLSUcQwUl9C8m0CP5 YaKFoNMmKCpbEVcs69SdeTcwV5ZHUd2Ea6U9THcVcdFRD3llC8KyWubk6Cl/xGlrWVk1LZzw9PLH L+wJs6eHR1rzuOJijqJEF3pO3Eivf6Glh5GGNM5oyKOgooWF+x0aRubDqh/6clhRgxOC7tITr2Ki KuQhr8KxoMdIqm2i9iFmKgooKimh5BhEqfDuRGMKZzSF/ysqoG51ndrZ9IbruOpkjbaGFqaKrhQ/ L18PVHHRRQsllRPEp2YQedYeZaGsWnYXKOxYPB/pLL7PSSuZrrRtzpFUOWtApymPOcO6j/7EH7/Y JGs3kjiGQVRKHBCP1XLeTh8VZaGscZVz6bXn3uSIohLKxy9SPjNgb8y+hYOBhvR9Zd3j3M1vnm2Y lN4PEH4/jJLmGTIahxmoS8bdVAV5neM8rJEooodASxsMPPNhvIqAI+ocPizIonaSpJqhF+tAfYWc NZLHJ6sbESJ+liTRFHcSg6eQRH/FQ47rW3DmUgQJiYncCPbFxvwooZltUqKYGm4k4aI/F0Nvcl8S fv4ER1QNuVU528kmaanIIsxdi2V75HG9fJObN2/yKKua4edcbp9uzcLNXhf945eIjY0hOvIK5js+ Y43OaRqkJDFCRogLamoGuPtdFdKP4tI5R1TlLQjJaBJIroRIh/28f8RFVj6B2Aoywjny8WqcrxdJ yzHcWsaDW8EYyH/J1/rHOHf6OF6Xwghwc8HZNwlJabrzIoRwHew9AokUyhAedA6VNSt5f1ewNHxM MEInDSw4HXiNeEEXN0MCsDe35HJK03Pv9Uz0NZJ5V9CRvyUffGRGQsP8xys9dTmcN93Fr//fv2WD tjMXrkdxMyIQaxWBAN0jaeyu436YG5vXreHQmSS6BN1MDTZyRXM7a7aoc/l+Cb3S1athUgLssD8f Q0FMEA6KThQ9L0mMdfMk5RL7f/8Kr3x0iOMBody6GY6LwQEOesbSNyUjgdaM6xgbO+J39SaJiQlc v3gGCz137tcOSsO7Kh9hrbqaVSZnpO1B8sQkFNItkW+ylyinPby+x5LE2h66ClNJfVLLcNsTrJUP sc0ikq6JKUqiz6J+UA9X/yDp+8GeTqhpGnAuoUqq787aPG5GerLpk50omLrgdPwsVyJC8LS1wT+u YoYk7DD1LWa88wHaKz5nv4UXN++kU9/zYrPc6Y50XA6rcr1cdLMv4hdFEoMkHFdgu7YjkXfjefjo EQ/ibuGmrcChA4HMjq/HOmrITEnikST8ziXU5TdhmtC8OIOSyxw4dpr879GHhiui0Dm4hxO3Suno G2Swv5fSuAD8rsXTJcm//Bb6mtpcyO5a8NYUxZHObNEJQOLYdirfhz2OZ3gyN9Ab5qYwivaKKFhk wKNddvP6enMSStvnZgBjw2NMTdRxXlMDp5CsRSdXnkRfwsz1kTCTmCTFQ41t6rZcux0n1VVi/G3O GCqzd4c39TOZDDSXEhsdTfTMcychjfq+p+w7dCdxeLsr9+oWK6wt+jTr3zpIZNX8FGO6LoZDu024 nCMbXiefccXp7AMpcTFVh5+TLaduz7r3nRAMeAQ2J0OQzPemssNxVjvN4tqaoq0ojZgFckanFNE1 N1Fow3uDJg5+6XN7GV2PT/OhYQDVEts63YS/ojCCN/HgVuw9oV08JOFuONZqO1jrkjijvxFu+2mj cavm6XVedgM1jRB6hXqK1FrPh4c8aR9qI/zKCQLyBOLszcR2hxoBqS0LTTVV0W4oGziR0Tlbey04 7t3Cl/tPkNU0NFe+UelSZyeXbCzYuk8PHR0DAh6Ufb8N5+FmwpyMkTe+SvMPuYUkQiSJl48kmgnY u5IvN+5BUZiGHzp0iEPC9F1RWQWHswlCFxNmGs05nLWzREVRFi6/cx1/+XQZlg9aFqU/kOXL7qMu pLR9r15ITsgZjihoYmZjh6OjI3YO7kSm1Eg7deOds1hou1KxdLje8gjDL2xJFohhIO0MOxw8KeyZ Deziuoo6XpGFC5bOugg9pYLyteKnGO1ktDcdI67yWSzXQZDCGr5cu2uxrpSUsTl1h9YZ69MkjLA1 JGEzj6KuCw/rRr6ZXH0s+7e6cL9+eJERLL5yFr1t/kuMejM+uyzwvlYm/d9YeTg6hoKu28cFvV/H XMeZ7NmVnpFibPbL8cUWHZydjmEqLxjQd1dx5HgkpZ2zo+dx8oKEmdkCOQ85BlPWP6upSk6vNeNS zPyyYkuSF5+YXKRawgAjucKofA1fbzuAwowu5A8roKSshfPVXNnS3HQP18+oonSt4KnanOot5KyK OdGpD7BV+pB/fceQGGFGct7GmQyhjY4XhHFgoydlS/dSOh4ib2bF+fz+maIUYSFvyek79U/JpYer 1qq8+c5XbNc0xi/xe+6PdGVhsGU7ymfTETlCxPfBT4IkOh+cwdjWnfJFs+xeoh21sL9b80zjfe+0 GvLHY5gzc8N5WOjswiJxMRuMPwlgn70bWd9jX2+oLpM7t6IobO6kvqqCstInJPqa8JmqK5l9gk0q DENHw5DousVdtCMtgF0HPCkVhrv9KafYbH2aorml5np89irgGV2x4I1BIrw00LhZ9U0hxgTDeEgL z5iKJdZsXJjZDEt1kXBcB+vI4qcbvRctdOt9Dm13I6l18ZsVIa5s+1SPxwv12JnEEVVbQjM7Z38g 2NKY0yGxhHnZYnw2Z954jbTx6OZ5Trq54uJ6AiuVXaz66zqMPW9T3v28Jq4eL2G2dTl23q98R6o3 y8yDpbMTJqrxkDcjKO1b1ucFkgg7pYTC9ZJnhPcRc0mfLeoGHD/hjIeJKeZG5pib3kSocibr72G0 SY9bVYsJti/rIsqGNsQ3zDbkCqyVbDmb0PqUTHq4aGWNvlc+Q23pOJpbcjGj9Xv1n/a8a+gesiCp TTyMIeLF8VJ/JzHU1UxVZSWP/Y3Yp6RLdH4lVbVN9I/JjFOHpPEf0MXn5iNKhHilOY+44u6E6+lw WgXTkx5owA5Lf3LLqyhIjcHLQJ4Pv/oAxQtZdA3KjM5gdyv54Uf5SuUIV9MqqRTSaWjtfe5RV3/2 edZ9/C6qXncprmmkqamKRH8z9tv6UixZYZns4fYZYxSPHCPiYZ6QfjkZ8ZcxlD+C250SaT6TNbfZ s0+NYyHJQng+kZ5HePufXkfrXCLtwxNMDndTX5mJm8lmNgkjf4mMlbXtDE9Mz5n5mgRvlPfp4RP5 gGIhvCjtDm6Wpli4P0BCEwMlUegf0MEz/L40vDzvMVfPuOB8PJjq5zxjOjbQSbUk74d+rFp2hAsP CwVZ6ukckBmf+psuvPd//5ZNxn48elJOZcE9Tutoo+Nyk5bxhcbyPBt3bGDrdkMS2p5FUWMUhLpz ZIspKZ1DjD/PjYSTI3Q0PcDkr4ew935I+9A4UyO9ZAWb8eohR5KqewR9T1F915NDakcJjkmjQijP k9Q4vF0ccfB6LFsGE+YTSVcsWanqTlJhhVCOFK55n+HMmVs0TsvaZm2MHf/8X/8DnYsFNCe78odf vY7KlRlSmRok2d+Gw4q2hCVmS+srNz4YU20NHEIzGRXSGO5rp7LkNgrrlDDxSZTGqWvqRvbpyQS9 rVnYKWqh7p4jM/RJvsgfUuf8vULqOvpf7IO4gSLOHjmIX7Z4uknEz4okJN9J2LBl7VrWrFrJVytW slr4e9MhSxJqRuaMY1PWTey1DrFeCFu7Zj/Gxy+RWtom7URTg9VcddFj45q17NGwJ/xBCiHuiqyQ U+NKSoe0s6eFHWOt3Nd8KaQvJ8Rbu3Yduk5RtD/nbu5wdSKnrPWwPGrJgc2S9zeiaOVHXtOCM+mj wgg57BTq29YJ4WvZpWjJlYflC4honJL4QNQ3ybF2swInQiK5YHKIVet24JnbTl9uKOrb1/D1yq/4 atVqaRrrD50ht2shlU0IxjsEI6WdrJHobLcaLhdiqGgfmVuyasu7i9MRBTZIdLV6D/pOATwuambi Octa8zCQnVI9r+LLL2f1pUlgomyBqTzEjyNyR/G/4MqBjZKwHZidi6FlaAkRTDfib6yAlsf9Z3wD MSQYWTPWrfqaFUI+q3e7kNzwHB4e+0o5a76XlV+s4Ov1u/DIbGag8Aba21eyfMXXqBhHIhuLj1Cc cEXQ1W6pLtfsVMbOO4K8+v45XU0NVBN6TIctkjJuOISF22UeFzbP1dloVTzWyloElY5KpiocPWBK VGn/vCxTAjndOIvGvq3SPDYqmBAY94SBaVm7fXL7tPD7aqF8K1i5ao00jqpl8Mxhhw5uucjz9YoD eNyWLTO1JF9k8xfL+FKIq+IbT/8LfMc43VOAl9FhfLN6RIsn4udEEiJ+aqgPv4j5nmuIDntfLkx3 5+GhL0/gkwFRGSJeGCJJiPiboOqBD1s/eZ8//esHbN63D2WPu7SL/h9eDgxV4Wslj0FYPuPToisV ES8GkSRE/E3Q11TMw6QkUtKSuBcfz4Mndc/9rYmIHxoTNGZeYt8aJU4EF4qnnES8EESSECHiF4Fp hnp66B0YQ+RuES8CkSREiBAhQsQzIZKECBEiRIh4JkSSECFChAgRz8QvgCSmZ56XHxM9FcRcjyS7 ZfSlVsVAbQbXwh9SP/RLP740Rm12AiFBQQQJz4343AU+pGQYbsjhevgDqvvE7WIRP038zEligvKk GC7eKP5J0MRY8SXWv/YKFo+7/vaJTw+SkRBEWH7Hfzqpxttm/PYNJW43/JCGT5A34iLe19Lpeykr b5LaxBA0t+5FQVsbbS0NTI8FUbHEi3fHfTv+8NoBwipED6wifpr4WZPE9GQfN49bsVk9gp7hYYaF Z2R0jMkZozM5PsbY+ASTk8Iz4/ZhempK+v+J8VFZ/LFZBwhTjI0IaYyMPt0lwvQEI5I8Rsa+h7fO KcZHRxhsqyApLoGSrgU+LKYlYaPM3mI5PTEm5DPC+DP8MkyMSeQeYWzJtZdTI/V42+3hUHCetFwy XYy/mKxTk1IddNXmEnMvl7aR6QVB44KuZklj+pu6Et4dFf4/MTHB+PiELN/pSenfExPjUs+nC2Vp zhUI870/s2ydHWXPyUXTUxNCvvP6n5zRxWJdTUt1tLAdyOpWEm96SfsZl9bpfLkW1MlIMxfNjDhk fv9ZjU+qg56GJ8QmZNM0OLXk/RFZ2xPa20zLk7Y7qY4mxfNHIl4e/KxJojElkGV/+RP/+rv3WLlq FauEZ8MhKx5IR8CjPPY3ZNkHf+X99fN3TAyWx6D3+Ye8/8EyafwVy77mkJobfmdt2blWSOPrNSge vUhJ++zIcJL2iiTOmKkhJ8ljzXb0ToRT3fUCl24OV3BS9yBycnKsPKhNWOkClx5d+bjqruejt/bh 4h2Iq6ESa1etZL28FbHlPfPxJjtJvuaF+r5Ngtxfs/mwKVcSymaM9AQ5wZZ88Mq/8+t3PpOWS/Ls VjzPiwxwh6sfYLd1FatXy7HmgBeFffOGr+yuKys/X86uQy74ezuyd71EV3IcsjhPcccQY1V3UVy3 nPc//IBPNb14Miy5iOg+Vqs+5oO/fsQ61cA5WSYbUzht7oDbMQdslV2f+z6J3sJbGK9Yztt79Tnl 54G+/BahnCvZrmRNRFbrDHl0EGmuxsovl7PpkBt59Y08uuzEnhVfsVbemTTpF4CT1KXewEHrEGsk bWCTAo4X4mme9V/S84STezfw5h/+wK9f+ZjVEn1u3o9n6rwDvtGmFJx3ynT19e6TZHfOE810Rw6u O9fz8bvv8Im2h9TxYE+qP1/85W0+W6HB1cetiBDxsuBnTRKT493ccLNht851Wrq66BKe7t4BZJMD YbQ73MZdT0vk9f1pnDFE0/2CUVZRxkbiBLCrmxwfXX7/337LweNRlLQIabQWE3ZUk13GflSMTTHa kMYJMzv844qkjvQYbSTO0wWLczG0jj7vzUWTDPb10lWdhKnJQWwedc6HCaPjwd5MTN99n7+uM+VW RgXdXc3c9tBkvfNNZC7bRskN9sDwWDAFTRL/QVM0F97nuLEjV2YuqRgfqMHH4RDKQZlSPUient5h vjFonRqiMiuJB2mlLF1Gn54cY6BHeDc/lE2r7UhY4Cp8YnSQJ5dNeeW//js77a9R2CTEay8j4tgR dul58qRvhF5BV9aaWtiFls580DXIXWcjNMzPU9kzI8tYI8HOppyJf0Lt/WDsFJ7/0qHpiVH6C8L4 +I//zh+22fKgoF4oZwvpUafZt02Xm+Uy3Yz099GQGYLGR59zyMCJwJA4KmrLibsVQWL1MAOlN7E1 dOZOXj2SrEfaSgh1O4rrhWyZyxFJnfRU429hhqJ1jEyf3T0MjU8t0NW4EEf4vSSSbautuVm2wCWG xDtvTyP3A5xQUHEnr7GV7EuOaBqeIqW2V5i5LJxTTdBamkV8Yi4tgz/6Pa4iRPzc9yRGeeB7HHnT hGd6zZzuysDZyIzL6X3S/xdGn0HrqD91MxOBkkBn9so5ULTQYA5norPDnOs5zRSGObHyvXVom5th YmIiPKaYq2/mtyv1uVM79mLiDpTg4qiOw+POJQHluK0yIihxfoRZ/+A0H5sF0yw1rMVYC7OQTQc0 MTM1lcphambIjrVfsMLmvqzsU50En1JDJ7r622UYLsLs03/m/3pTnfSeZ8RpTuDAtqX3SUB12Cn2 fWlFzkIP2WP5GO42xmfGHXbJJXfMj4XQKpG7PwcXC3P8Uma9kw6Qff0sFl7x0itPh5KDcVByo2ZR LhMU3ziHhb4++rOPZxTVgzNs13CHNVu08FvkzG6IWyfVOOCfPrc3NV5zF+2PlmN9q2xJ2xgjwX43 yzbsw8hMpksTUzM0d2/g68/tKZ6r0j6uCTMdLZf0b9dn5yMUtjtyu/xpfpMGSLl0EvlNe1E39qSo +2mDim4uqX7Cf/kfq7hcJPpeEvHj42dOEsPEn3XhoEASzx6MjpN12QkD12vUNRZxSlcX77TZjeNJ 8nxOorfnAu2L3qnh1I6jhCeWkehnx+q1hvgFnsfP1xdfXz/8LwQRfjeHtuEX3J3oKcDJXu2bJDFZ wvGvTQl+MH+dT1X8ST6zCJHdwNeXitrKfegd8+K8v58ggy9+/ue5cvUGqUVtsmWWiVYuuSsLJFH5 7TJMDlKVk0JSVgX9z9oLeOalQ17obvWlaVHkJs7ttcQ3Yuaui45EjI7YElPRTUP8BYx1faidzWfg CRa7P+PdT9axa9tW1nz6Lq/95g2+PuhOatPoXJ3Up0RzQarrmedmKi2zxFR1gzWqx4iun1gkW2qo NZs8Hs2RRG/RHY7tMiejf2nh+ojQ3sUBbTsCzvvL0vfz58KVYGKSF86uughxsEPDKeXbD0W0PkB+ 27NIAtoTTyP31husMIyg7xnts7U8l/uPcmkeEE9Iifjx8TMniRHuezmwRyNqfrQ43E1TSxsDC1mj NwsnfUOUlJQ57HaHhd259KI1y/+8m7DS+WMrXakX2KfpRmr7MA0JFzHV8mTJdT90N7czMPKinbqO UyeO4Ja/dN7TiOfao9zImJesLdWHL+xvyWSdauKiliEed5ZcSDTaT1tLj8yITbRz0UUB+aul88E9 HbQ0dy322jo9ychAL129g4w/i+P6UlDY7SG9VGkhqq8f46tXt3LpyXxAf/ZVDmk4cXfOSI6SeNIU i9P+eNgZYxdVO5/AxDCtdaXk52WTW1DMowAntLYacreshYGx51y6q7uD3EdyaAZmz9d5bz7uBqqc erjgBrimR7gJ5JX3jSqaIi/IGq2T0Sy+MmiC7rZWBuYSneSW23H0ThV+uzyjWajucefhU2497MiN lN5ieDsjhxv+J7C/lET/U5IYH+ylu1/0rSvi74Of/XcSzY+vobfhIGYnvfH39sL5qGCgTl2kcMnF ZFURxrzx8WEiKxeahmnKrzry6f/5C5vVrXDzEmYJHvao79fjTHi+7C6E0VquuFuiKoyOT/v6C3mc 4dhRQ9T0fMlpHnkuGcc7y7gZGoD/aStWr3qPVQYn8RdmAreLWgWeayfppjPr/m0ZBwy9SG0eZKQx Dy/9jfzTF4cJvFuCZJu7PTccHQ19jrqcFt7155TbMfR1jDgWkDVzZ8MYObdOsmGXFsfPCSNkz5PY GFtwwiuGRfZruATrFb/i//sXddJ6FsvZVZXBJSFtf2dN3vjDWo44nxXyiiCjUkYKdVHufPG//8x6 FQuOe/rif8YRzQNHcA/OYuGcY7z2JptXfcAXm2woHHy6TtoKEvHQP4jcOxtxCk1++l3bT0N9HGtW vMuraxSwd/fC3/cMR3XVUDoRhWwyMkhhTCRnjqqz6o+foufuL9XXrbyG+VNRXQWc0zuCgbULZ4VZ hK+HG9aGBljaX6RaUqXDLSQFn+XQqq95f7Uwi5To5OJVkuvmTXxfbQ5XJL8LpP/mH+RQszsj5HON tIo+hjuLCD5jyor332SjY5xs3yPvAl+88w5rtV0ISy1l7uDYZC3HN37EJyoX6ECECJEkfgCMU5US xlEjPfT0rPEOu09l28CSJYJ+Yo6ZY+L3iKFFAdMUnPfGYl8Ayek3OWZsgJ6hvdCJqxcfHR1rJyXc G2M9SR4mHA+MprTt+dePRxvTOG1viJ4wmzE1NcfUUF9IRx+vR9VMD9YS6mmNqaUZxpb2RFb0MFga z3ErU6zMTHH3TWZ2Rb+3/DG+LlbCu3ro25wi8nExvYtWXXrJCvfCVCKniQtBMZk09S9ZiJvo4lHw OU5dvEfrki2V5pxozCXvGhhhYWGKkYGkvK7cypaZr4qQAMx3+JKcfRsXU0FX+jYEPSp/itfRflKC vQm4X/6MpZoR8qPOYmRkgpmQj4HlJfLbnnN/pzaajaZuXE18yKWT1ujrGXHy8kM652YAPTzyOYGB UAZTCzOM9PWk+vJIKF5Up9P9Vdw+7y6rU6EcPuEPqeuZkWGgklAbC4xNzTA3NZS+r2dmy/WC+WXC joJYrKTvzupKUqdO3MjsoL8hiaNmBtK9Do9rydLZYE9xAg5mZpgIdf//b+883KJM8n3/N9xzn/s8 5+y5e/c5e++enZ3ZmV3HmXGSo2PAHDAj0QCoqCgGJOckUQwEdcxZdEQEAxkVFUGSgGQUAUlNauhu uvnct7sRMOvu6IrWx4dH6Kp+36pf1VvfqnqrfuVz5kb/4URS1SqLYeKnBrhfqBStleBfwsftlqOv l+52GaVXQjFduIGE4icb9l5FO6mB3ljPjKRaKVaWvAy1spPMXVuxnBROmeJfM3euXd3UmX2A0cud OVHc/gF4O+3j7mE7fjL2Ilcm9k4I/jV81CLR13aXiCXTGfvtl4wY9R1ztsYNOShHQ8E5PyZ+/x1f f/kD4w0MWCCFN4ln9bncSwhhyujv+XrE9zpbGXrHUPeOtaKtMA77yT/y96+/ZfS4icxe7sW1uuEs 7gqKEs8Sd70U1TDOhWB485GPJLQ7beV0K1T0qlQolL1P9D412t3NSiUq6f9uuRTvqXDBc2yl7reV 4t3bSrvjWrtjWa0ty265fse3KDCB4J9CeIEVCAQCwQsRIiEQCASCFyJEQiAQCAQvRIjEe0Sf1hOo Rveq5C3eRLqLRq27l0AgELyKj0ck2orZ6bqeVavXEHQgndb3sI1U1l4j1NGZM/e63vzLWqdzHR30 vOJNrab+Ov7OgZzNaxW1XyAQvJKPaCTRRU5KPFEOy1g8w5UC5XuYxPvnWT5uLAG3ZG/+XWUVJ+0D uProFfEexTN/kgmBifWi9gsEglfyEYhED1V5N0lKSeNOVRN112MIWOpD/lBXOIomCjPTSUpK4lp+ Nc+cytnTRN71VH14Vj73iqtoaJI/MWHT/rCY9OQk6T5XKSitoKKinnal/v7lBTdITs0gt1S/I1fZ XMHV1BRulNTr179rOim+fZ3EyxeJT7xGTcfg2n5lSw23pe/ermpGIW/i7i1tOpO5XVw3xHtpN5Wp B7D6ehIue+N06dTGySx9NLjbWbpH5a00krT3uHST+23PW3mvpqE0V5+P5GsUPZANhHTUFZGSfoPy h530tD8kJ02Kk3qT6mbhU0gg+JD5sEWi+xFJu9yxNDFlkdFCFmgd+M02xNxkKyX9bWTngzz2e27C 0tiYxYsXMXfxCvwPX6a+f6ShaC7lbMhG5s9bIIUbYb7UmEmfzMIh8Eb/Bicl91JO4LjcjNnzjTAy tmC11SK++saWMyXaBrSRo2GbWDB1NJ+P9yI+M5FIb0dMF03HwMhF6vlLcZTVRLutxWjedL6cNJPQ rLaBLMjy43Cd8RP/45uJmNquZ9VSE4yM5jLfeCUBR7Lp0Apa3yN+dVrGl7//E6OnzZfCpXQYLWb9 gcxBn0nK+5xyXI6RdN8vPjMlKv2pIUdvGzePB2NjIdlqgfT9+VJ+rZ04dKlMJzSVqZEYjv2Sz/4y l42ebqw1XcyCKVMxdookXya8kwoEHyofsEj0UhK/FbMV/tyq0/d2NY05uEz6mr9P9adSOwxQNXIh fAuO4ZcGnNz11d8i2NaJPbFVur/LToRiNdudAcesvVVEmqzDPeC6ztdPR/EFHC1siLhUOuD7pzX3 EJNHr+fInSHz/rUJTPn7REzsw7iQ9UD3UcPdXCqahjgB7KsmxH8lnhlPuXJrvMyYTz9jouMpGvrF rbngDCsXLGHvnX635soSohat49LDV9nlPp6WboTGDfG+KqW84koIi62cSSh67BRdTWnSPpYt38KR Ir0Dv9bLkUz7v7MITSrSC2R3LrZ2q3AVU1cCwQfLBywS9RyxtSQ87clWs+xkMEtn+XBP+0f7LZzG /ZVRU+ZgOHM606ZNY+ac2fz897HYbk3V9aC7S5OwNzVnmXMgvxw8zIkzscSeSeJuldbjp5KMXQGs 2Rz7pLtt6a+q0lqahvgj7yk8xbSx6zlb3P7iJL/gPAl1yUkmmHlKAjB0HkxJfNR65kXqD73pa80h bO5KzhS/wrGg6i5OS1zYFl8z5MNmTq43xzu25KnIHZx2dWaj91W97Y5Hs3nBIQZS112Kg4cDdnE1 4kkSCD5QPmCRqGWfpQU7nhKJilOhLJ/dLxJNmfiamLIro5yainJKS0spr6imobm1/yjKPnqaGyhI zyAh7jSH9u3nl6gwNlpLDfmRG1Iz3UdmxFbWbnhaJJ5FXnCa+fN3Ufgy7+EvEwlTrUgMfQui5NLu TZgfuKP7S9Nym9DZNsSVv8I9+XNFoonjtub4xZU+Fbmbc+7ubHZP071/KT8RjZ3hXga+2VXMFrct bIq/L54kgeAD5QMWCSV3jrtisnobhS39c0Ut+XhM/ZavZ29DN0nT28iZUDtsgy8jG/iegtL0RNKy K9BI/wr3BGA2zoOsQV/TpPuvZYXDPt1pdZ1FsWw2XUlUUvnAdJP8/i0ORJ8l7+HgQUXcv4jRwt1U vDTN9/WHDuU/+ea8r+JXRn/6N2Z4nBtwef0o+zirrOz6z22WRKKjgOCFiwi72j9dpJaRdyOdtNy6 p3ZE1OJl7cPujKEjGg2l8VsxWulBcvngFFnV1SNYLd/Cvlz9lFbD+cM4LDjG4BuTB7j7ueOSIZbT CgQfKh/0i+u+jgec87fH1NQEcwszVqzfyJpFU/nqP//OwvCz1CqlRr46h2hHW5aaW2BhYYGJ8VKs V7txMk3f6Jfs98HgD+NZareO5UuWsMTCnGVWAVzKqu9fXaSg8OIBNlgYM8fIHAtzM8ytVmHvd4ri Rml8oWrg5E5nTGb+xO/+YyTTF0txLFaz52LJwMqjnup0vDctw8JoJn/7/I98MXmRFGcJfvEF+gjl vzJ+7gymWVhjvVxKp5kxJuZrCUooHhzBaLq486svC+cuwETKh+nyFax1CuBIeo1OJJQPruNms1z6 7iw+/cNnjBw3T7qHDUHHCvTpULWQts8bK+m7ZqbSPYwtWLLSkT3ni3SHFlVn7GfRmFH893+MwmR7 DPc7WknbuYq/fPYX/jxuMwli34VA8EHy4S+B1bRRmJlEbGwsaXcq6JC3ci/9CvFZJTxeaaqR13E7 +aIuzoXLmZQNOTBI3thARUEZxfk3iJfCY+OSKHz47HuF1qpcLsVJ4bHxZORVP9F4F91O5Xz8JVJT pfue18a5yJ2K5oGRR29bDVcT44g9H09iYjKJCXG6tFwr7x8VPDjPNLc9ZNa1UCJdKz4ugZtFDc/m ta+b8qw0zkvfjU+9RVXjYD7U7bWk6a57gaSURK5c1P6eQGZh45DDdpTcz88kQZvG80nkVQ1Oe7Xd z+PS5cskpV7m0q1i2pU91NxJJykxiaSL1yh/1DMca4dAIHgFwi3He46iqYKMnev540QTvI8kkJFT gdiZIBAI3hVCJN5zZIUJ+CxdguWypbqprpWu0eS3CL9LAoHg3SBEQiAQCAQvRIiEQCAQCF6IEAmB QCAQvBAhEgKBQCB4IUIkBB81fX0a1GrNyyKgUavRfDwm+WesKdlSrfvR9D29uKKXjuYGGmVyYcth hhCJ10Ct6KS5vpnOHgWdrS20yLqfqejKjkeU37vHvbJqGpqaae2U0/uBLUJSdDRRps1jeSW1NVWU l0q/V9fS3u+iStHeSGVVNdU1lZRq490rpbq+7R8+A0/R1syj1q632qiUx4ZhNsmAseOn4XGl+plw edlF1plOYvzY8SzzSkYuHodnkYS2ufgiWyzmMGnSJOlnKtae8Ty5vbKOHdYWLPNMeDs21KiQtTTS 1N6NQt5OY7OMHuGc+DdBiMRr0JgRxthP5xN95TrBFjOZsfY8g2fH9fEoL5mta82ZOHka0+YYY2o4 jrH24ZR0flh2qErbz8Jp05g85iv+9ycjGDNJyu9qT1Lr9DJQmfILU0Z8zmd/+YqJUrxp06Yye/5q IhLzeNOz9tTtWWyYPpqxi7dR/Za7noqOGvZ6GGF8JPf57Y+ijZRoD6aaHqNFPA7PoYPDYatZefQO vb299Er2aqhr4ek2+lJ4EP6/3Hg7+3y6i9g4ezyGHme5esiDUWNtSKkXS8V/C4RIvAadOVH8+O0S DmfeIcRmPtMckwd6xxrZHYI2rsFz341+n0YdXNu5jK9WenJHNniNppIM9vq74ezsjO/2E+Q90j8q zblXCHH3JjwhW9+QqpuIOxyKp180WTX6prWtJJlwdxfps52k1Urf63lA/N5AXL12kVI2eBNVYyEn I7fq77FjP2d+jedCSiUDh/DJa7h8YAduUrhL8H6uDfnum6DIP8CPGyLIfY4I5kd442p/iMfOzutz DrPSzIVDMQls8/PG28cX7z0XqJKyoX6Uy7EAH3x8PPHZcYW6xwlVN3Nhuzvmi01Yax5AseqNUkdd 8Q2ORwfr7ODis4MrJY3PxGosSCIiwAUXt0BOpWRxImotVqcKBsJ7H+VzbJc/zi7u7D6dTtKxXSxe EYN2r3139XW2eknl4SPZX+t1V/OIRKnMXN23calw0M17z6MCTm0P0KXDK+IsRY+ebB6VjQVS4+qj L6+w3Rw9cI60qzUMZFfRQMrBbbpwV78dHDx6jAvp2bzO8R31uQl4SPXqSHIuFflp7PZ1lq7jxd7z uQM9+a7qG0RLn3t4BRNf3q6re6lHwiWbhHAhf3BHv+rRXU5HB+nS4RdxkryGwd31itrbhHquYcKY EfxksRlPT6ksA49R1Pw4kWoqrh3D1dkFn6BdJOXVPzEy7L5/kyA/Vzy9fTgSn68TkAdZZ/CV6oRr yBFyGl/3CMlKXGfNZKnfRW6f3MrPP2zgVrtou4RIvCN67x3nZyMHfs27Jz1UazAMvTkgEvK8I6y1 syNpqONWWSHn0m9QrzvxR8O9S7uxW7kKexcfQkND8HKxw3LFVhKLW2grvkb4ysl8usqfIu3Tq24l 5Vw4iz4bg19Mse4+HZU3OLDNB+OZ3zHTM4IjkYH4bg3CxXYdzjvTdQcLyStT8Vq5lnUOHgSFhhK8 1QPj8eP4dvFxnfhopAZpj5Mjrt5B7IiMJNDXE/stnvxa+OZ94647BxizMYIc2bM9tdxdPng4Hxvi MPEh2xc5ERYZy4HwTfz4w7dM94rjodQSqltK2GUkpXH0bLwPXuORSt+oFMUE4x52ipuxB/FZ7s/d NxEJ1UMSDkfg46vP5za/zZgu8iGxaDBFlclRrLBZKwlIAKFbfbG3WsTno0aw5GSRPn/lSThar2WD q69UXgF4bV7BmL+OYrxlDFpd7KnNYfdOHxZPmI7hqjCi9+wkMCgQN1sbnHck6ISkvSSFYDt7PAPC iIzcha+rE/Ze27leq2/05PeziN5sg61bANu3bycs0Il5n03AzCpW34hLgn460oVltm6ESeHhYVux nTuaCRauFL7GsKyxOA2fVVP50x8+YdpSe3z9gwgN8mb9cgvWRV2hSWrDux/mciIiEOs5o5jgGMZR SQi8tkr1c+M6NgTE6zo93RUpeDm64O4bQoSUj62+rmyy287NWr3UKBsK2BfuguG07zGw8ZTsFUq4 JIglzY8LTcP97DjCQoNZPWE8K53PDHEQKdmyLo+94Q7M/HEEs13idf7Qru6w5NORc3HdE8vdltct /IdELLDGZVs6xZf2sWysNwUqBEIk3hEPkjD3iSajspZzR0PYEDN47oKms5jwTZaYrQ/h9JXrFBTe pWKIbydVVRL2q1ewLbFyyHGjcq7tdWGuwzGdJ1kK97DYdzv5A5O4KuJt1rDzTMET8/kXg4z488S1 nL5R1n/inJrWpnbUmnpOSA2OY0QSg537Xq4dDMPS4RI90lVyftmImV0Iabkl1NbXc780lyOe67Fa doi6NxyVd+bsZ8yGXWS3PjsPlBflybplvqQWFlJYmM2F3a6YrQ3kav+5RImhWwnZl9XfW27kaIgv wWce+8bto6PoIh7+UeRLxlJmncbXKpQ3dUTe1dJAdWU1dVI+aysz8ZlixNaTelv2tWbhtHIzOy4P +uNVlMey6IcvMDtaLEWQccZhHU4RKYNz5z0leC6YwLdLjj/RwCUFr+GvXy/hQHppf1wNHa0yVKpH nPVZhpXXIbJKqqivr6OyIJ0gS2u2eCXr8t6QtI+lY9cS96C/xdfISA7ZSXhwhq433VebjP3SBfgm 1PTXgV6qEncTsH0/5a85qa/KjmDcD1MITHow+FlNAuum2nAyZ3DEk73Pmk/GLGVfUgGPa25bU5uU zmbObLZllfNebhZW6PNx9wY77ZcyNzRtyHRSI7vDbPG5/fKJpKLtXvh4nab5OWE9ZYl4eQcQtnsv 7lsiSC/vfsNSbyHWLoj9RwuouZ1AwPKDVD/PJvcTsZ74PfO8ziMGGkIkfjv61ChVvboVG2p1Lyr1 k61qT0M+h3zXM3PadKZPm8LM+WuITC7SNeR1lyJwWO3Pvafb07oU1o3zIFMmNbo3tjNf6mUWyAYr /CnLlew4WzgoEpoWToQsx6z//IgnkF3HdpYXF8uebT3UurS2cHSZAaN+msJcw1nMnDGDmbMMMZw1 ixVbjvHgDV/wvUwkig86Y/D/RmAg3WPGjJkY2wSQWNo8kI+OnMOssQ8mu02DojAWJ1sPMh4fC6gs I9B6HjOX+nD0+HF2brHC8KeFbD1xlfvtr5dIdWclFw4GYGk8T5/PGRP58vff43v2nl5Abu1ijscO CjuGfquZQ64LWHaqVFKMbGzneHL+qcObMvd7MHH5ySEjpFZOeLmw1C352Rfr3YX4GXzJd1MkG8+e JdlhBrNmz2H2jHnSSCNVLyiKGo4GbWKhpR1efv4EhYRJPfBjXCt5fIcubh0OwmqhJQ7eftJIJYTQ 8GguZJbzuhMwtRe3Sj33YEqe8L3YyXmXJfjHFff/rSAxehXzd6Y8u8BAeRf7KVK9GTeDOQP50ObJ kBXBKYPvmTpLCfO1xjn5ZScUqskMcMLTK+aF73VKjjnyp//5KWtO3PtHHlLU0jPaq9bQp1HTq1I/ d8GEqjYDJ9N52OwY2qESCJF4a/SQn5jAiSsPnvi08eYeZpl6cKVeTdedI6xd5UjaU0+G/O4JTOYF UyA9wB3XQpnrtYPigaeuicNLrNh+rnjIN9o4tX0lK8+VPScZRfgtsmXftbrnPDsaXcNwwWMlHrHF v0muu/MOMnZjJHee0xXLi/DF0/nJHveTbcVDojdtZnfcdRJ+8WPD1ozBF5nyB5yNdmOd7RpsbFZj MXM83/zlO4w37yP3kfK1yuNmuAdrNkZR2PK46b7PjvnGBJ68q28Si44wf40faUMPcNJUEWI1maWn JNuq7+E+z44D14Y2eEriA9cwdvmpIb3PNk76erMmMOtZk8vL2G1nTeSdF88LycqKSI/JorymmKzM 61xNSWDXFkssnfZSqx1ytlWTlZFIbkUNeVmZXLuawrkdDhhYeXK59vVe/dZfCWCOxWbSh56Gq6km ynIt+zMfH8bVS/IvazE/fPvZC/RWEGpmz/6UuldUiArC/Vfgmtr40mg3A53x9jn73LrRVXNDGpE7 4unuhIM0qr7+QKwje18QIvFPIeeclw0jxjmRUlyLvKeHHnkLeb8GY742hJuN2jmTOg77rsbKOYrM 8ia6u+XUFl7Gy8oGx2PZugay995JZhuvITq9hm75IzIOO/Ptf36Ni9SwqTR9Ujvfi0Jey35/M0wP ZUvX6Ka7RyWNbB6nQ8XdU/5YmLtw7mYp7VJ42/07HAz1w2t7GtqOZHP2QazNNnPyegntUjrlzVWk ntjDzl0xVL1m11SjVtEjXbvxWgTfrArm6sMuuhVKHg+stOGZwU5sso2iUrqHUvX8ZUmNKeHMXWKG ufF6zlS/+OZNyQdwMw94xUFNPNGYZ2x1YPXaKMo6lHQ+zOVIpCNT/jgaz6M5KLUJVT3isNsaLL0O kFfbRnfHQ1J3r+O/fvfvzPslVxolKsk/6MVia3+SCmolW7dRnBLF+D/8gS8WHaBJ6qFqpJ6qoqeW fU4OLHFNQi7ZpKdn0A70Kck7G8iy5b4kFj+Uwnpoe3iX2Mhw9hxP140kHsQEMvHfDYm6Vka3zkwt JAY6sG7zHh5qRaIqFrMJo7Dec41GXQQ1NZdDWWDnweUHrzfZ3pSxjW//z38x3fEwd+s76JaEJz7U Dst1v1DRpdbXqx4Z57cvY25Ecn+9GpIP7TnnMUGY2/hyKadaCutB9rCYuIORhERloB2MaXvtiqZ8 /FzM2HChUncNnS0Gir6PXmWP9Hknye52OEhpqdXGUah0IzBNr4rW0lR8LZfiF5Ov+6zopC9WNt5k VHeg6h2sQ31NOfjbLGWdNAro+AefWGVVKk429hzKeiSaLyES7wIFGfsDmbdgPU6O1kwzMMBg8nSW bAoj7V7DwDsIdUspMTtdMZk2EQMpzmyjNYSeuknHwLu9Tq4eDcJo/BgMppvgFhGF9+KJfD1mJuE5 jbTlHMNq9ni++/oLvvhurO4ak03CyGkeMgUjXePWqR1YLprBBCl8gqEp9oGHuF7Sok+H1HCVXjmE /TIjJmvTOc4Qy82B/Jpe0t9IvZrKlL3M0V57zCg++fs3/DRBus4KV5L7e+UVSbuZ8s1IvhwxinEG k1nunsBzjyLqLcNvyXQWupx9wZp5OVejNzPxh1F8+flIxs7z5eqD1+s9q1rvcsDLip/HGzBVKpdd sbFEr5jN9z8Y4JeiP3hVLSvkcNBG5o2fgMHUhWzwj8DXfg6ffzePIO37EXU7qQcDWTp3smTraVhv CmS7z3pGfj6aDTuSqSxMwHyeAd+NHMnfRo7Wl6mxF9frhpSHQsaNE9tYuXC2LnziZCPWeUaRml+n K4+GtGOs/tmcdZtsMJws2dFgBpYOe7hdpbeI6uFV/GwWsWydHaaztOmYiKGVG3E5Na+9/+bhlXBW Wy/H3dMVi6lS3ZswgyVO0eQ26u/RVniO9Qsn8uOov/HXUfp8GMz1Jq1myPyURsa10xGsNpmjC58w YxG2nru4mF2neychv5fAkvlSXR35BV/+OE4XZ9pcR1Kq+t8p9NUTs8lY9/nor0YwcuR3jJd+N1kT TaVU7yrOBzLnp6/45L+/YXOEfgly/nF7vvjzn/n6p7kExxQMvPvoa8hgtVT3ZjnEvHik+goKD6/l d3+az+kyMVIRIvGO0Gg0urXhCqmn1NrSQkurjC7l855iNV3trbS0tNLW+bwDevro6ZBJ329HoTte W0Vne5vurO0+ldQTlbXS3tElXUOKI92nta2L53XUe7radelobZfCn5MMlbxDHy7dp1v1ZhsQ1Mpu ZLp7S73Srg7aWqX8tHdKPfTH4XIpjZ10dnZI8bT5VLx4I5xKifKFgX0opXTK2jvo7OpEJuvUjwJe u1AUUtq0Nujun5fW27JLqR5yC+kzyaZae/eo9eUjb2+nq+dxHI00ytDaWipPhT6hCsm2HXKpl9wr XV8mo72zk67ONr09pTQ+a05tmQ6GD81vn1Rv1L1qVAo5Mu0GzVZpVDNEY7Q7wTXqXnqlsu+Q6etN R4/6jcqr61okriG/6BdHSB2adukeQy/RJ+VDe+02qV7JpXRq61XLc23dN1iv2jpRPHWNtrY2Ojq7 6Gzrr5uyjiHX0Ojrta4+aOuG/jpt7XKdWKoVXVL5SnaXy6URiN4A2pFHl7yLdsnGXU/siOuTbNb7 8h3yL60XDUSZTGSKQ4x4HyFEQiD4uHmYfZ7VM7/l0xHfYW67Cf/w5OeuKvqokGn3ObkTk9MoKsgb IERCIPgAaS67wcH9hzh65BB7d0dzLCabVvVHbhRFBw1NMhRiI/YbIURCIBAIBC9EiIRAIBAIXogQ CYFAIBC8kPdcJPqoSDrAcgsvrpR89K/dBAKB4J3z3o8k5M3VnPG1ZZV39Gv7rBEIBALBb8OwmG7S FB3GxMmNK7ViWYJAIBC8S4aFSPTkHcTM1ZNEIRICgUDwThkeIpG7H2M3L17qZFIgEAgEvznDQiT6 quMwtXHgeJF4KSEQCATvkmGyBLaVeO/NGJnv5G6z8v1PrkAgEHwgDBORUJId7YzhLA8y6xXvf3IF AoHgA2F4iER9CqvW2LM/q0mUmEAgELxDhoVIKHL3Y+TiRVKDKDCBQCB4l4glsAKBQCB4IcNkM90R TJzduPxAiIRAIBC8S957kVDJW0iPcmC5cxiFHe9zSgUCgeDD47138Fd2aQ+LDDcQk12L5v1NqEAg EHyQvP/TTX1iikkgEAj+VYjzJAQCgUDwQt6qSGiUXTTUt9DdKwwtEAgEw5G3KhLdZZexnmGMc+Rl ZB/7IewCgUAwDHnr002y/DNssl3F0XvC55JAIBAMN97+OwlZDu4eKwm4IRPWFggEgmHG2xeJppu4 ua8iJKtdWFsgEAiGGe9AJG7h6GZDYE6nsLZAIBAMM96+SPTcZ6fzOtbsuol4KyEQCATDi3eyT6Il 4wALvjElKu2hsLhAIBAMI96+SPQpyDsZylJjL1KruoTFBQKBYBjx9kWioxAvlzW4XKoV1hYIBIJh xtsXicabuLitJCRbuHAVCASC4cbbF4nmLNw8VhF0s01YWyAQCIYZb18k2rNwcbQkWOyTEAgEgmHH WxUJVUsFR3w2YWXrSeYj4fJbIBAIhhtvVSR6ajIJcNlGXHadsLRAIBAMQ8R5EgKBQCB4IUIkBAKB QPBChEgIBIL3ht7WCtLjL1NQ3y2M8Z4gRKIfjaoHubwb9cf+fr1PjaK7i26lOE5w2BRZr0Kqu3JU mmGeEWUdR13sMDZx5EqpWA35viBEop/a9EiWrI4gv304PmlqCs8EYjJnDnMMDVkTfJa6f9SbYm8N kZvs8T+Wy9s8TLCvrw+NRqP/6Xs9ZVY1ZBOyeg6GRoFkPnw37iLlFYk4WGntugCHXTfoeccl29dZ ycnADczRlq30s9BtD8VPtZ+td86weqkv1+vfsMTaSwhyXK67ruHCFYSnP3hp9AdJv7BaG3eeCUGp Vb99Xqtjmb7Ug/PVooPyPiFEop/SmI38edQG0puHo0j00d1aT0VZGZkHnVli40SW7B+8VG8xdj9P wswvhbf2qGpaSN/vxvjP/hf/9m+/x8L/Mq/j1atPJaeh8CRzxq1n342md2JZjaKdB1X3OBtsj8Hi o7S803LtJTPUjpWr/UkpKqOs7C45xZXIep4U1YbkbXzziTGxlW9YYuoe6h9UUXbvJp72y5gRmf3S 6Mr2JqrL8olynsPcvTd++1pccooJG4JJrFOJBuk94v8DDDybeMV64mwAAAAASUVORK5CYII= --_004_4A95BA014132FF49AE685FAB4B9F17F657E81CA0dfweml501mbb_-- From nobody Fri May 6 00:45:09 2016 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 A2FCD12D871 for ; Fri, 6 May 2016 00:45:08 -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 qFni4ks9FVLX for ; Fri, 6 May 2016 00:45:06 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD6B12D1C9 for ; Fri, 6 May 2016 00:45:06 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 81C5B1CC0314; Fri, 6 May 2016 09:45:06 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 06 May 2016 09:45:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Schema mount questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 07:45:08 -0000 Hi Balazs, Balazs Lengyel writes: > Hello, > > 1) Will mounted YANG modules be listed in the base ietf-yang-library? > Even the mounted ones? Currently, they aren't. However, I sent it as an open issue to the mailing list (no response so far): https://www.ietf.org/mail-archive/web/netmod/current/msg15737.html I do see a value in being able to determine the overall schema outside any management protocol context. > > 2) What does conformance to a YANG module e.g. ietf-system mean now? > Do we need to load the module at the top level, or is it enough to > mount it =E2=80=9Csomewhere=E2=80=9D in the containment tree? I think this would depend on whether the client supports schema mount or not. If it does, then it must iteratively construct the data model, and the conformance will then be relatively strict - unless we use anydata at a mount point. > > 3) If the answer to 2) is it can be mounted anywhere, which modules > must be present at the top level? E.g. ietf-yang-library? It's not that any module can be mounted anywhere, the server specifies the schema. Yes, yang-library has to be present, then schema-mount module, and all modules listed at the top-level YANG library. > > 4) If a new list entry is created can it introduce a completely new > module never heard of before in the network element? I *think* that if the list is a mount point, then yes - a new instance of YANG library can be provided for the new entry. > > 5) IMHO allowing such dynamic introduction of new YANG modules into a > network element, with flexible mountpoints, flexible set of modules at > each mountpoint, a flexible set of deviations and features for each > mounted module makes discovery actual available schema tree difficult. > I think we are providing to much flexibility, over-complicating the > issue. Some more static mounting solution that can be read from YANG > modules instead of run-time data would be easier. I fully agree, that's why YSDL was much more conservative in this respect: all modules need to appear in the top-level YANG library, and there is just an extra specification of the hierarchical organisation of subschemas. Lada > > regards Balazs > > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon May 9 02:00:10 2016 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 5BCE312D0E4 for ; Mon, 9 May 2016 02:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 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, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk 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 qLcDHtcDqUPG for ; Mon, 9 May 2016 02:00:06 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3CF12D0A6 for ; Mon, 9 May 2016 02:00:05 -0700 (PDT) Received: from [10.137.1.13] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id BB2CA2401CC; Mon, 9 May 2016 11:00:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1462784403; bh=5WnrAYfmr3hEYuZeCa6c45VP49e5Bddqmkv7xrxLhAE=; h=Subject:To:References:From:Date:In-Reply-To; b=o336eIsyJ+I/JMUB3hhvRxlw587YDK722m72W0ZyVe93BYkpb7lruLQsLkgUQFD5N S+JFeizbvZEZz03HiG2d8ErFXqTH/rQWV9rxeDF3Q2cPRXq8k/p7Ea7rljkwVf8gbJ ER6zXtv8ZCftLSMOpWxrFed89mBXGXBrTipdDywQ= To: Balazs Lengyel , "netmod@ietf.org" References: From: Robert Varga X-Enigmail-Draft-Status: N1110 Message-ID: <3695c597-0704-69a6-6c68-19dea11b48b2@hq.sk> Date: Mon, 9 May 2016 10:59:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0w6G2UTLO7eolwjRp2BqG3w1AgUvvqbCo" Archived-At: Subject: Re: [netmod] Schema mount questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 09:00:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0w6G2UTLO7eolwjRp2BqG3w1AgUvvqbCo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 05/05/2016 04:44 PM, Balazs Lengyel wrote: > 5) IMHO allowing such dynamic introduction of new YANG modules into a > network element, with flexible mountpoints, flexible set of modules at > each mountpoint, a flexible set of deviations and features for each > mounted module makes discovery actual available schema tree difficult. = I > think we are providing to much flexibility, over-complicating the issue= =2E > Some more static mounting solution that can be read from YANG modules > instead of run-time data would be easier. Unfortunately, there is at least one use case, where the organization of 'the world' is a run-time rather than modeling-time property, hence the discovery process needs to be driven by data available in run-time. That use case is important for things like OpenDaylight, but may not be important when talking directly to "simple" network elements, e.g. those which can be statically modeled. Bye, Robert --0w6G2UTLO7eolwjRp2BqG3w1AgUvvqbCo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXMFGMAAoJECsDwSqgzwDT2HYQAJBUP+vhX3Hb6lXU77CiLrjW zLqAyfyA1NXejB44j/mBsD3xgH8KgB422l4bFNpsxSoda0xzRbXZBmNImlcPy0XS //4ZBih4ZVnKuXHYfbSWbTv0PFXpSf8EftDnzzraFlY7SBXJqS1Lo95OUJ5rMvFT r9BHH81pGLfh2HI2VEfMa3allpI5tyjmbRF1V/2dvldKT/r6KyUgH//o8QklDf4P wQGQfe3EHNihwkVgn3wyYqPp64vJeBX8QlNhlCBvXb2vP0msWYD/kNF1ySosHqeZ QiE6vMOxtWH8R26GQNycHQe9juflgPZP8eb9R2ToFU7wYI+kKdZLvDWJ2syxqXQr CrhtQLpRYg6FSctsLkYfdgr8kCyaucHJ9CB/c4heZcra0OlHo4zcu5I4GGbkGPZR EzXHTijQGS8bwZnf9v8Im0S28HEbhHD9OYmskw4aMr+fGsp3nOjgToLwBsJHd86a 0Kjb71ZDD8y8jm/HvpcYSCt/7Km9lLTw2Wc9KO2b8trJg4U53yMJ3rY8d+L/XxFR cNIASSp2eVc+iZAEPcXg1C5GVVb8Xd4lyVOLQuRUs4KVeFHgwizW85MKWOv3iETS /HjpMaytLLZb9PfaiwdZRgcmq4mYUgFCTUbEXjoQXuDhaNdNIGLieGWkcfeZ6mLF /1AGJ2SoF0l8cT2BbSlf =Hemr -----END PGP SIGNATURE----- --0w6G2UTLO7eolwjRp2BqG3w1AgUvvqbCo-- From nobody Mon May 9 02:30:17 2016 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 D629E12D0FC for ; Mon, 9 May 2016 02:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.996 X-Spam-Level: X-Spam-Status: No, score=-7.996 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.996] 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 brVQvg9bILjh for ; Mon, 9 May 2016 02:30:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E6812D0F9 for ; Mon, 9 May 2016 02:30:12 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:cc31:fdc8:23f2:ace0] (unknown [IPv6:2001:718:1a02:1:cc31:fdc8:23f2:ace0]) by mail.nic.cz (Postfix) with ESMTPSA id 06D9561799; Mon, 9 May 2016 11:30:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1462786211; bh=n8qn+JN7yXTezOxlul5EuENXVOdmnllxbMc9ttdbBzQ=; h=From:Date:To; b=hvVCBN1uJh/Lh7yMuyOnPEoj24tuEkdAL0pjqfHiwSdg3rileCTgarCqe44wSokcI JoGcWaLPMFg8hnhaI3RayQ3is1KvTtLxgHC6RWt+lCpQ9XlLqqeoU6jFpwcmltxkVo IqCnQSrxABitXUEtT7jDxAPo4C9kZ3rQFks/8avc= Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E37E6203-7594-45D1-BC4A-A4F722A7AF42"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Ladislav Lhotka In-Reply-To: <3695c597-0704-69a6-6c68-19dea11b48b2@hq.sk> Date: Mon, 9 May 2016 11:30:14 +0200 Message-Id: <67B0277D-0F6D-4962-8354-C62E2D62C80E@nic.cz> References: <3695c597-0704-69a6-6c68-19dea11b48b2@hq.sk> To: Robert Varga X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Schema mount questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 09:30:15 -0000 --Apple-Mail=_E37E6203-7594-45D1-BC4A-A4F722A7AF42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 09 May 2016, at 10:59, Robert Varga wrote: >=20 > On 05/05/2016 04:44 PM, Balazs Lengyel wrote: >> 5) IMHO allowing such dynamic introduction of new YANG modules into a >> network element, with flexible mountpoints, flexible set of modules = at >> each mountpoint, a flexible set of deviations and features for each >> mounted module makes discovery actual available schema tree = difficult. I >> think we are providing to much flexibility, over-complicating the = issue. >> Some more static mounting solution that can be read from YANG modules >> instead of run-time data would be easier. >=20 > Unfortunately, there is at least one use case, where the organization = of > 'the world' is a run-time rather than modeling-time property, hence = the > discovery process needs to be driven by data available in run-time. Either way, schema mount isn't really about modeling-time but rather = about session-time. I would prefer that the server publish the complete = schema upfront, as a part of the "contract" with the client. >=20 > That use case is important for things like OpenDaylight, but may not = be > important when talking directly to "simple" network elements, e.g. = those > which can be statically modeled. One option is to have separate mechanisms for the simple and complex = cases. Lada >=20 > Bye, > Robert >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C --Apple-Mail=_E37E6203-7594-45D1-BC4A-A4F722A7AF42 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlcwWKcACgkQWQVCj+dOjAwuWwCfYd4gKty+nlGIsSdWesF9koZQ GsMAn1jq4wfp0liB2fk0CLaCuQkIVAMl =/PZA -----END PGP SIGNATURE----- --Apple-Mail=_E37E6203-7594-45D1-BC4A-A4F722A7AF42-- From nobody Mon May 9 06:27:14 2016 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 F2FFB12D1A6 for ; Mon, 9 May 2016 06:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxiuE_y9fElU for ; Mon, 9 May 2016 06:27:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 803A712B060 for ; Mon, 9 May 2016 06:27:11 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 2A4CB1AE034E; Mon, 9 May 2016 15:27:10 +0200 (CEST) Date: Mon, 09 May 2016 15:27:28 +0200 (CEST) Message-Id: <20160509.152728.738155337458624523.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Schema mount questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 13:27:14 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUaHUsIE1heSA1 LCAyMDE2IGF0IDc6NDQgQU0sIEJhbGF6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nv bi5jb20+DQo+IHdyb3RlOg0KPiANCj4gPiBIZWxsbywNCj4gPg0KPiA+IDEpIFdpbGwgbW91bnRl ZCBZQU5HIG1vZHVsZXMgYmUgbGlzdGVkIGluIHRoZSBiYXNlIGlldGYteWFuZy1saWJyYXJ5PyBF dmVuDQo+ID4gdGhlIG1vdW50ZWQgb25lcz8NCj4gPg0KPiANCj4gRG9lcyB0aGUgc2VydmVyIHBy b3ZpZGluZyB0aGUgbW91bnRlZCBtb2R1bGVzIGNsYWltIGNvbmZvcm1hbmNlDQo+IHRvIHRob3Nl IG1vZGVscz8NCg0KTm8sIHdoaWNoIGlzIHdoeSB0aGV5IGFyZSBub3QgbGlzdGVkIGluIHRoZSBi YXNlIGlldGYteWFuZy1saWJyYXJ5Lg0KDQo+IElNTyBZQU5HIG1vdW50IGJyZWFrcyB0aGUgIllB TkcgQVBJIGNvbnRyYWN0IiBpZiBldmVuIDEgdGlueQ0KPiBwcm9wZXJ0eSBpcyBpZ25vcmVkLCBk dWUgdG8gbW91bnRpbmcuDQoNCkFncmVlLg0KDQo+IEkgYXNrZWQgZm9yIGEgY29uZm9ybWFuY2Ug ZW51bSBvZiAnbm9uZScgb3IgJ290aGVyJyBmb3IgdGhpcyBleGFjdCBwdXJwb3NlDQo+IGJ1dA0K PiB0aGUgV0cgZGlkIG5vdCB0aGluayBpdCB3YXMgcG9zc2libGUgZm9yIGEgc2VydmVyIHRvIGRv IGFueXRoaW5nDQo+IG90aGVyIHRoYW4gaW1wbGVtZW50IG9yIGltcG9ydCBhIFlBTkcgbW9kdWxl Lg0KPiANCj4gRS5nLCB3ZSBhcmUgYnVpbGRpbmcgYSBzcGVjaWFsIHNlcnZlciAibGlicmFyeS1t b2RlIiB0aGF0IGp1c3QNCj4gcHJvdmlkZWRccyB0aGUgbGlicmFyeSBhbmQgZ2V0LXNjaGVtYSBm b3IgZXZlcnkgbW9kdWxlLg0KPiBUaGV5IHdpbGwgYWxsIGJlIGxpc3RlZCBhcyAnaW1wb3J0ZWQn IChzbyB0aGF0IGVudW0gZXNzZW50aWFsbHkNCj4gYmVjb21lcyAnb3RoZXInKQ0KPiANCj4gDQo+ ID4gMikgV2hhdCBkb2VzIGNvbmZvcm1hbmNlIHRvIGEgWUFORyAgbW9kdWxlIGUuZy4gaWV0Zi1z eXN0ZW0gbWVhbiBub3c/IERvIHdlDQo+ID4gbmVlZCB0byBsb2FkIHRoZSBtb2R1bGUgYXQgdGhl IHRvcCBsZXZlbCwgb3IgaXMgaXQgZW5vdWdoIHRvIG1vdW50IGl0DQo+ID4g4oCcc29tZXdoZXJl 4oCdIGluIHRoZSBjb250YWlubWVudCB0cmVlPw0KPiA+DQo+IA0KPiANCj4gSXQgbWVhbnMgdGhl IHNhbWUgaWYgdGhlIHNlcnZlciByZXR1cm5zICJpbXBsZW1lbnQiDQoNClllcy4NCg0KPiBNb3Vu dGluZyB0aGUgbW9kdWxlIHZpb2xhdGVzIHRoZSBjb250cmFjdCBiZWNhdXNlIHRoZQ0KPiBtb2R1 bGUgY2xlYXJseSBkZWZpbmVzIC9zeXN0ZW0gYXMgYSB0b3AtbGV2ZWwgbm9kZS4NCg0KTm8sIG1v dW50aW5nIGRvZXNuJ3QgYnJlYWsgdGhlIGNvbnRyYWN0LCBzaW5jZSB0aGUgY29udHJhY3QgKGJh c2UNCmlldGYteWFuZy1saWJyYXJ5KSBkb2Vzbid0IG1lbnRpb24gdGhlc2UgbW9kdWxlcy4NCg0K PiBBbnkgb3RoZXIgbG9jYXRpb24gaXMgbm9uLWNvbXBsaWFudC4NCg0KSSBhZ3JlZSBpdCB3b3Vs ZCBiZSBub24tY29tcGxpYW50IHRvIGxpc3QgYSBtb3VudGVkIG1vZHVsZSBpbiB0aGUgYmFzZQ0K aWV0Zi15YW5nLWxpYnJhcnkuICBUaGlzIGlzIHdoeSBtb3VudGVkIG1vZHVsZXMgYXJlIG5vdCBs aXN0ZWQuDQoNCj4gPiAzKSBJZiB0aGUgYW5zd2VyIHRvIDIpIGlzIGl0IGNhbiBiZSBtb3VudGVk IGFueXdoZXJlLCB3aGljaCBtb2R1bGVzIG11c3QgYmUNCj4gPiBwcmVzZW50IGF0IHRoZSB0b3Ag bGV2ZWw/IEUuZy4gaWV0Zi15YW5nLWxpYnJhcnk/DQo+ID4NCj4gDQo+IElNTyB0aGUgWUFORyBj b250cmFjdCBvbmx5IHN1cHBvcnRzIHRoZSBkYXRhIHBsYWNlbWVudCBleHBsaWNpdA0KPiBpbiB0 aGUgbW9kdWxlLg0KDQpBZ3JlZWQuDQoNCj4gPiA0KSBJZiBhIG5ldyBsaXN0IGVudHJ5IGlzIGNy ZWF0ZWQgY2FuIGl0IGludHJvZHVjZSBhIGNvbXBsZXRlbHkgbmV3IG1vZHVsZQ0KPiA+IG5ldmVy IGhlYXJkIG9mIGJlZm9yZSBpbiB0aGUgbmV0d29yayBlbGVtZW50Pw0KPiA+DQo+IA0KPiA/Pw0K PiANCj4gdGhpcyBpcyBmaW5lIGZvciAiYW55ZGF0YSINCj4gDQo+ID4gNSkgSU1ITyBhbGxvd2lu ZyBzdWNoIGR5bmFtaWMgaW50cm9kdWN0aW9uIG9mIG5ldyBZQU5HIG1vZHVsZXMgaW50byBhDQo+ ID4gbmV0d29yayBlbGVtZW50LCB3aXRoIGZsZXhpYmxlIG1vdW50cG9pbnRzLCBmbGV4aWJsZSBz ZXQgb2YgbW9kdWxlcyBhdCBlYWNoDQo+ID4gbW91bnRwb2ludCwgYSBmbGV4aWJsZSBzZXQgb2Yg ZGV2aWF0aW9ucyBhbmQgZmVhdHVyZXMgZm9yIGVhY2ggbW91bnRlZA0KPiA+IG1vZHVsZSBtYWtl cyBkaXNjb3ZlcnkgYWN0dWFsIGF2YWlsYWJsZSBzY2hlbWEgdHJlZSBkaWZmaWN1bHQuIEkgdGhp bmsgd2UNCj4gPiBhcmUgcHJvdmlkaW5nIHRvIG11Y2ggZmxleGliaWxpdHksIG92ZXItY29tcGxp Y2F0aW5nIHRoZSBpc3N1ZS4gU29tZSBtb3JlDQo+ID4gc3RhdGljIG1vdW50aW5nIHNvbHV0aW9u IHRoYXQgY2FuIGJlIHJlYWQgZnJvbSBZQU5HIG1vZHVsZXMgaW5zdGVhZCBvZg0KPiA+IHJ1bi10 aW1lIGRhdGEgd291bGQgYmUgZWFzaWVyLg0KPiA+DQo+IA0KPiBtb3VudCBpcyB3YXkgb3Zlci1l bmdpbmVlcmVkDQoNCldoYXQgZG8gbWVhbiB3aGVuIHlvdSB3cml0ZSAibW91bnQiPw0KDQo+IGJ1 dCBzY2hlbWEtZGVmaW5lZCBtb3VudC1wb2ludHMgZG9uJ3QgcmVhbGx5DQo+IGhlbHAuDQo+IEEg bmVzdGVkICJyb290IiB3b3JrcyBhbmQgaGFzIGEgdXNlLWNhc2UuDQoNClRoaXMgaXMgYWxsIHRo ZSBjdXJyZW50IHNjaGVtYSBtb3VudCBkb2VzLg0KDQo+IEV2ZXJ5dGhpbmcgZWxzZSBpcyBleHRy YQ0KPiBhbmQgYW4gaW1wbGVtZW50YXRpb24gY2hvaWNlIHdpdGhvdXQgYW55IHJlYWwgdXNlLWNh c2UuICBZQU5HIGlzIGFscmVhZHkNCj4gY29tcGxpY2F0ZWQgYW5kIHNsb3cuIG1vdW50IGFuZCBz eW0tbGlua3MgbWFrZXMgaXQgd29yc2UuDQoNCg0KL21hcnRpbg0KDQoNCg0KPiANCj4gcmVnYXJk cyBCYWxhenMNCj4gPg0KPiA+DQo+ID4NCj4gDQo+IEFuZHkNCj4gDQo+IA0KPiA+DQo+ID4gLS0N Cj4gPiBCYWxhenMgTGVuZ3llbCAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb24gSHVuZ2Fy eSBMdGQuDQo+ID4gU2VuaW9yIFNwZWNpYWxpc3QNCj4gPiBNb2JpbGU6ICszNi03MC0zMzAtNzkw OSAgICAgICAgICAgICAgZW1haWw6IEJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbQ0KPiA+DQo+ ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+DQo+ID4NCg== From nobody Mon May 9 08:02:42 2016 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 1BAEF12D0C3 for ; Mon, 9 May 2016 08:02:40 -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 Jmj7bhmeTCz2 for ; Mon, 9 May 2016 08:02:37 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 E7BC912B004 for ; Mon, 9 May 2016 08:02:36 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id m64so202962242lfd.1 for ; Mon, 09 May 2016 08:02:36 -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:date:message-id:subject:from:to :cc; bh=LkVkJqGHiDqZBevDP21j0IR88m5JRxaaR0X5mk7+9Iw=; b=1vwl6ivdlWwLf6VYYYmxwnnL4VrhzTofECFQmCAmuARowIqj3pbABli5bF1OR/DP9t qb+b+UesdL9wCf+TWP3PjWclTPyhgpTVEp/eH1/Dzkh816j7STZrypBk5RW1rnr8/VF2 dMoGd/e91GqCxMWHh/t3w6e8zCqybWVFrR3CTetAhyGBmdxD9YfGFJD4uMfsoCBeL4Ie tmTgBzebaaWNfyftW4mPq6t7jOIPVFlx7kIKLEVAM2IQZUTM8iRYuPwoI94anE10eO5P bILii8+hK0bCD1hSGRf80fYBJfZKS9eXVFLthHvmbZH4avCiCVVS8DSKZvSzuLANC5YH PZ9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LkVkJqGHiDqZBevDP21j0IR88m5JRxaaR0X5mk7+9Iw=; b=McvUmbNvchyHPCDbvlkkrq/UsL7BgPJ0klcBj9/KLVkBu4672CdBlIK+zZnkcJ/Ftu 5y+3eUycafEutnx2GDcWQYak6sR45bBbgzlokQKwwpN1/chLI+xbBpSvHux9WbaTzbKG NkBm0NDKXLqrXW5rYU/FGLBKPKcar1osuGcgYs1cJ0teSXQDrSinvs4Hvyx2crRtm5B1 8dJ/yFtwloG8q5CNCfeZYradwBYOt6sw6ONkw6LfUHFGp+GUwWwnRCntblgYYiiSHSCh VHfUJ0AVjGM3EhIuS59s9PXH+kip+9TcFwkDQ3KmGlFGmltIgb3PfxqSpCfFqcsYqfbg F1sw== X-Gm-Message-State: AOPr4FW9pvfxDtrnNYNnJRzW8U5sTuxzJGoBspa/TkH+y9MYUjbh73nMvz77A4+R+bpL2h3SbAksles8nUgPlw== MIME-Version: 1.0 X-Received: by 10.112.22.131 with SMTP id d3mr14927881lbf.145.1462806155084; Mon, 09 May 2016 08:02:35 -0700 (PDT) Received: by 10.112.13.133 with HTTP; Mon, 9 May 2016 08:02:34 -0700 (PDT) In-Reply-To: <20160509.152728.738155337458624523.mbj@tail-f.com> References: <20160509.152728.738155337458624523.mbj@tail-f.com> Date: Mon, 9 May 2016 08:02:34 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=14dae947364f3fdedc05326a1959 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Schema mount questions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 15:02:40 -0000 --14dae947364f3fdedc05326a1959 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, May 9, 2016 at 6:27 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, May 5, 2016 at 7:44 AM, Balazs Lengyel < > balazs.lengyel@ericsson.com> > > wrote: > > > > > Hello, > > > > > > 1) Will mounted YANG modules be listed in the base ietf-yang-library? > Even > > > the mounted ones? > > > > > > > Does the server providing the mounted modules claim conformance > > to those models? > > No, which is why they are not listed in the base ietf-yang-library. > > > IMO YANG mount breaks the "YANG API contract" if even 1 tiny > > property is ignored, due to mounting. > > Agree. > > > I asked for a conformance enum of 'none' or 'other' for this exact > purpose > > but > > the WG did not think it was possible for a server to do anything > > other than implement or import a YANG module. > > > > E.g, we are building a special server "library-mode" that just > > provided\s the library and get-schema for every module. > > They will all be listed as 'imported' (so that enum essentially > > becomes 'other') > > > > > > > 2) What does conformance to a YANG module e.g. ietf-system mean now? > Do we > > > need to load the module at the top level, or is it enough to mount it > > > =E2=80=9Csomewhere=E2=80=9D in the containment tree? > > > > > > > > > It means the same if the server returns "implement" > > Yes. > > > Mounting the module violates the contract because the > > module clearly defines /system as a top-level node. > > No, mounting doesn't break the contract, since the contract (base > ietf-yang-library) doesn't mention these modules. > > > Any other location is non-compliant. > > I agree it would be non-compliant to list a mounted module in the base > ietf-yang-library. This is why mounted modules are not listed. > > OK -- good. > > > 3) If the answer to 2) is it can be mounted anywhere, which modules > must be > > > present at the top level? E.g. ietf-yang-library? > > > > > > > IMO the YANG contract only supports the data placement explicit > > in the module. > > Agreed. > > > > 4) If a new list entry is created can it introduce a completely new > module > > > never heard of before in the network element? > > > > > > > ?? > > > > this is fine for "anydata" > > > > > 5) IMHO allowing such dynamic introduction of new YANG modules into a > > > network element, with flexible mountpoints, flexible set of modules a= t > each > > > mountpoint, a flexible set of deviations and features for each mounte= d > > > module makes discovery actual available schema tree difficult. I thin= k > we > > > are providing to much flexibility, over-complicating the issue. Some > more > > > static mounting solution that can be read from YANG modules instead o= f > > > run-time data would be easier. > > > > > > > mount is way over-engineered > > What do mean when you write "mount"? > > > but schema-defined mount-points don't really > > help. > > A nested "root" works and has a use-case. > > This is all the current schema mount does. > > This is the only variant I support. Renaming or relocating data (changing the ancestor path to the first root) is way too complicated and not relevant to a programmatic interface. This can be done in the presentation layer of the controller or application= . > > Everything else is extra > > and an implementation choice without any real use-case. YANG is alread= y > > complicated and slow. mount and sym-links makes it worse. > > > /martin > > > Andy > > > > > regards Balazs > > > > > > > > > > > > > Andy > > > > > > > > > > -- > > > Balazs Lengyel Ericsson Hungary Ltd. > > > Senior Specialist > > > Mobile: +36-70-330-7909 email: > Balazs.Lengyel@ericsson.com > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > --14dae947364f3fdedc05326a1959 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 9, 2016 at 6:27 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Thu, May 5, 2016 at 7:44 AM, Balazs Lengyel <balazs.lengyel@ericsson.com>
> wrote:
>
> > Hello,
> >
> > 1) Will mounted YANG modules be listed in the base ietf-yang-libr= ary? Even
> > the mounted ones?
> >
>
> Does the server providing the mounted modules claim conformance
> to those models?

No, which is why they are not listed in the base ietf-yang-library.

> IMO YANG mount breaks the "YANG API contract" if even 1 tiny=
> property is ignored, due to mounting.

Agree.

> I asked for a conformance enum of 'none' or 'other' fo= r this exact purpose
> but
> the WG did not think it was possible for a server to do anything
> other than implement or import a YANG module.
>
> E.g, we are building a special server "library-mode" that ju= st
> provided\s the library and get-schema for every module.
> They will all be listed as 'imported' (so that enum essentiall= y
> becomes 'other')
>
>
> > 2) What does conformance to a YANG=C2=A0 module e.g. ietf-system = mean now? Do we
> > need to load the module at the top level, or is it enough to moun= t it
> > =E2=80=9Csomewhere=E2=80=9D in the containment tree?
> >
>
>
> It means the same if the server returns "implement"

Yes.

> Mounting the module violates the contract because the
> module clearly defines /system as a top-level node.

No, mounting doesn't break the contract, since the contract (base
ietf-yang-library) doesn't mention these modules.

> Any other location is non-compliant.

I agree it would be non-compliant to list a mounted module in the base
ietf-yang-library.=C2=A0 This is why mounted modules are not listed.



OK -- good.
<= br>
=C2=A0
> > 3) If the answer to 2) is it can be mounted anywhere, which modul= es must be
> > present at the top level? E.g. ietf-yang-library?
> >
>
> IMO the YANG contract only supports the data placement explicit
> in the module.

Agreed.

> > 4) If a new list entry is created can it introduce a completely n= ew module
> > never heard of before in the network element?
> >
>
> ??
>
> this is fine for "anydata"
>
> > 5) IMHO allowing such dynamic introduction of new YANG modules in= to a
> > network element, with flexible mountpoints, flexible set of modul= es at each
> > mountpoint, a flexible set of deviations and features for each mo= unted
> > module makes discovery actual available schema tree difficult. I = think we
> > are providing to much flexibility, over-complicating the issue. S= ome more
> > static mounting solution that can be read from YANG modules inste= ad of
> > run-time data would be easier.
> >
>
> mount is way over-engineered

What do mean when you write "mount"?

> but schema-defined mount-points don't really
> help.
> A nested "root" works and has a use-case.

This is all the current schema mount does.



This is the only varian= t I support.

Renaming or relocating data (changing= the ancestor path to the first root)
is way too complicated and = not relevant to a programmatic interface.
This can be done in the= presentation layer of the controller or application.

<= div>
=C2=A0
> Everything else is extra
> and an implementation choice without any real use-case.=C2=A0 YANG is = already
> complicated and slow. mount and sym-links makes it worse.


/martin




Andy
=C2=A0

>
> regards Balazs
> >
> >
> >
>
> Andy
>
>
> >
> > --
> > Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 email: Balazs.Lengyel= @ericsson.com
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >

--14dae947364f3fdedc05326a1959-- From nobody Mon May 9 08:44:30 2016 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 EC3D912D102; Mon, 9 May 2016 08:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJKj2NAS3PM3; Mon, 9 May 2016 08:44:25 -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 D9BEE12D106; Mon, 9 May 2016 08:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31996; q=dns/txt; s=iport; t=1462808665; x=1464018265; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+BY36WFLPyXTIaaVciQbaoq0PzVPl18pzRXOKexCEOQ=; b=ejmeeD23tY4gYy/Tc2F1NZc7c7VPnVd+zuzJie8MKujUWUPu+1N2LNQy aYbH3RUmSww7rBlx24PtwPqNkBsTWQ6naJWmWdpMw9dpsgkSBiTX4RDRt sEid+8pUzRgRIaMov3dgJKH07GgZPJwnQf5cKrPzuQjetuICRY73ZTFGF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAgDmrzBX/4wNJK1dgmxMVW4PBrh/A?= =?us-ascii?q?Q2BdhcBDIUiSgIcgRU4FAEBAQEBAQFlJ4RBAQEBBAEBASBLCxACAQgRAwECIQc?= =?us-ascii?q?DAgICJQsUCQgCBA4FCRKIEA6vEZBVAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYgg?= =?us-ascii?q?XYIgk6CNYFmOwkWgkorgi4FjV6FToR2AYV8iB+BaYRPiF+GKYkRAR4BAUKCBRu?= =?us-ascii?q?BS24Bh0cCHgcYAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,601,1454976000"; d="scan'208,217";a="270648733" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2016 15:44:23 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u49FiN7r019060 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 May 2016 15:44:23 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 9 May 2016 11:44:22 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Mon, 9 May 2016 11:44:22 -0400 From: "Tarek Saad (tsaad)" To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" Thread-Topic: [netmod] Use of schema mounts for common model Thread-Index: AQHRoYTn8Q7ybSBq9EC0qN+9tgYLnp+hBBqAgAAeDQCABm+7AIAJPmKA Date: Mon, 9 May 2016 15:44:22 +0000 Message-ID: References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.203] Content-Type: multipart/alternative; boundary="_000_D5AA9261193D4100AF1581F4BF98654Cciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-yang-te@ietf.org" , "draft-ietf-netmod-schema-mount@ietf.org" Subject: Re: [netmod] Use of schema mounts for common model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 15:44:28 -0000 --_000_D5AA9261193D4100AF1581F4BF98654Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpUaGFua3MuIFBsZWFzZSBzZWUgaW5saW5l4oCmDQoNCkZyb206ICJSb2Jl cnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIiA8cndpbHRv bkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4NCkRhdGU6IFR1ZXNkYXksIE1h eSAzLCAyMDE2IGF0IDEwOjM0IEFNDQpUbzogVGFyZWsgU2FhZCA8dHNhYWRAY2lzY28uY29tPG1h aWx0bzp0c2FhZEBjaXNjby5jb20+Pg0KQ2M6IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYu Y29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+LCAiZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGVAaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtdGVhcy15YW5nLXRlQGlldGYub3JnPiIgPGRyYWZ0LWll dGYtdGVhcy15YW5nLXRlQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRlYXMteWFuZy10ZUBp ZXRmLm9yZz4+LCAibXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGll dGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4sICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz4iIDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+ LCAidGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4iIDx0ZWFzQGlldGYub3JnPG1h aWx0bzp0ZWFzQGlldGYub3JnPj4sICJkcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnRAaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudEBpZXRmLm9yZz4iIDxk cmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnRAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt bmV0bW9kLXNjaGVtYS1tb3VudEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gVXNl IG9mIHNjaGVtYSBtb3VudHMgZm9yIGNvbW1vbiBtb2RlbA0KDQoNCkhpIFRhcmVrLA0KDQpJJ20g YWxzbyB3b25kZXJpbmcgd2hldGhlciB1c2luZyBzY2hlbWEgbW91bnQgaW4gdGhpcyB3YXkgbWln aHQgYmUgYSBiaXQgbGlrZSB1c2luZyBhIHNsZWRnZWhhbW1lciB0byBjcmFjayBhIG51dC4NCg0K V2l0aCBpbnRlcmZhY2VzLCB0aGVyZSBpcyBhIHBlciBkZXZpY2UgZ2xvYmFsIGxpc3Qgb2YgaW50 ZXJmYWNlcyB3aGVyZSBlYWNoIGxpc3QgZW50cnkgY2FuIGhhdmUgYSBkaWZmZXJlbnQgdHlwZSBh bmQgZGlmZmVyZW50IHByb3BlcnRpZXMuICBDdXJyZW50bHkgdGhlc2UgYXJlIHVzaW5nIHRoZSBp YW5hOmlmdHlwZSB0byBkaWZmZXJlbnRpYXRlIHRoZWlyIGRpZmZlcmVudCBzY2hlbWEgbW9kZXMs IGJ1dCB0aGVyZSBpcyBhbiBpZGVhIHRvIHVzZSBtb3JlIGFic3RyYWN0IGlkZW50aXRpZXMuDQoN CkknbSBub3QgcmVhbGx5IGZhbWlsaWFyIHdpdGggdGhlIHR1bm5lbCBZQU5HIG1vZGVscywgYnV0 IEkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIHRoZSBzYW1lIGFwcHJvYWNoIGhhcyBiZWVuIGNvbnNp ZGVyZWQgZm9yIHRoZSBURSB0dW5uZWwgWUFORyBtb2RlbHMgYXQgYWxsPw0KDQpJLmUuIHJhdGhl ciB0aGFuIGhhdmluZyBhIHNlcGFyYXRlIHByb3RvY29sIGluc3RhbnRpYXRpb24gZm9yIGVhY2gg ZGlmZmVyZW50IGRhdGEgcGxhbmUgdGVjaG5vbG9neSwgaW5zdGVhZCBoYXZlIGEgcGVyIGRldmlj ZSBnbG9iYWwgbGlzdCBvZiB0dW5uZWxzIHRoYXQgaG9sZCB0aGUgY29uZmlndXJhdGlvbiBhbmQg b3BlcmF0aW9uYWwgc3RhdGUsIG1ha2luZyB1c2Ugb2Ygd2hlbiBzdGF0ZW1lbnRzIGFuZCBpZGVu dGl0aWVzIChpZiByZXF1aXJlZCkgdG8gbWFuYWdlIGRhdGFwbGFuZSBzcGVjaWZpYyBsZWF2ZXMu ICBFYWNoIHByb3RvY29sIHNwZWNpZmljIGRhdGEgcGxhbmUgbW9kdWxlIGNvdWxkIGFsc28gbWFp bnRhaW4gYSBwcm90b2NvbCBzcGVjaWZpYyBsaXN0IGNvbnRhaW5pbmcgbGVhZi1yZWZzIGJhY2sg dG8gdGhlIGFwcHJvcHJpYXRlIHR1bm5lbHMgaW4gdGhlIG1hc3RlciBsaXN0Lg0KDQpbVFNdOiBD dXJyZW50bHkgdGhlIFRFIHR1bm5lbCBtb2RlbCBoYXMgYSBnbG9iYWwgbGlzdCBvZiBpbnRlcmZh Y2VzLiBUaGUgdGVhbSBoYXMgZGlzY3Vzc2VkIHRoZSBpZGVhIG9mIGNvbnRpbnVpbmcgdG8gaGF2 ZSBhIHNpbmdsZSBnbG9iYWwgbGlzdCBhbmQgdGhlbiBhc3NpZ25pbmcgdGhlIHR1bm5lbCB0ZWNo bm9sb2d5IHR5cGUgb24gcGVyIHR1bm5lbC4gVGhpcyBpbXBsaWNhdGVzIHRoZSBmb2xsb3dpbmc6 DQoNCiAgMS4gIFRoZXJlIHdpbGwgYmUgMSBmdWxsIGxpc3Qgb2YgVEUgdHVubmVscyBmb3IgYWxs IHRlY2hub2xvZ3kgdHlwZXMuIFRoZSBsaXN0IHdpbGwgYmUga2V5ZWQgYnkgeyh0dW5uZWwgbmFt ZSkrKHR1bm5lbC10ZWNobm9sb2d5LXR5cGUpfS4gT24gbm9kZXMgdGhhdCBtYXkgc3VwcG9ydCBt dWx0aXBsZSB0ZWNobm9sb2d5IHR5cGVzIChlLmcuIFBhY2tldCBhbmQgb3B0aWNhbCksIHRoZSB0 dW5uZWxzL0xTUHMgZm9yIG11bHRpcGxlIHRlY2hub2xvZ2llcyB3aWxsIGJlIGludGVybWl4ZWQg aW4gdGhlIHNhbWUgbGlzdC4NCiAgMi4gIFRoZSBzYW1lIGdvZXMgZm9yIHRoZSBsaXN0IG9mIExT UHMgKGluc3RhbnRpYXRpb25zIG9mIHR1bm5lbHMgb24gaW5ncmVzcy90cmFuc2l0L2VncmVzcyBu b2Rlcy4uIEluIHRoaXMgY2FzZSwgc3VjaCBMU1BzIG9mIGRpZmZlcmVudCB0ZWNobm9sb2d5IHBh cnRzIHdpbGwgYmUgaW50ZXJtaXhlZCB0b28uDQoNClRoaXMgaXMgcG9zc2libGUsIGJ1dCBtYXkg bm90IGJlIG1vc3QgZWxlZ2FudCB3YXkgb2YgcHJlc2VudGluZyB0aGlzLi4gV2Ugd2VyZSBob3Bp bmcgaXQgd2lsbCBiZSBwb3NzaWJsZSB0byBoYXZlIHRoZSBzZWdyZWdhdGlvbiBvbiBwZXIgdGVj aG5vbG9neSBieSBtb3VudGluZyB0aGUgdHVubmVsIGxpc3QgdW5kZXIgdGhlIHJlc3BlY3RpdmUg dGVjaG5vbG9neSAocGFja2V0LCBvdG4sIGV0Yy4pLi4NCkxhc3RseSwgcGxheWluZyBkZXZpbOKA mXMgYWR2b2NhdGUgOiksIG9uZSBjb3VsZCBhcmd1ZSBpdOKAmXMgYWxzbyBwb3NzaWJsZSB0byBo YXZlIG9uZSBnbG9iYWwgbGlzdCBvZiBpbnRlcmZhY2VzIGluIHRoZSBpbnRlcmZhY2VzIG1vZGVs IGFuZCBtYWtlIHRoZSBkZXZpY2UvVk0gYW4gYXR0cmlidXRlIChhbmQgcGFydCBvZiB0aGUga2V5 KSBvZiB0aGUgaW50ZXJmYWNlIGxpc3QuLiBUaGF0IGlzIGFuIGludGVyZmFjZSBuYW1lIGZvbyBj YW4gYXBwZWFyIG11bHRpcGxlIHRpbWVzIGluIHRoZSBpbnRlcmZhY2UgbGlzdCAob25jZSBwZXIg Vk0gb3IgcGh5c2ljYWwpLi4gT2YgY291cnNlLCBJTU8gdGhlIG1vdW50aW5nIHByb3Bvc2FsIGlz IG1vcmUgZWxlZ2FudCBpbiB0aGlzIGNhc2UuLg0KDQpSZWdhcmRzLA0KVGFyZWsNCg0KDQpUaGFu a3MsDQpSb2INCg0KDQpPbiAyOS8wNC8yMDE2IDE3OjE3LCBUYXJlayBTYWFkICh0c2FhZCkgd3Jv dGU6DQpUaGFua3MgTWFydGluLCBwbGVhc2Ugc2VlIGlubGluZS4uDQoNCg0KT24gMjAxNi0wNC0y OSwgNjoyOSBBTSwgIk1hcnRpbiBCam9ya2x1bmQiIDw8bWFpbHRvOm1iakB0YWlsLWYuY29tPm1i akB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+IHdyb3RlOg0KDQoiVGFyZWsgU2Fh ZCAodHNhYWQpIiA8dHNhYWRAY2lzY28uY29tPG1haWx0bzp0c2FhZEBjaXNjby5jb20+PiB3cm90 ZToNCkhpIGF1dGhvcnMvV0csDQpJbiBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZSwgd2UgYXJlIGRy aXZpbmcgdGhlIGRlZmluaXRpb24gZm9yIGENCmdlbmVyaWMgVEUgWUFORyBtb2RlbCB0aGF0IGNh bi9tYXkgYmUgdXNlZCAoYW5kIGV4dGVuZGVkIHdoZW4NCm5lY2Vzc2FyeSkgZm9yIGRpZmZlcmVu dCBkYXRhIHBsYW5lIHRlY2hub2xvZ2llcyAoZS5nLiBNUExTLCBPVE4sIFdETSwNCmV0Yy4pLg0K UmV2aWV3aW5nIHRoZSBzY2hlbWEgbW91bnQgaWRlYSBwcmVzZW50ZWQgaW4NCmRyYWZ0LWlldGYt bmV0bW9kLXNjaGVtYS1tb3VudCwgd2UgYXJlIHRoaW5raW5nIHRoaXMgcHJvcG9zYWwgaXMNCnVz ZWZ1bCBhbmQgY2FuIGZhY2lsaXRhdGUgdGhlIHJldXNlIG9mIHRoZSBvdXIgbW9kZWwgaW4gbXVs dGlwbGUNCnBsYWNlcyBpbiB0aGUgWUFORyB0cmVlIChvbmNlIHBlciBlYWNoIHRlY2hub2xvZ3kp LCBlLmcuOg0K4oCmL21wbHMvbW91bnQtcG9pbnRzL21vdW50LXBvaW50L21vZHVsZT1pZXRmLXRl LnlhbmcNCuKApi9vdG4vbW91bnQtcG9pbnRzL21vdW50LXBvaW50L21vZHVsZT1pZXRmLXRlLnlh bmcNCg0KU2NoZW1hIG1vdW50IGlzIHByb2JhYmx5IG5vdCB0aGUgcmlnaHQgc29sdXRpb24gdG8g eW91ciBwcm9ibGVtLiAgSQ0KdGhpbmsgYSBiZXR0ZXIgc29sdXRpb24gaW4geW91ciBjYXNlIGlz IHRvIGRlZmluZSBncm91cGluZ3MuDQpHcm91cGluZ3MgYXJlIGRlc2lnbmVkIHRvIGJlIHJlLXVz ZWQgYXQgZGlmZmVyZW50IHBsYWNlcyBpbiB0aGUNCmhpZXJhcmNoeS4NCg0KV2UgdGhvdWdodCBv ZiB0aGlzIGVhcmxpZXIsIGFuZCBmb3VuZCBncm91cGluZ3MgcG9zZSB0aGVpciBvd24gc2V0IG9m IGNoYWxsZW5nZXMgdG9vLi4gU3BlY2lmaWNhbGx5Og0KLSBhIGdyb3VwaW5ncyB3aXRoIGxlYWZy ZWZzIGNvdWxkIG5vdCByZWZlcmVuY2UgZGF0YSBub2RlcyB0aGF0IHJlc2lkZSBpbiBhbm90aGVy IGdyb3VwaW5nDQotIGEgZ3JvdXBpbmcgd2l0aCBsZWFmcmVmcyBvZiByZWxhdGl2ZSBwYXRoIHdl cmUgY2hhbGxlbmdlIHdoZW4gdGhlIHJlbGF0aXZlIHBhdGggcmVmZXJlbmNlcyBkYXRhIG5vZGVz IG91dHNpZGUgdGhlIGdyb3VwaW5nDQotIHRoZSBhdWdtZW50YXRpb24gb2YgdGhlIGdyb3VwaW5n IGJ5IG90aGVyIG1vZHVsZXMgaXMgbm90IGFzIHN0cmFpZ2h0Zm9yd2FyZA0KDQpUaGF0IHNhaWQs IHRoZSBncm91cGluZyBwcm9wb3NhbCBzZWVtcyB0bw0KDQpvbmUgY291bGQgYWxzbyB0aGluayB0 aGF0IHdpdGggZ3JvdXBpbmdzIG9uZSBjb3VsZCBhZGRyZXNzIHJldXNlIG9mIHRoZSBhIG1vZGVs IChlLmcuIElldGYtaW50ZXJmYWNlcykgZm9yIGxvZ2ljYWwgZGV2aWNlcyBvciBWTSAoc2VlIGJl bG93KS4gSW4gZmFjdCwgaW4geW91ciBkcmFmdCAoc2VjdGlvbiAyKSB5b3UgZXhwbGljaXRseSBk aXNjb3VyYWdlIHRoaXMgYXBwcm9hY2ggYXMgbm90IHNjYWxhYmxlIHNvbHV0aW9uDQoNCg0KICAg V2l0aCB0aGUgInVzZXMiIGFwcHJvYWNoLCBpZXRmLWludGVyZmFjZXMgd291bGQgaGF2ZSB0byBk ZWZpbmUgYQ0KICAgZ3JvdXBpbmcgd2l0aCBhbGwgaXRzIG5vZGVzLCBhbmQgdGhlIG5ldyBtb2Rl bCBmb3IgbG9naWNhbCBkZXZpY2VzDQogICB3b3VsZCBoYXZlIHRvIHVzZSB0aGlzIGdyb3VwaW5n LiAgVGhpcyBpcyBhIG5vdCBhIHNjYWxhYmxlIHNvbHV0aW9uLA0KICAgc2luY2UgZXZlcnkgdGlt ZSB0aGVyZSBpcyBhIG5ldyBtb2RlbCBkZWZpbmVkLCB3ZSB3b3VsZCBoYXZlIHRvDQogICB1cGRh dGUgb3VyIG1vZGVsIGZvciBsb2dpY2FsIGRldmljZXMgdG8gdXNlIGEgZ3JvdXBpbmcgZnJvbSB0 aGUgbmV3DQogICBtb2RlbC4gIEFub3RoZXIgcHJvYmxlbSBpcyB0aGF0IHRoaXMgYXBwcm9hY2gg Y2Fubm90IGhhbmRsZSB2ZW5kb3ItDQoNCg0KDQpXZSBoYXZlIGEgY29tbWVudC9jb25jZXJuL3N1 Z2dlc3Rpb24gYW5kIHdlIHZhbHVlIHlvdXIgZmVlZGJhY2suDQpUaGUgZ2VuZXJpYyBURSBtb2Rl bCBjdXJyZW50bHkgcmVmZXJlbmNlcyBkYXRhIG5vZGVzIGluIHRoZSBnbG9iYWwNCnRyZWUgKGUu Zy4gZnJvbSB0aGUgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsIHRvIGRlZmluZSBhZGRpdGlvbmFsIFRF DQpwcm9wZXJ0aWVzIGFzc29jaWF0ZWQgd2l0aCBhIHNwZWNpZmljIGRldmljZSBpbnRlcmZhY2Up LiBPdXINCnVuZGVyc3RhbmRpbmcgYWZ0ZXIgcmVhZGluZyBzZWN0aW9uIDMuMSBvZiB5b3VyIGRy YWZ0IGlzIHRoZSBtb3VudGVkDQptb2RlbCBjYW4gKm5vdCogcmVmZXJlbmNlIGFueSBkYXRhIG5v ZGVzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZQ0KbW91bnQtcG9pbnQgKGUuZy4gZ2xvYmFsIGRh dGEgbm9kZXMgaW4gdGhlIHlhbmcgdHJlZSkuIFRoaXMgcG9zZXMgYQ0KbGltaXRhdGlvbiBmb3Ig dXMsIGRvIHlvdSBoYXZlIGEgc3VnZ2VzdGlvbiBmb3IgdGhpcyBwcm9ibGVtPw0KT25lIHBvc3Np YmxlIHNvbHV0aW9uIHdlIHRob3VnaHQgb2Ygd2FzIHRvIHJlcGxhY2UgdGhlIGxlYWYtcmVmcw0K cG9pbnRpbmcgdG8gdGhlIGdsb2JhbCBkYXRhIG5vZGVzIChlLmcuIElldGYtaW50ZXJmYWNlcykg d2l0aCBjb250ZXh0DQpuYW1lcyAoZS5nLiB0aGUgaW50ZXJmYWNlIG5hbWUpLi4gVGhpcyBkZWNv dXBsZXMgdGhlIGRhdGEtbm9kZXMNCmRlZmluZWQgaW4gdGhlIFRFIGdlbmVyaWMgbW9kZWwgZnJv bSB0aG9zZSBpbiB0aGUgZ2xvYmFsIHRyZWUNCihlLmcuIHRoZSBhY3R1YWwgaW50ZXJmYWNlIGll dGYtaW50ZXJmYWNlcyBtb2RlbCkuIEFueSBmZWVkYmFjayBvbg0KdGhpcyBvciBiZXR0ZXIgc3Vn Z2VzdGlvbnM/DQoNCklmIHlvdSB1c2UgZ3JvdXBpbmdzIGluc3RlYWQsIHlvdSBjYW4gc3RpbGwg dXNlIHByb3BlciBsZWFmcmVmcy4NCg0KTm90IGluIGFsbCBjYXNlcyDigJQgYXMgZGVzY3JpYmVk IGFib3ZlLg0KDQpSZWdhcmRzLA0KVGFyZWsNCg0KDQoNCi9tYXJ0aW4NCg0KDQoNClJlZ2FyZHMs DQpUYXJlaw0KRXhjZXJwdCBmcm9tIGRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudA0KMy4x PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91 bnQtMDEjc2VjdGlvbi0zLjE+Lg0KQXVnbWVudCBhbmQgVmFsaWRhdGlvbiBpbiBNb3VudGVkIERh dGENCiAgICBBbGwgcGF0aHMgKGluIGxlYWZyZWZzLCBpbnN0YW5jZS1pZGVudGlmaWVycywgWFBh dGggZXhwcmVzc2lvbnMsIGFuZA0KICAgIHRhcmdldCBub2RlcyBvZiBhdWdtZW50cykgaW4gdGhl IGRhdGEgbW9kZWxzIG1vdW50ZWQgYXQgYSBtb3VudCBwb2ludA0KICAgIGFyZSBpbnRlcnByZXRl ZCB3aXRoIHRoZSBtb3VudCBwb2ludCBhcyB0aGUgcm9vdCBub2RlLCBhbmQgdGhlDQogICAgbW91 bnRlZCBkYXRhIG5vZGVzIGFzIGl0cyBjaGlsZHJlbi4gIFRoaXMgbWVhbnMgdGhhdCBkYXRhIHdp dGhpbiBhDQogICAgbW91bnRlZCBzdWJ0cmVlIGNhbiBuZXZlciByZWZlciB0byBkYXRhIG91dHNp ZGUgb2YgdGhpcyBzdWJ0cmVlLg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCg0K --_000_D5AA9261193D4100AF1581F4BF98654Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K PGRpdj4NCjxkaXY+SGkgUm9iZXJ0LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhh bmtzLiBQbGVhc2Ugc2VlIGlubGluZeKApjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRM T09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBC T1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURE SU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBC T1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsg UEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTog PC9zcGFuPiZxdW90O1JvYmVydCBXaWx0b24gLVggKHJ3aWx0b24gLSBFTlNPRlQgTElNSVRFRCBh dCBDaXNjbykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+cndp bHRvbkBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5EYXRlOiA8L3NwYW4+VHVlc2RheSwgTWF5IDMsIDIwMTYgYXQgMTA6MzQgQU08YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5UYXJlayBTYWFkICZsdDs8YSBo cmVmPSJtYWlsdG86dHNhYWRAY2lzY28uY29tIj50c2FhZEBjaXNjby5jb208L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPk1hcnRpbiBCam9ya2x1 bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJqQHRhaWwtZi5jb208L2E+ Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdGVhcy15YW5nLXRlQGlldGYu b3JnIj5kcmFmdC1pZXRmLXRlYXMteWFuZy10ZUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpkcmFmdC1pZXRmLXRlYXMteWFuZy10ZUBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi10 ZWFzLXlhbmctdGVAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86bXBs c0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpt cGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0 bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8 YSBocmVmPSJtYWlsdG86dGVhc0BpZXRmLm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4mcXVvdDsNCiAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+Jmd0Oywg JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudEBpZXRm Lm9yZyI+ZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50QGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudEBpZXRmLm9y ZyI+ZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50QGlldGYub3JnPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbbmV0bW9k XSBVc2Ugb2Ygc2NoZW1hIG1vdW50cyBmb3IgY29tbW9uIG1vZGVsPGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+DQo8ZGl2Pg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4NCjxwPkhp IFRhcmVrLDxicj4NCjwvcD4NCjxwPkknbSBhbHNvIHdvbmRlcmluZyB3aGV0aGVyIHVzaW5nIHNj aGVtYSBtb3VudCBpbiB0aGlzIHdheSBtaWdodCBiZSBhIGJpdCBsaWtlIHVzaW5nIGEgc2xlZGdl aGFtbWVyIHRvIGNyYWNrIGEgbnV0LjwvcD4NCjxwPldpdGggaW50ZXJmYWNlcywgdGhlcmUgaXMg YSBwZXIgZGV2aWNlIGdsb2JhbCBsaXN0IG9mIGludGVyZmFjZXMgd2hlcmUgZWFjaCBsaXN0IGVu dHJ5IGNhbiBoYXZlIGEgZGlmZmVyZW50IHR5cGUgYW5kIGRpZmZlcmVudCBwcm9wZXJ0aWVzLiZu YnNwOyBDdXJyZW50bHkgdGhlc2UgYXJlIHVzaW5nIHRoZSBpYW5hOmlmdHlwZSB0byBkaWZmZXJl bnRpYXRlIHRoZWlyIGRpZmZlcmVudCBzY2hlbWEgbW9kZXMsIGJ1dCB0aGVyZSBpcyBhbiBpZGVh IHRvIHVzZQ0KIG1vcmUgYWJzdHJhY3QgaWRlbnRpdGllcy48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9zcGFuPjwvc3Bhbj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ DQo8ZGl2Pg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4NCjxwPkknbSBu b3QgcmVhbGx5IGZhbWlsaWFyIHdpdGggdGhlIHR1bm5lbCBZQU5HIG1vZGVscywgYnV0IEkgd2Fz IHdvbmRlcmluZyB3aGV0aGVyIHRoZSBzYW1lIGFwcHJvYWNoIGhhcyBiZWVuIGNvbnNpZGVyZWQg Zm9yIHRoZSBURSB0dW5uZWwgWUFORyBtb2RlbHMgYXQgYWxsPzwvcD4NCjxwPkkuZS4gcmF0aGVy IHRoYW4gaGF2aW5nIGEgc2VwYXJhdGUgcHJvdG9jb2wgaW5zdGFudGlhdGlvbiBmb3IgZWFjaCBk aWZmZXJlbnQgZGF0YSBwbGFuZSB0ZWNobm9sb2d5LCBpbnN0ZWFkIGhhdmUgYSBwZXIgZGV2aWNl IGdsb2JhbCBsaXN0IG9mIHR1bm5lbHMgdGhhdCBob2xkIHRoZSBjb25maWd1cmF0aW9uIGFuZCBv cGVyYXRpb25hbCBzdGF0ZSwgbWFraW5nIHVzZSBvZiB3aGVuIHN0YXRlbWVudHMgYW5kIGlkZW50 aXRpZXMgKGlmIHJlcXVpcmVkKQ0KIHRvIG1hbmFnZSBkYXRhcGxhbmUgc3BlY2lmaWMgbGVhdmVz LiZuYnNwOyBFYWNoIHByb3RvY29sIHNwZWNpZmljIGRhdGEgcGxhbmUgbW9kdWxlIGNvdWxkIGFs c28gbWFpbnRhaW4gYSBwcm90b2NvbCBzcGVjaWZpYyBsaXN0IGNvbnRhaW5pbmcgbGVhZi1yZWZz IGJhY2sgdG8gdGhlIGFwcHJvcHJpYXRlIHR1bm5lbHMgaW4gdGhlIG1hc3RlciBsaXN0LjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDE0cHg7Ij4NCjxiPjxpPltUU106IEN1cnJlbnRseSB0aGUgVEUgdHVubmVsIG1vZGVsIGhh cyBhIGdsb2JhbCBsaXN0IG9mIGludGVyZmFjZXMuIFRoZSB0ZWFtIGhhcyBkaXNjdXNzZWQgdGhl IGlkZWEgb2YgY29udGludWluZyB0byBoYXZlIGEgc2luZ2xlIGdsb2JhbCBsaXN0IGFuZCB0aGVu IGFzc2lnbmluZyB0aGUgdHVubmVsIHRlY2hub2xvZ3kgdHlwZSBvbiBwZXIgdHVubmVsLiBUaGlz IGltcGxpY2F0ZXMgdGhlIGZvbGxvd2luZzo8L2k+PC9iPjwvZGl2Pg0KPG9sPg0KPGxpIHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+DQo8Yj48aT5UaGVyZSB3aWxsIGJlIDEgZnVsbCBsaXN0IG9mIFRF IHR1bm5lbHMgZm9yIGFsbCB0ZWNobm9sb2d5IHR5cGVzLiBUaGUgbGlzdCB3aWxsIGJlIGtleWVk IGJ5IHsodHVubmVsIG5hbWUpJiM0MzsodHVubmVsLXRlY2hub2xvZ3ktdHlwZSl9LiBPbiBub2Rl cyB0aGF0IG1heSBzdXBwb3J0IG11bHRpcGxlIHRlY2hub2xvZ3kgdHlwZXMgKGUuZy4gUGFja2V0 IGFuZCBvcHRpY2FsKSwgdGhlIHR1bm5lbHMvTFNQcyBmb3IgbXVsdGlwbGUgdGVjaG5vbG9naWVz DQogd2lsbCBiZSBpbnRlcm1peGVkIGluIHRoZSBzYW1lIGxpc3QuPC9pPjwvYj48L2xpPjxsaT48 Yj48aT48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPlRoZSBzYW1lIGdvZXMgZm9yIHRo ZSBsaXN0IG9mIExTUHMgKGluc3RhbnRpYXRpb25zIG9mIHR1bm5lbHMgb24gaW5ncmVzcy90cmFu c2l0L2VncmVzcyBub2Rlcy4uIEluIHRoaXMgY2FzZSwgc3VjaCBMU1BzIG9mIGRpZmZlcmVudCB0 ZWNobm9sb2d5IHBhcnRzIHdpbGwgYmUgaW50ZXJtaXhlZCB0b28uPC9mb250PjwvaT48L2I+PC9s aT48L29sPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGI+PGk+VGhpcyBpcyBwb3Nz aWJsZSwgYnV0IG1heSBub3QgYmUgbW9zdCBlbGVnYW50IHdheSBvZiBwcmVzZW50aW5nIHRoaXMu LiBXZSB3ZXJlIGhvcGluZyBpdCB3aWxsIGJlIHBvc3NpYmxlIHRvIGhhdmUgdGhlIHNlZ3JlZ2F0 aW9uIG9uIHBlciB0ZWNobm9sb2d5IGJ5IG1vdW50aW5nIHRoZSB0dW5uZWwgbGlzdCB1bmRlciB0 aGUgcmVzcGVjdGl2ZSB0ZWNobm9sb2d5IChwYWNrZXQsIG90biwgZXRjLikuLjwvaT48L2I+PC9k aXY+DQo8ZGl2PjxiPjxpPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+TGFzdGx5LCBw bGF5aW5nIGRldmls4oCZcyBhZHZvY2F0ZSA6KSwgb25lIGNvdWxkIGFyZ3VlIGl04oCZcyBhbHNv IHBvc3NpYmxlIHRvIGhhdmUgb25lIGdsb2JhbCBsaXN0IG9mIGludGVyZmFjZXMgaW4gdGhlIGlu dGVyZmFjZXMgbW9kZWwgYW5kIG1ha2UgdGhlIGRldmljZS9WTSBhbiBhdHRyaWJ1dGUgKGFuZCBw YXJ0IG9mIHRoZSBrZXkpIG9mIHRoZSBpbnRlcmZhY2UgbGlzdC4uDQogVGhhdCBpcyBhbiBpbnRl cmZhY2UgbmFtZSBmb28gY2FuIGFwcGVhciBtdWx0aXBsZSB0aW1lcyBpbiB0aGUgaW50ZXJmYWNl IGxpc3QgKG9uY2UgcGVyIFZNIG9yIHBoeXNpY2FsKS4uIE9mIGNvdXJzZSwgSU1PIHRoZSBtb3Vu dGluZyBwcm9wb3NhbCBpcyBtb3JlIGVsZWdhbnQgaW4gdGhpcyBjYXNlLi4mbmJzcDs8L2ZvbnQ+ PC9pPjwvYj48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxiPjxpPjxicj4N CjwvaT48L2I+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Yj48aT5SZWdh cmRzLDwvaT48L2I+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Yj48aT5U YXJlazwvaT48L2I+PC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP TiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij4NCjxkaXY+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAw MDAiPg0KPHA+PGJyPg0KPC9wPg0KPHA+VGhhbmtzLDxicj4NClJvYjwvcD4NCjxwPjxicj4NCjwv cD4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMjkvMDQvMjAxNiAxNzoxNywgVGFy ZWsgU2FhZCAodHNhYWQpIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlk OjUwQkVBQTRFLUM2NDUtNERDRS1BOTkyLTQ0QjE0QjRFRkM0M0BjaXNjby5jb20iIHR5cGU9ImNp dGUiPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMs IG1vbm9zcGFjZTsiPg0KPGRpdj5UaGFua3MgTWFydGluLCBwbGVhc2Ugc2VlIGlubGluZS4uPC9k aXY+DQo8ZGl2Pg0KPGRpdiBpZD0iIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25z b2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEy cHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+T24gMjAxNi0wNC0yOSwgNjoy OSBBTSwgJnF1b3Q7TWFydGluIEJqb3JrbHVuZCZxdW90OyAmbHQ7PGEgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIiBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPjwvYT48YSBjbGFzcz0ibW96LXR4 dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1iakB0YWls LWYuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7 IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImZvbnQt c2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7DQogICAgICAgIGJv cmRlci1sZWZ0LWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRlci1sZWZ0LXdpZHRoOiA1 cHg7DQogICAgICAgIGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZzogMHB4IDBweCAw cHggNXB4OyBtYXJnaW46IDBweA0KICAgICAgICAwcHggMHB4IDVweDsiPg0KPGRpdj4mcXVvdDtU YXJlayBTYWFkICh0c2FhZCkmcXVvdDsgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJl Zj0ibWFpbHRvOnRzYWFkQGNpc2NvLmNvbSI+dHNhYWRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9U RSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsg TUFSR0lOOjANCiAgICAgICAgICAwIDAgNTsiPg0KPGRpdj5IaSBhdXRob3JzL1dHLDwvZGl2Pg0K PGRpdj5JbiBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZSwgd2UgYXJlIGRyaXZpbmcgdGhlIGRlZmlu aXRpb24gZm9yIGE8L2Rpdj4NCjxkaXY+Z2VuZXJpYyBURSBZQU5HIG1vZGVsIHRoYXQgY2FuL21h eSBiZSB1c2VkIChhbmQgZXh0ZW5kZWQgd2hlbjwvZGl2Pg0KPGRpdj5uZWNlc3NhcnkpIGZvciBk aWZmZXJlbnQgZGF0YSBwbGFuZSB0ZWNobm9sb2dpZXMgKGUuZy4gTVBMUywgT1ROLCBXRE0sPC9k aXY+DQo8ZGl2PmV0Yy4pLjwvZGl2Pg0KPGRpdj5SZXZpZXdpbmcgdGhlIHNjaGVtYSBtb3VudCBp ZGVhIHByZXNlbnRlZCBpbjwvZGl2Pg0KPGRpdj5kcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91 bnQsIHdlIGFyZSB0aGlua2luZyB0aGlzIHByb3Bvc2FsIGlzPC9kaXY+DQo8ZGl2PnVzZWZ1bCBh bmQgY2FuIGZhY2lsaXRhdGUgdGhlIHJldXNlIG9mIHRoZSBvdXIgbW9kZWwgaW4gbXVsdGlwbGU8 L2Rpdj4NCjxkaXY+cGxhY2VzIGluIHRoZSBZQU5HIHRyZWUgKG9uY2UgcGVyIGVhY2ggdGVjaG5v bG9neSksIGUuZy46PC9kaXY+DQo8ZGl2PuKApi9tcGxzL21vdW50LXBvaW50cy9tb3VudC1wb2lu dC9tb2R1bGU9aWV0Zi10ZS55YW5nPC9kaXY+DQo8ZGl2PuKApi9vdG4vbW91bnQtcG9pbnRzL21v dW50LXBvaW50L21vZHVsZT1pZXRmLXRlLnlhbmc8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlNjaGVtYSBtb3VudCBpcyBwcm9iYWJseSBub3QgdGhlIHJpZ2h0 IHNvbHV0aW9uIHRvIHlvdXIgcHJvYmxlbS4mbmJzcDsmbmJzcDtJPC9kaXY+DQo8ZGl2PnRoaW5r IGEgYmV0dGVyIHNvbHV0aW9uIGluIHlvdXIgY2FzZSBpcyB0byBkZWZpbmUgZ3JvdXBpbmdzLjwv ZGl2Pg0KPGRpdj5Hcm91cGluZ3MgYXJlIGRlc2lnbmVkIHRvIGJlIHJlLXVzZWQgYXQgZGlmZmVy ZW50IHBsYWNlcyBpbiB0aGU8L2Rpdj4NCjxkaXY+aGllcmFyY2h5LjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMs IG1vbm9zcGFjZTsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBm b250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPldlIHRob3VnaHQgb2YgdGhpcyBlYXJs aWVyLCBhbmQgZm91bmQgZ3JvdXBpbmdzIHBvc2UgdGhlaXIgb3duIHNldCBvZiBjaGFsbGVuZ2Vz IHRvby4uIFNwZWNpZmljYWxseTo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsg Zm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij4tIGEgZ3JvdXBpbmdzIHdpdGggbGVh ZnJlZnMgY291bGQgbm90IHJlZmVyZW5jZSBkYXRhIG5vZGVzIHRoYXQgcmVzaWRlIGluIGFub3Ro ZXIgZ3JvdXBpbmc8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9udC1mYW1p bHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij4tIGEgZ3JvdXBpbmcgd2l0aCBsZWFmcmVmcyBvZiBy ZWxhdGl2ZSBwYXRoIHdlcmUgY2hhbGxlbmdlIHdoZW4gdGhlIHJlbGF0aXZlIHBhdGggcmVmZXJl bmNlcyBkYXRhIG5vZGVzIG91dHNpZGUgdGhlIGdyb3VwaW5nPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+LSB0aGUg YXVnbWVudGF0aW9uIG9mIHRoZSBncm91cGluZyBieSBvdGhlciBtb2R1bGVzIGlzIG5vdCBhcyBz dHJhaWdodGZvcndhcmQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9udC1m YW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtc2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij5UaGF0IHNh aWQsIHRoZSBncm91cGluZyBwcm9wb3NhbCBzZWVtcyB0byZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29u c29sYXMsIG1vbm9zcGFjZTsiPm9uZSBjb3VsZCBhbHNvIHRoaW5rIHRoYXQgd2l0aCBncm91cGlu Z3Mgb25lIGNvdWxkIGFkZHJlc3MgcmV1c2Ugb2YgdGhlIGEgbW9kZWwgKGUuZy4gSWV0Zi1pbnRl cmZhY2VzKSBmb3IgbG9naWNhbCBkZXZpY2VzIG9yIFZNIChzZWUgYmVsb3cpLiBJbiBmYWN0LCBp biB5b3VyIGRyYWZ0IChzZWN0aW9uIDIpIHlvdSBleHBsaWNpdGx5IGRpc2NvdXJhZ2UNCiB0aGlz IGFwcHJvYWNoIGFzIG5vdCBzY2FsYWJsZSBzb2x1dGlvbjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMs IG1vbm9zcGFjZTsiPjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQgc3R5bGU9ImZvbnQt c2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwNCiAgICAgICAgICAgIDI1NSwg MCk7IiBmYWNlPSJDb25zb2xhcyxtb25vc3BhY2UiPiZuYnNwOyAmbmJzcDtXaXRoIHRoZSAmcXVv dDt1c2VzJnF1b3Q7IGFwcHJvYWNoLCBpZXRmLWludGVyZmFjZXMgd291bGQgaGF2ZSB0byBkZWZp bmUgYTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwNCiAgICAgICAgICAgIDI1NSwgMCk7IiBmYWNlPSJDb25z b2xhcyxtb25vc3BhY2UiPiZuYnNwOyAmbmJzcDtncm91cGluZyB3aXRoIGFsbCBpdHMgbm9kZXMs IGFuZCB0aGUgbmV3IG1vZGVsIGZvciBsb2dpY2FsIGRldmljZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs DQogICAgICAgICAgICAyNTUsIDApOyIgZmFjZT0iQ29uc29sYXMsbW9ub3NwYWNlIj4mbmJzcDsg Jm5ic3A7d291bGQgaGF2ZSB0byB1c2UgdGhpcyBncm91cGluZy4gJm5ic3A7VGhpcyBpcyBhIG5v dCBhIHNjYWxhYmxlIHNvbHV0aW9uLDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc3R5bGU9ImZv bnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwNCiAgICAgICAgICAgIDI1 NSwgMCk7IiBmYWNlPSJDb25zb2xhcyxtb25vc3BhY2UiPiZuYnNwOyAmbmJzcDtzaW5jZSBldmVy eSB0aW1lIHRoZXJlIGlzIGEgbmV3IG1vZGVsIGRlZmluZWQsIHdlIHdvdWxkIGhhdmUgdG88L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsDQogICAgICAgICAgICAyNTUsIDApOyIgZmFjZT0iQ29uc29sYXMsbW9u b3NwYWNlIj4mbmJzcDsgJm5ic3A7dXBkYXRlIG91ciBtb2RlbCBmb3IgbG9naWNhbCBkZXZpY2Vz IHRvIHVzZSBhIGdyb3VwaW5nIGZyb20gdGhlIG5ldzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg c3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiIGZhY2U9IkNvbnNvbGFzLG1vbm9zcGFjZSI+PHNwYW4g c3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMCk7Ij4mbmJzcDsgJm5ic3A7 bW9kZWwuDQo8L3NwYW4+Jm5ic3A7QW5vdGhlciBwcm9ibGVtIGlzIHRoYXQgdGhpcyBhcHByb2Fj aCBjYW5ub3QgaGFuZGxlIHZlbmRvci08L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEycHg7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09V VExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xh cywgbW9ub3NwYWNlOyBib3JkZXItbGVmdC1jb2xvcjoNCiAgICAgICAgcmdiKDE4MSwgMTk2LCAy MjMpOyBib3JkZXItbGVmdC13aWR0aDogNXB4OyBib3JkZXItbGVmdC1zdHlsZToNCiAgICAgICAg c29saWQ7IHBhZGRpbmc6IDBweCAwcHggMHB4IDVweDsgbWFyZ2luOiAwcHggMHB4IDBweCA1cHg7 Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYm9yZGVyLWxlZnQtY29s b3I6IHJnYigxODEsIDE5NiwgMjIzKTsNCiAgICAgICAgICBib3JkZXItbGVmdC13aWR0aDogNXB4 OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRpbmc6IDBweA0KICAgICAgICAgIDBweCAw cHggNXB4OyBtYXJnaW46IDBweCAwcHggMHB4IDVweDsiPg0KPGRpdj5XZSBoYXZlIGEgY29tbWVu dC9jb25jZXJuL3N1Z2dlc3Rpb24gYW5kIHdlIHZhbHVlIHlvdXIgZmVlZGJhY2suPC9kaXY+DQo8 ZGl2PlRoZSBnZW5lcmljIFRFIG1vZGVsIGN1cnJlbnRseSByZWZlcmVuY2VzIGRhdGEgbm9kZXMg aW4gdGhlIGdsb2JhbDwvZGl2Pg0KPGRpdj50cmVlIChlLmcuIGZyb20gdGhlIGlldGYtaW50ZXJm YWNlcyBtb2RlbCB0byBkZWZpbmUgYWRkaXRpb25hbCBURTwvZGl2Pg0KPGRpdj5wcm9wZXJ0aWVz IGFzc29jaWF0ZWQgd2l0aCBhIHNwZWNpZmljIGRldmljZSBpbnRlcmZhY2UpLiBPdXI8L2Rpdj4N CjxkaXY+dW5kZXJzdGFuZGluZyBhZnRlciByZWFkaW5nIHNlY3Rpb24gMy4xIG9mIHlvdXIgZHJh ZnQgaXMgdGhlIG1vdW50ZWQ8L2Rpdj4NCjxkaXY+bW9kZWwgY2FuICpub3QqIHJlZmVyZW5jZSBh bnkgZGF0YSBub2RlcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGU8L2Rpdj4NCjxkaXY+bW91bnQt cG9pbnQgKGUuZy4gZ2xvYmFsIGRhdGEgbm9kZXMgaW4gdGhlIHlhbmcgdHJlZSkuIFRoaXMgcG9z ZXMgYTwvZGl2Pg0KPGRpdj5saW1pdGF0aW9uIGZvciB1cywgZG8geW91IGhhdmUgYSBzdWdnZXN0 aW9uIGZvciB0aGlzIHByb2JsZW0/PC9kaXY+DQo8ZGl2Pk9uZSBwb3NzaWJsZSBzb2x1dGlvbiB3 ZSB0aG91Z2h0IG9mIHdhcyB0byByZXBsYWNlIHRoZSBsZWFmLXJlZnM8L2Rpdj4NCjxkaXY+cG9p bnRpbmcgdG8gdGhlIGdsb2JhbCBkYXRhIG5vZGVzIChlLmcuIElldGYtaW50ZXJmYWNlcykgd2l0 aCBjb250ZXh0PC9kaXY+DQo8ZGl2Pm5hbWVzIChlLmcuIHRoZSBpbnRlcmZhY2UgbmFtZSkuLiBU aGlzIGRlY291cGxlcyB0aGUgZGF0YS1ub2RlczwvZGl2Pg0KPGRpdj5kZWZpbmVkIGluIHRoZSBU RSBnZW5lcmljIG1vZGVsIGZyb20gdGhvc2UgaW4gdGhlIGdsb2JhbCB0cmVlPC9kaXY+DQo8ZGl2 PihlLmcuIHRoZSBhY3R1YWwgaW50ZXJmYWNlIGlldGYtaW50ZXJmYWNlcyBtb2RlbCkuIEFueSBm ZWVkYmFjayBvbjwvZGl2Pg0KPGRpdj50aGlzIG9yIGJldHRlciBzdWdnZXN0aW9ucz88L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+SWYgeW91IHVzZSBncm91cGluZ3MgaW5z dGVhZCwgeW91IGNhbiBzdGlsbCB1c2UgcHJvcGVyIGxlYWZyZWZzLjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Tm90IGluIGFsbCBjYXNlcyDigJQgYXMgZGVz Y3JpYmVkIGFib3ZlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEycHg7Ij5SZWdhcmRzLDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPlRh cmVrPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29s YXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L3Nw YW4+PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyBib3JkZXItbGVm dC1jb2xvcjoNCiAgICAgICAgcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItbGVmdC13aWR0aDog NXB4OyBib3JkZXItbGVmdC1zdHlsZToNCiAgICAgICAgc29saWQ7IHBhZGRpbmc6IDBweCAwcHgg MHB4IDVweDsgbWFyZ2luOiAwcHggMHB4IDBweCA1cHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij4vbWFydGluPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4 OyI+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYm9yZGVyLWxlZnQtY29sb3I6IHJn YigxODEsIDE5NiwgMjIzKTsNCiAgICAgICAgICBib3JkZXItbGVmdC13aWR0aDogNXB4OyBib3Jk ZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRpbmc6IDBweA0KICAgICAgICAgIDBweCAwcHggNXB4 OyBtYXJnaW46IDBweCAwcHggMHB4IDVweDsiPg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5U YXJlazwvZGl2Pg0KPGRpdj5FeGNlcnB0IGZyb20gZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1v dW50PC9kaXY+DQo8ZGl2PjMuMSZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQt MDEjc2VjdGlvbi0zLjEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5l dG1vZC1zY2hlbWEtbW91bnQtMDEjc2VjdGlvbi0zLjE8L2E+Jmd0Oy48L2Rpdj4NCjxkaXY+QXVn bWVudCBhbmQgVmFsaWRhdGlvbiBpbiBNb3VudGVkIERhdGE8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7QWxsIHBhdGhzIChpbiBsZWFmcmVmcywgaW5zdGFuY2UtaWRlbnRpZmll cnMsIFhQYXRoIGV4cHJlc3Npb25zLCBhbmQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dGFyZ2V0IG5vZGVzIG9mIGF1Z21lbnRzKSBpbiB0aGUgZGF0YSBtb2RlbHMgbW91bnRl ZCBhdCBhIG1vdW50IHBvaW50PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Fy ZSBpbnRlcnByZXRlZCB3aXRoIHRoZSBtb3VudCBwb2ludCBhcyB0aGUgcm9vdCBub2RlLCBhbmQg dGhlPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21vdW50ZWQgZGF0YSBub2Rl cyBhcyBpdHMgY2hpbGRyZW4uJm5ic3A7Jm5ic3A7VGhpcyBtZWFucyB0aGF0IGRhdGEgd2l0aGlu IGE8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bW91bnRlZCBzdWJ0cmVlIGNh biBuZXZlciByZWZlciB0byBkYXRhIG91dHNpZGUgb2YgdGhpcyBzdWJ0cmVlLjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVy Ij48L2ZpZWxkc2V0PiA8YnI+DQo8cHJlIHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJt b3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5l dG1vZEBpZXRmLm9yZzwvYT48YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D5AA9261193D4100AF1581F4BF98654Cciscocom_-- From nobody Mon May 9 20:43:53 2016 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 A0A5C12D111; Mon, 9 May 2016 20:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUPwhzSDCFLz; Mon, 9 May 2016 20:43:49 -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 95B5712D0F6; Mon, 9 May 2016 20:43:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJO31592; Tue, 10 May 2016 03:43:40 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 May 2016 04:43:39 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Mon, 9 May 2016 20:43:37 -0700 From: Linda Dunbar To: "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" Thread-Topic: Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 Thread-Index: AdGqbibMI0ZS5SbaSgSLdPnQFDvHlA== Date: Tue, 10 May 2016 03:43:38 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.242] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E82F0Adfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.573158ED.00FD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2f06b09bbb09ce330343a5ef27a8902f Archived-At: Subject: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 03:43:51 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657E82F0Adfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors: The "acl-base" identity defined in your draft is empty (i.e. only with a de= scription) . Then you define "ipv4-acl" to be "acl-base". So basically you = inherited the comments twice. identity acl-base { description "Base Access Control List type for all Access Control List type identifiers."; } identity ipv4-acl { base acl:acl-base; description "ACL that primarily matches on fields from the IPv4 header (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP destination port). An acl of type ipv4-acl does not contain matches on fields in the ethernet header or the IPv6 header."; } identity ipv6-acl { base acl:acl-base; description "ACL that primarily matches on fields from the IPv6 header (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP destination port). An acl of type ipv6-acl does not contain matches on fields in the ethernet header or the IPv4 header."; } You really don't need to define the "acl-base". What is the impact if defin= ing the "ipv4-acl" and "ipv6-acl" as follows? identity ipv4-acl { description "ACL that primarily matches on fields from the IPv4 header (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP destination port). An acl of type ipv4-acl does not contain matches on fields in the ethernet header or the IPv6 header."; } identity ipv6-acl { description "ACL that primarily matches on fields from the IPv6 header (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP destination port). An acl of type ipv6-acl does not contain matches on fields in the ethernet header or the IPv4 header."; } Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657E82F0Adfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors:

 

The “acl-base” identity defined in your = draft is empty (i.e. only with a description) . Then you define “ipv4= -acl” to be “acl-base”. So basically you inherited the co= mments twice.

 

identity acl-base {

description

"Base Access Control L= ist type for all Access Control List type

identifiers.";

}

identity ipv4-acl {

base acl:acl-base;

description

"ACL that primarily ma= tches on fields from the IPv4 header

(e.g. IPv4 destination addr= ess) and layer 4 headers (e.g. TCP

destination port). An acl o= f type ipv4-acl does not contain

matches on fields in the et= hernet header or the IPv6 header.";

}

identity ipv6-acl {

base acl:acl-base;

description

"ACL that primarily ma= tches on fields from the IPv6 header

(e.g. IPv6 destination addr= ess) and layer 4 headers (e.g. TCP

destination port). An acl o= f type ipv6-acl does not contain

matches on fields in the et= hernet header or the IPv4 header.";

}

 

 

You really don&#= 8217;t need to define the “acl-base”. What is the impact if def= ining the “ipv4-acl” and “ipv6-acl” as follows?

 

identity ipv4-acl {

   description

   "ACL that primarily matche= s on fields from the IPv4 header

   (e.g. IPv4 destination address)= and layer 4 headers (e.g. TCP

   destination port). An acl of ty= pe ipv4-acl does not contain

   matches on fields in the ethern= et header or the IPv6 header.";

}

identity ipv6-acl {

   description

   "ACL that primarily matche= s on fields from the IPv6 header

   (e.g. IPv6 destination address)= and layer 4 headers (e.g. TCP

   destination port). An acl of ty= pe ipv6-acl does not contain

   matches on fields in the ethern= et header or the IPv4 header.";

}

 

 

Thanks, Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F657E82F0Adfweml501mbb_-- From nobody Mon May 9 21:24:23 2016 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 C4D5D12D0C8; Mon, 9 May 2016 21:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPvGH03TsCwP; Mon, 9 May 2016 21:24:19 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2618612B01A; Mon, 9 May 2016 21:24:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DF682ADF; Tue, 10 May 2016 06:24:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id owL6uuhJhNqK; Tue, 10 May 2016 06:24:08 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 10 May 2016 06:24:14 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB3982004E; Tue, 10 May 2016 06:24:13 +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 JLsA012Nb6wR; Tue, 10 May 2016 06:24:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C6AA20047; Tue, 10 May 2016 06:24:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 879CD3ACCED5; Tue, 10 May 2016 06:24:11 +0200 (CEST) Date: Tue, 10 May 2016 06:24:11 +0200 From: Juergen Schoenwaelder To: Linda Dunbar Message-ID: <20160510042411.GA49737@elstar.local> Mail-Followup-To: Linda Dunbar , "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" , "Thomas D. Nadeau" References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 04:24:22 -0000 Linda, the identityref type in YANG can be scoped to a base identity. This allows to restrict an indentityref to a certain set of identities. See 6020 section 7.16.3 and section 9.10.5 for an example. The ACL draft follows the model described in RFC 6020 and defines typedef acl-type { type identityref { base acl-base; } } which restricts acl-type to any identity directly or indirectly derived from acl-base. If you remove acl-base, then acl-type could refer to any identity, which includes identities that have nothing to do with ACLs. /js On Tue, May 10, 2016 at 03:43:38AM +0000, Linda Dunbar wrote: > Dear Authors: > > The "acl-base" identity defined in your draft is empty (i.e. only with a description) . Then you define "ipv4-acl" to be "acl-base". So basically you inherited the comments twice. > > identity acl-base { > description > "Base Access Control List type for all Access Control List type > identifiers."; > } > identity ipv4-acl { > base acl:acl-base; > description > "ACL that primarily matches on fields from the IPv4 header > (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP > destination port). An acl of type ipv4-acl does not contain > matches on fields in the ethernet header or the IPv6 header."; > } > identity ipv6-acl { > base acl:acl-base; > description > "ACL that primarily matches on fields from the IPv6 header > (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP > destination port). An acl of type ipv6-acl does not contain > matches on fields in the ethernet header or the IPv4 header."; > } > > > You really don't need to define the "acl-base". What is the impact if defining the "ipv4-acl" and "ipv6-acl" as follows? > > identity ipv4-acl { > description > "ACL that primarily matches on fields from the IPv4 header > (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP > destination port). An acl of type ipv4-acl does not contain > matches on fields in the ethernet header or the IPv6 header."; > } > identity ipv6-acl { > description > "ACL that primarily matches on fields from the IPv6 header > (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP > destination port). An acl of type ipv6-acl does not contain > matches on fields in the ethernet header or the IPv4 header."; > } > > > Thanks, Linda Dunbar -- 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 May 10 07:17:12 2016 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 AADDB12D6E6 for ; Tue, 10 May 2016 07:17:11 -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 w5HRGecYzovZ for ; Tue, 10 May 2016 07:17:09 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 228C612D6E1 for ; Tue, 10 May 2016 07:17:06 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id 90so6979114qgz.1 for ; Tue, 10 May 2016 07:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=vdnbkq2bM6EVHENgsc0jWa1AVzzuRnPi34OHPxbWZfc=; b=QYvvbTifo4eCXeTz4tDsr3GlHkJfrnF5LwhFOvI/fUPCCXsYNWYxzIjQetK/JK0n1Y tyG+/Ui4LcZh7LzNuVe3eeYUCFxaX/TcQzC/DmvMqTWU795btu8WC4nEIJr+d2IA8l51 kQfVwzwJ5pap1xGOYV47+HVRgFNHyXSA0A5+UaqQzsY0QCIqszF4Q0BYNwLxu94PZz4h 1ZT9CRRD8GGeJeY2/VjJhOglF8/+mr/b0DQSrYPAdrnH8N1T2G3NoKAmM9hOV64J84GK lLzT6Kt6SdcJgtqUgiRqSJL7FDXmpf7/H2AuNOQvFMa4UYb17umMUQA7A4XvHjW13UyL OINg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vdnbkq2bM6EVHENgsc0jWa1AVzzuRnPi34OHPxbWZfc=; b=U6jdjcFOsWK5OrWluxx90R58cwQFc81TbNh0Vt/Mlddol+uCDpK4FKZ6LdYVjJ2TUL MSKU5ny9GH7VGgnWhGMC2JUrE2NKshopuI+Sc+BdOkYh8zYZaO28N3E6Q8AjD3Km/PQw fDj4+nNsDOqXOp32xpS6jL795amfpvF7CBpSbFHSVz6qXvwmNF6A6o4U0S65nidCZCbK wvTT1rp529S+AG4gfaaE+fKnODRYjPVM0HW31qgAONaOREkJZZ7YFnQ2tdllnTj/FNJE S0OeuV6j066llf497dSegpLI5OwBI/doFDxnkUILRcc8KzDUje2HDYcpMhJ+B6IwdTUf L4Vw== X-Gm-Message-State: AOPr4FV0pQQjBVyTyn6yhjqmEnyTEWjbn0znRnY9P1/eyTNUNwaNQ20+AREm7ucuW67nCw== X-Received: by 10.140.42.195 with SMTP id c61mr40859353qga.40.1462889825219; Tue, 10 May 2016 07:17:05 -0700 (PDT) Received: from [10.0.1.3] (c-75-68-179-118.hsd1.ma.comcast.net. [75.68.179.118]) by smtp.gmail.com with ESMTPSA id 125sm970760qki.30.2016.05.10.07.17.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 May 2016 07:17:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_389699A3-8649-48EC-86D2-CF107A8D502D" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E81CA0@dfweml501-mbb> Date: Tue, 10 May 2016 10:17:03 -0400 Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F657E81CA0@dfweml501-mbb> To: Linda Dunbar X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Susan Hares , "netmod@ietf.org" Subject: Re: [netmod] Is there any common module (like library module) for matching all IPv4 or IPv6 header fields? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 14:17:12 -0000 --Apple-Mail=_389699A3-8649-48EC-86D2-CF107A8D502D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Linda, If you need additional fields in ACL, it is easy to extend the existing = base model. The intention of the draft authors was to create base common = model that can be then extended for different uses.=20 Saying that, there is nothing out there that could be used for your = purposes, but using the ACL model, you should be able to augment it for = your use case. Dean > On May 5, 2016, at 11:48 PM, Linda Dunbar = wrote: >=20 > Dear YANG Model experts:=20 > =20 > Draft-ietf-netmod-acl-model-07 has matching criteria for Destination = Address and Source for IPv4 and IPv6 respectively, like: > =20 > > =20 > IDR FlowSpec also has defined YANG model for matching criteria for = IPv6/ IPv4-prefix plus other header fields. I2RS Filter Based RIB also = define various header matching. > =20 > Is there a common library module that can be called when any IP header = fields need to be used as matching criteria? > =20 > Thanks, Linda Dunbar --Apple-Mail=_389699A3-8649-48EC-86D2-CF107A8D502D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Linda,

If = you need additional fields in ACL, it is easy to extend the existing = base model. The intention of the draft authors was to create base common = model that can be then extended for different uses. 

Saying that, there is = nothing out there that could be used for your purposes, but using the = ACL model, you should be able to augment it for your use case.

Dean

On May 5, 2016, at 11:48 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

Dear YANG Model experts: 
 
Draft-ietf-netmod-acl-model-07 has matching criteria for = Destination Address and Source for IPv4 and IPv6 respectively, like:
 
<image001.png>
 
IDR = FlowSpec also has  defined YANG model for matching criteria for = IPv6/ IPv4-prefix plus other header fields. I2RS Filter Based RIB also = define various header matching.
 
Is there a common library module that = can be called when any IP header fields need to be used as matching = criteria?
 
Thanks, Linda Dunbar

= --Apple-Mail=_389699A3-8649-48EC-86D2-CF107A8D502D-- From nobody Tue May 10 08:07:43 2016 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 23DFA12D6F2; Tue, 10 May 2016 08:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGFBvs4DxFoA; Tue, 10 May 2016 08:07:39 -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 0C38012D507; Tue, 10 May 2016 08:07:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJP51588; Tue, 10 May 2016 15:07:34 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 May 2016 16:07:33 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Tue, 10 May 2016 08:07:30 -0700 From: Linda Dunbar To: Juergen Schoenwaelder Thread-Topic: Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 Thread-Index: AdGqbibMI0ZS5SbaSgSLdPnQFDvHlAAQFK2AAAeEnWA= Date: Tue, 10 May 2016 15:07:30 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> In-Reply-To: <20160510042411.GA49737@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5731F938.002F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 70f2c7e289e24ade0f4d93762a84d0eb Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 15:07:42 -0000 Juergen, If "acl-base" has some content more than the comment (i.e. the description)= , then it makes sense. =20 The comments in the "identity ipv4-acl" is enough to describe the identity.= Same with the identity ipv6-acl.=20 I find it is very confusing to have the recursive reference of identity (al= l of them are simply the description).=20 My two cents,=20 Linda=20 =20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, May 09, 2016 11:24 PM To: Linda Dunbar Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas D. Nade= au Subject: Re: Can you remove the "Identity acl-base" defined in draft-ietf-n= etmod-acl-model-07 Linda, the identityref type in YANG can be scoped to a base identity. This allows = to restrict an indentityref to a certain set of identities. See 6020 section 7.16.3 and section 9.10.5 for an example. The ACL draft follows the model described in RFC 6020 and defines typedef acl-type { type identityref { base acl-base; } } which restricts acl-type to any identity directly or indirectly derived fro= m acl-base. If you remove acl-base, then acl-type could refer to any identi= ty, which includes identities that have nothing to do with ACLs. /js On Tue, May 10, 2016 at 03:43:38AM +0000, Linda Dunbar wrote: > Dear Authors: >=20 > The "acl-base" identity defined in your draft is empty (i.e. only with a = description) . Then you define "ipv4-acl" to be "acl-base". So basically yo= u inherited the comments twice. >=20 > identity acl-base { > description > "Base Access Control List type for all Access Control List type=20 > identifiers."; } identity ipv4-acl { base acl:acl-base; description=20 > "ACL that primarily matches on fields from the IPv4 header (e.g. IPv4=20 > destination address) and layer 4 headers (e.g. TCP destination port).=20 > An acl of type ipv4-acl does not contain matches on fields in the=20 > ethernet header or the IPv6 header."; } identity ipv6-acl { base=20 > acl:acl-base; description "ACL that primarily matches on fields from=20 > the IPv6 header (e.g. IPv6 destination address) and layer 4 headers=20 > (e.g. TCP destination port). An acl of type ipv6-acl does not contain=20 > matches on fields in the ethernet header or the IPv4 header."; } >=20 >=20 > You really don't need to define the "acl-base". What is the impact if def= ining the "ipv4-acl" and "ipv6-acl" as follows? >=20 > identity ipv4-acl { > description > "ACL that primarily matches on fields from the IPv4 header > (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP > destination port). An acl of type ipv4-acl does not contain > matches on fields in the ethernet header or the IPv6 header."; }=20 > identity ipv6-acl { > description > "ACL that primarily matches on fields from the IPv6 header > (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP > destination port). An acl of type ipv6-acl does not contain > matches on fields in the ethernet header or the IPv4 header."; } >=20 >=20 > Thanks, Linda Dunbar --=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 Tue May 10 08:37:57 2016 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 CA82F12D70A; Tue, 10 May 2016 08:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjzDROlZvRUX; Tue, 10 May 2016 08:37:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36CC112D6F5; Tue, 10 May 2016 08:37:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AABE68DC; Tue, 10 May 2016 17:37:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id G4uXgPGB02x2; Tue, 10 May 2016 17:37:33 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 10 May 2016 17:37:41 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 061432004E; Tue, 10 May 2016 17:37:41 +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 delXFsEgP_2P; Tue, 10 May 2016 17:37:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 094A220047; Tue, 10 May 2016 17:37:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D95943ACDB4D; Tue, 10 May 2016 17:37:37 +0200 (CEST) Date: Tue, 10 May 2016 17:37:37 +0200 From: Juergen Schoenwaelder To: Linda Dunbar Message-ID: <20160510153737.GA50842@elstar.local> Mail-Followup-To: Linda Dunbar , "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" , "Thomas D. Nadeau" References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 15:37:57 -0000 On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: > Juergen, > > If "acl-base" has some content more than the comment (i.e. the description), then it makes sense. > > The comments in the "identity ipv4-acl" is enough to describe the identity. Same with the identity ipv6-acl. > > I find it is very confusing to have the recursive reference of identity (all of them are simply the description). > I fail to see anything confusing here. Did you read the relevant sections of RFC 6020? What is unclear about identities and how they work? /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 May 10 09:55:52 2016 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 6926312D75F; Tue, 10 May 2016 09:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnuEBLK5x0cm; Tue, 10 May 2016 09:55:48 -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 0F0F712D546; Tue, 10 May 2016 09:55:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJP66682; Tue, 10 May 2016 16:55:45 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 May 2016 17:55:45 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Tue, 10 May 2016 09:55:41 -0700 From: Linda Dunbar To: Juergen Schoenwaelder Thread-Topic: Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 Thread-Index: AdGqbibMI0ZS5SbaSgSLdPnQFDvHlAAQFK2AAAeEnWAAEABZgAAN9jXg Date: Tue, 10 May 2016 16:55:41 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> <20160510153737.GA50842@elstar.local> In-Reply-To: <20160510153737.GA50842@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.57321292.009B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 70f2c7e289e24ade0f4d93762a84d0eb Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 16:55:52 -0000 Juergen,=20 Of course, it is not confusing to you because you are in the box (vs. many = of us are outside the box looking in).=20 RFC 6020 doesn't say all identities have to have a sub-identity.=20 My opinion only.=20 Linda=20 =20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, May 10, 2016 10:38 AM To: Linda Dunbar Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas D. Nade= au Subject: Re: Can you remove the "Identity acl-base" defined in draft-ietf-n= etmod-acl-model-07 On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: > Juergen, >=20 > If "acl-base" has some content more than the comment (i.e. the descriptio= n), then it makes sense. =20 >=20 > The comments in the "identity ipv4-acl" is enough to describe the identit= y. Same with the identity ipv6-acl.=20 >=20 > I find it is very confusing to have the recursive reference of identity (= all of them are simply the description).=20 > I fail to see anything confusing here. Did you read the relevant sections o= f RFC 6020? What is unclear about identities and how they work? /js --=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 Tue May 10 10:06:40 2016 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 20D9512D786; Tue, 10 May 2016 10:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNCysiMlEzwd; Tue, 10 May 2016 10:06:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260FB12D539; Tue, 10 May 2016 10:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PVgeKP8CSkftM1Wqv69TjQVB/lSJP1vVcQYYOt/G4O4=; b=BZyRXvSeQ0Kp43+9kNMHUSgXhT4pmQE3RbvB3/KMxXuBOXsbgdaV45PSkDCw9CSrMbyWLi+4vcUNVK3WoHYPb/z4L0EmU1bkwL9omgeuqZ5+UnGKn69ujsTkRu3FfxmKyyB70+bM55pQ3Uehy3ntzCrATF7mZYlgVHKJeb/LRgw= Received: from CY1PR0501MB1820.namprd05.prod.outlook.com (10.163.141.146) by CY1PR0501MB1819.namprd05.prod.outlook.com (10.163.141.145) with Microsoft SMTP Server (TLS) id 15.1.485.9; Tue, 10 May 2016 17:05:52 +0000 Received: from CY1PR0501MB1820.namprd05.prod.outlook.com ([10.163.141.146]) by CY1PR0501MB1820.namprd05.prod.outlook.com ([10.163.141.146]) with mapi id 15.01.0485.016; Tue, 10 May 2016 17:05:52 +0000 From: "Lisa (Yi) Huang" To: Linda Dunbar , Juergen Schoenwaelder Thread-Topic: Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 Thread-Index: AdGqbibMI0ZS5SbaSgSLdPnQFDvHlAABaZWAABZ3swAAAQ1EgAACufiA//+NfQA= Date: Tue, 10 May 2016 17:05:52 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> <20160510153737.GA50842@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-ms-office365-filtering-correlation-id: 65aefb09-5ec8-4f16-b049-08d378f557b3 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1819; 5:6qkyf3Prckzv+yKqDW2Kf4PTSFV8tZB6oDJtGUXMWnB7tNHuF8qR22eL/s94VG/bV25D01u/p/hpKUfLJI9nFAWd7isVgmpqh0p7sK1+5vfCDhfwuULFFjQEm58bcdC3e81TGGiLryWqHjLQN6e3nA==; 24:mATy6BElA4N4a3TACXBOSALwTe5YiTenTPpDpwZW1RRgize4IDB4g069D1mTGq+yo9NwTTXsM9gd52EwRp/DznM52D/dLdlL92S8phL3oqY=; 7:Xh5HRrnrsSdwrYbbt9qn7zxw71ASnYaboYUihIpIED6iQ6CuBMgTrPgFS69mPQ7YgkW/KIOqJOMZ6KlA5GkwyYTpl4NaB/Uz+p4k5eVZ/27uJX3lC/kLoA7cEdV7BtqM3peT/0g/JRvD9KtHUSQM6esSnnhmaltyvD6SWOAlJ7CiUCqhRYuiy0PGtAcAlwoy x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1819; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR0501MB1819; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1819; x-forefront-prvs: 0938781D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(13464003)(129404003)(3280700002)(66066001)(50986999)(3660700001)(2906002)(86362001)(15975445007)(77096005)(19580395003)(230783001)(4326007)(189998001)(81166006)(83506001)(5004730100002)(5008740100001)(10400500002)(76176999)(54356999)(8936002)(19580405001)(11100500001)(5002640100001)(92566002)(99286002)(122556002)(6116002)(2950100001)(4001350100001)(2900100001)(102836003)(586003)(36756003)(3846002)(1220700001)(93886004)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1819; H:CY1PR0501MB1820.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2016 17:05:52.2617 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1819 Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 17:06:38 -0000 Linda, Could you elaborate what difficulty you are facing? The draft defines typedef acl-type { type identityref { base acl-base; } } This allows the acl-type to be ipv4-acl or ipv6-acl, or other new types that inherit from acl-type. Hope this helps. Thanks, Lisa On 5/10/16, 9:55 AM, "Linda Dunbar" wrote: >Juergen,=20 > >Of course, it is not confusing to you because you are in the box (vs. >many of us are outside the box looking in). > >RFC 6020 doesn't say all identities have to have a sub-identity. > > >My opinion only.=20 > > >Linda=20 >=20 > >-----Original Message----- >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >Sent: Tuesday, May 10, 2016 10:38 AM >To: Linda Dunbar >Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas D. >Nadeau >Subject: Re: Can you remove the "Identity acl-base" defined in >draft-ietf-netmod-acl-model-07 > >On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: >> Juergen, >>=20 >> If "acl-base" has some content more than the comment (i.e. the >>description), then it makes sense. >>=20 >> The comments in the "identity ipv4-acl" is enough to describe the >>identity. Same with the identity ipv6-acl. >>=20 >> I find it is very confusing to have the recursive reference of identity >>(all of them are simply the description). >> > >I fail to see anything confusing here. Did you read the relevant sections >of RFC 6020? What is unclear about identities and how they work? > >/js > >--=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 Tue May 10 10:17:05 2016 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 149FA12D77B for ; Tue, 10 May 2016 10:17:03 -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=unavailable 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 szBgZ6QEAudY for ; Tue, 10 May 2016 10:16:59 -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 22E2312D126 for ; Tue, 10 May 2016 10:16:59 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id m64so22486798lfd.1 for ; Tue, 10 May 2016 10:16:59 -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:date:message-id:subject:from:to :cc; bh=sJdwHVavhzw3KiKTx6Ca1EgsCmVdKCzDTqYCl2rL7M4=; b=VxeqIAEAOO+kV9nOseXGD1AKJmIHG6ubNKFGWbwrZF5hs3v/ocOvdQ3yrLBHLmDd7u vAxqkTb0DcYvnXcVhCj9RIVawBNmp3DYhoSRY8Tq8f15jDR2/kFCsjCPLmW1lfZaYNEL k8s8I0qwrL6NEv2oJWzGI7E12x6GMp64eDh9FVpZxSsv+/xWjVtLIDgBbawEJyIWBPju WPRPsJSrbZvf0qg/uZU522GvsZFBTUnK+EIggFvEyeLiiYDwjp5OrFxv+Qzm3imQFI1S ZPniiqT0oOPrUG7ExZnmZ0bK+K2D4B3TAOpERrSku7IeydkURwvlP2LlXQsUI6gWUpO0 Gt3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sJdwHVavhzw3KiKTx6Ca1EgsCmVdKCzDTqYCl2rL7M4=; b=V6ERy94CZxB8Z/Xpdz8CtvD5M0azygT7sw2Jc7t5pM7ItzsKQHXEDD45hjOYQUEPyk R3LuE2yc7Fv9jVzlHxH9xJUAGP4fiTOdT0TeSB/1HuYO16MtZPD6mLaytC6im+K1J7vu f+cGrmRN92k6jIdcfmiou2tl7qy5MhvXjiMeFHbXU/gH3j45NadGYzTc3NASkW5PhyaA rVBaB5kEHijSEecXcmTujwc+C57dkKv2M4uXcnczJFN2S2INe3E0VCrBFFF7hGYPwl0r EGyVQI/KeSS16YcuscA9g90ADndk68K7nnC0inqUIukOm8+1jtvVkjGGDLc2oBDuerxh ma5w== X-Gm-Message-State: AOPr4FUrkycIkmdoWrPGLWkMNMrgrrQYCYajMVG9qv8fieUEha7a1+c/K5ofhe2hbqQVQHJOGCBoe3TmFLaMiQ== MIME-Version: 1.0 X-Received: by 10.112.184.79 with SMTP id es15mr17159504lbc.30.1462900617297; Tue, 10 May 2016 10:16:57 -0700 (PDT) Received: by 10.112.13.133 with HTTP; Tue, 10 May 2016 10:16:57 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> <20160510153737.GA50842@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> Date: Tue, 10 May 2016 10:16:57 -0700 Message-ID: From: Andy Bierman To: Linda Dunbar Content-Type: multipart/alternative; boundary=001a1133ac90a2dde5053280177e Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 17:17:03 -0000 --001a1133ac90a2dde5053280177e Content-Type: text/plain; charset=UTF-8 On Tue, May 10, 2016 at 9:55 AM, Linda Dunbar wrote: > Juergen, > > Of course, it is not confusing to you because you are in the box (vs. many > of us are outside the box looking in). > > RFC 6020 doesn't say all identities have to have a sub-identity. > > > This is how YANG does strong typing for identities. It allows the compiler to check the identity being used for a given identityref leaf. Otherwise the identities meant for completely different purposes could not be screened by the compiler leaf transport { type identityref { base transport-protocol; } } leaf toast-type { type identityref { base bread-type; } } > My opinion only. > > > Linda > > > Andy > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, May 10, 2016 10:38 AM > To: Linda Dunbar > Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas D. > Nadeau > Subject: Re: Can you remove the "Identity acl-base" defined in > draft-ietf-netmod-acl-model-07 > > On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: > > Juergen, > > > > If "acl-base" has some content more than the comment (i.e. the > description), then it makes sense. > > > > The comments in the "identity ipv4-acl" is enough to describe the > identity. Same with the identity ipv6-acl. > > > > I find it is very confusing to have the recursive reference of identity > (all of them are simply the description). > > > > I fail to see anything confusing here. Did you read the relevant sections > of RFC 6020? What is unclear about identities and how they work? > > /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 > --001a1133ac90a2dde5053280177e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 10, 2016 at 9:55 AM, Linda Dunbar <linda.dunbar@huaw= ei.com> wrote:
Juergen,

Of course, it is not confusing to you because you are in the box (vs. many = of us are outside the box looking in).

RFC 6020 doesn't say all identities have to have a sub-identity.




This is how YANG does s= trong typing for identities.
It allows the compiler to check the = identity being used for a given
identityref leaf. =C2=A0 Othe= rwise the identities meant for completely different
purposes coul= d not be screened by the compiler

=C2=A0 =C2=A0 = =C2=A0leaf transport {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type identityr= ef {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base transport-prot= ocol;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0= =C2=A0 }

=C2=A0 =C2=A0 =C2=A0leaf toast-type= {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type identityref {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base bread-type;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 }
=
=C2=A0
My opinion only.


Linda




Andy
=C2=A0
-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Tuesday, May 10, 2016 10:38 AM
To: Linda Dunbar
Cc: draft-ietf-netm= od-acl-model@ietf.org; 'netmod@i= etf.org'; Thomas D. Nadeau
Subject: Re: Can you remove the "Identity acl-base" defined in dr= aft-ietf-netmod-acl-model-07

On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote:
> Juergen,
>
> If "acl-base" has some content more than the comment (i.e. t= he description), then it makes sense.
>
> The comments in the "identity ipv4-acl" is enough to describ= e the identity. Same with the identity ipv6-acl.
>
> I find it is very confusing to have the recursive reference of identit= y (all of them are simply the description).
>

I fail to see anything confusing here. Did you read the relevant sections o= f RFC 6020? What is unclear about identities and how they work?

/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

--001a1133ac90a2dde5053280177e-- From nobody Tue May 10 10:27:22 2016 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 4969B12D539; Tue, 10 May 2016 10:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBh0Sb3cMhC4; Tue, 10 May 2016 10:27:19 -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 2826912D1E9; Tue, 10 May 2016 10:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1971; q=dns/txt; s=iport; t=1462901239; x=1464110839; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=O8JnzI8hrA3ZUlurDhiTwozIsoQtCCwZxaOxNRFAhSI=; b=dwaFnsK2d8z9dzypUX0ACUwpDfU11zoWmtPKzxGB5u2r7geS13rYxf8e lBKGiclhkh2dtGYqfaYgCIc3TdP8Cqfj2FaB4fXCqk38x3aqPLUrpVQF0 odi4lf7+ULl7nzs+iqY0fAnEHuxRg9IPbjoz7IkdfjV7Awu5jMyPnguru 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBAB6GTJX/xbLJq1UCYQ4Urs5hhACg?= =?us-ascii?q?gIBAQEBAQFmJ4RBAQEBBDhBDAQLEAEEAQEBJwdGCQgGDQYCAQGIJ7kmAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEWhiCBdoJWhBiGAAEEmCeOHoFph1YjhTePQGKCBRsWg?= =?us-ascii?q?TY7MokKAQEB?= X-IronPort-AV: E=Sophos;i="5.24,605,1454976000"; d="scan'208";a="635580356" 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; 10 May 2016 17:27:07 +0000 Received: from [10.63.23.117] (dhcp-ensft1-uk-vla370-10-63-23-117.cisco.com [10.63.23.117]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4AHR6cL022234; Tue, 10 May 2016 17:27:06 GMT To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> <20160510153737.GA50842@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> From: Robert Wilton Message-ID: Date: Tue, 10 May 2016 18:27:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 17:27:21 -0000 Hi Linda, I think that having the base identity makes the model safer and more extensible in future. I think that the general idea of a base identity is fairly standard and is perhaps a bit like defining an abstract base class in an OO language. So, in YANG, rather than a when statement having to explicitly check for ipv4-acl or ipv6-acl it can just check for any type derived from acl-base, which allows for new types of ACL to be defined in future (potentially in different modules). Conversely, it also helps prevent someone from using a completely inappropriate identity, e.g. say trying to use an interface type identity such as ift:ethernetCsmacd where a type of ACL identity is required. Thanks, Rob On 10/05/2016 17:55, Linda Dunbar wrote: > Juergen, > > Of course, it is not confusing to you because you are in the box (vs. many of us are outside the box looking in). > > RFC 6020 doesn't say all identities have to have a sub-identity. > > > My opinion only. > > > Linda > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, May 10, 2016 10:38 AM > To: Linda Dunbar > Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas D. Nadeau > Subject: Re: Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 > > On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: >> Juergen, >> >> If "acl-base" has some content more than the comment (i.e. the description), then it makes sense. >> >> The comments in the "identity ipv4-acl" is enough to describe the identity. Same with the identity ipv6-acl. >> >> I find it is very confusing to have the recursive reference of identity (all of them are simply the description). >> > I fail to see anything confusing here. Did you read the relevant sections of RFC 6020? What is unclear about identities and how they work? > > /js > From nobody Tue May 10 10:27:46 2016 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 BC7ED12D1E9; Tue, 10 May 2016 10:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7KeD7v-dMRI; Tue, 10 May 2016 10:27:42 -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 B2F4312D79A; Tue, 10 May 2016 10:27:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COJ90834; Tue, 10 May 2016 17:27:28 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 May 2016 18:27:27 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Tue, 10 May 2016 10:27:24 -0700 From: Linda Dunbar To: "Lisa (Yi) Huang" , Juergen Schoenwaelder Thread-Topic: Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 Thread-Index: AdGqbibMI0ZS5SbaSgSLdPnQFDvHlAAQFK2AAAeEnWAAEABZgAAN9jXg//+o9gCAAHGtsA== Date: Tue, 10 May 2016 17:27:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E83419@dfweml501-mbb> References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> <20160510153737.GA50842@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.57321A01.01FD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3ef598fc56b86aee432401c2d1bc7013 Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 17:27:45 -0000 Lisa,=20 My difficulty was not being able to see the value of one comment based on a= nother comment.=20 Now I understand it is really just personal preference. Having an extra ste= p doesn't hurt the bottom line end result. It is Ok.=20 Linda -----Original Message----- From: Lisa (Yi) Huang [mailto:lyihuang@juniper.net]=20 Sent: Tuesday, May 10, 2016 12:06 PM To: Linda Dunbar; Juergen Schoenwaelder Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas D. Nade= au Subject: Re: Can you remove the "Identity acl-base" defined in draft-ietf-n= etmod-acl-model-07 Linda, Could you elaborate what difficulty you are facing? The draft defines typedef acl-type { type identityref { base acl-base; } } This allows the acl-type to be ipv4-acl or ipv6-acl, or other new types tha= t inherit from acl-type. Hope this helps. Thanks, Lisa On 5/10/16, 9:55 AM, "Linda Dunbar" wrote: >Juergen, > >Of course, it is not confusing to you because you are in the box (vs. >many of us are outside the box looking in). > >RFC 6020 doesn't say all identities have to have a sub-identity. > > >My opinion only.=20 > > >Linda >=20 > >-----Original Message----- >From: Juergen Schoenwaelder=20 >[mailto:j.schoenwaelder@jacobs-university.de] >Sent: Tuesday, May 10, 2016 10:38 AM >To: Linda Dunbar >Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas D. >Nadeau >Subject: Re: Can you remove the "Identity acl-base" defined in >draft-ietf-netmod-acl-model-07 > >On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: >> Juergen, >>=20 >> If "acl-base" has some content more than the comment (i.e. the=20 >>description), then it makes sense. >>=20 >> The comments in the "identity ipv4-acl" is enough to describe the=20 >>identity. Same with the identity ipv6-acl. >>=20 >> I find it is very confusing to have the recursive reference of=20 >>identity (all of them are simply the description). >> > >I fail to see anything confusing here. Did you read the relevant=20 >sections of RFC 6020? What is unclear about identities and how they work? > >/js > >--=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 Tue May 10 11:17:40 2016 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 9FFCC12D7D7; Tue, 10 May 2016 11:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, 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=lucidvision.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 4VaVQV61OUWH; Tue, 10 May 2016 11:17:36 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 C8D1312D7D5; Tue, 10 May 2016 11:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1462904211; bh=acy7NOnrswapMz2vBeXxhbW2Ov60H0ABHKfg3tMbSQI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=C49Ah2BoaJer2otp7AbvOJqsKTEC7Sg/TEAG5zSPOqlFIaSnY/ODSNm5aWSUsJjBJ bdi3IrvSYS3Z+NsJOYZZ+iaLW+2S5OVzp5PVW95gxzSQwbYi/EtRQ7zboTdbFF5TlR XaObHioRWGZoXaZnf96ytm4xo/pTpP+X8vIPKaIU= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Nadeau Thomas In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> Date: Tue, 10 May 2016 14:17:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0FDE92DF-52ED-4B48-ACBA-8BDC4BBE0024@lucidvision.com> References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> <20160510153737.GA50842@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> To: Linda Dunbar X-Mailer: Apple Mail (2.3124) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=11 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 361, in=3691, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 18:17:38 -0000 Yea, I agree that its probably worth giving a little more = latitude when helping people with models. 8) =E2=80=94Tom > On May 10, 2016:12:55 PM, at 12:55 PM, Linda Dunbar = wrote: >=20 > Juergen,=20 >=20 > Of course, it is not confusing to you because you are in the box (vs. = many of us are outside the box looking in).=20 >=20 > RFC 6020 doesn't say all identities have to have a sub-identity.=20 >=20 >=20 > My opinion only.=20 >=20 >=20 > Linda=20 >=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Tuesday, May 10, 2016 10:38 AM > To: Linda Dunbar > Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas D. = Nadeau > Subject: Re: Can you remove the "Identity acl-base" defined in = draft-ietf-netmod-acl-model-07 >=20 > On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: >> Juergen, >>=20 >> If "acl-base" has some content more than the comment (i.e. the = description), then it makes sense. =20 >>=20 >> The comments in the "identity ipv4-acl" is enough to describe the = identity. Same with the identity ipv6-acl.=20 >>=20 >> I find it is very confusing to have the recursive reference of = identity (all of them are simply the description).=20 >>=20 >=20 > I fail to see anything confusing here. Did you read the relevant = sections of RFC 6020? What is unclear about identities and how they = work? >=20 > /js >=20 > --=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 Tue May 10 11:58:28 2016 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 5732812D838; Tue, 10 May 2016 11:58:27 -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 Rdy6LNcU-1P7; Tue, 10 May 2016 11:58:25 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 489B112D844; Tue, 10 May 2016 11:58:23 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id 90so11916749qgz.1; Tue, 10 May 2016 11:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y9wrM8TYCUQdZ1trLlMQ0Aj5aAmd+E9g7WF1qXh7ngI=; b=cUEP/rkmrAZWhBd8bNeNLSwGUyTTgdpkWu//NWqdbVe1ufbzuf2CK2H9SWLNh+wZz3 s/8gZgO/HHyFYffeiKh9Zj4xyrsKEujpEcYquvLyliOe5tm2lsXdRSJJJGHVQLDNjmwu yPPdg6ljn7FI5/g2Zx8a+60PiWLwsJVb1unU9cB8B1tLvKX1jXP0LBkDDZg42q8QtNcd 2nNP2LNoRHetNeedIqfhOLQQ/GEHAS1d4Hd7ULj/k2awbwrlFsrtT0a/PZh6XizY9BDb oD8l+NqTgLd4OTwwgAaft0oLQ28chnjVBBcEd9ONg7Q3LB1ie1It1MQHQavFGckNVcaE 3wpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y9wrM8TYCUQdZ1trLlMQ0Aj5aAmd+E9g7WF1qXh7ngI=; b=S0nxrerZySKlzgMEfuGp3GEzqJIIPeXrg2L2i0l5x1dHGz8op/Yzxmd36NzzVcwqlp EJmh9ABFl6nnC5x59iM84SUoQFLc6kYd5zkGG+aZqaafIQY3IFtRL1+xNhQPVhfGJbKn /9p/ZVmO8km9G9sgPlIVEFqiE7DQzlt+7s6pUvSHo/1lsT6exp4/3ufpATtevewBM6jh GLdc3GHsU40xqBpnu/byhGlpd+xTx0KBESZOT6xtcTr1zVHAUp28cC+K8O6nqYaRynOL 3ml54ETGhLF0w52Xov2CIDSoXSUJh8xccxJavrG+mpZw4JpvDSRzPCAAtcFyPlfLwj+/ K2rQ== X-Gm-Message-State: AOPr4FXZRNqunelkowiV62157dLNzesfy5HNp6UdG4pipcPhFpNIfshLtaDGxMpLgjSYOA== X-Received: by 10.140.216.16 with SMTP id m16mr43585483qhb.37.1462906702450; Tue, 10 May 2016 11:58:22 -0700 (PDT) Received: from [10.0.1.3] (c-75-68-179-118.hsd1.ma.comcast.net. [75.68.179.118]) by smtp.gmail.com with ESMTPSA id a207sm1565049qkb.28.2016.05.10.11.58.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 May 2016 11:58:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: <0FDE92DF-52ED-4B48-ACBA-8BDC4BBE0024@lucidvision.com> Date: Tue, 10 May 2016 14:58:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02377BE8-A572-4431-9A4F-6B5E09CCBA56@gmail.com> References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> <20160510153737.GA50842@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> <0FDE92DF-52ED-4B48-ACBA-8BDC4BBE0024@lucidvision.com> To: Nadeau Thomas X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 18:58:27 -0000 Tom, It is how YANG does strong typing for identities. Please see Andy=E2=80=99= s email Dean > On May 10, 2016, at 2:17 PM, Nadeau Thomas = wrote: >=20 >=20 > Yea, I agree that its probably worth giving a little more = latitude when helping people with models. 8) >=20 > =E2=80=94Tom >=20 >=20 >> On May 10, 2016:12:55 PM, at 12:55 PM, Linda Dunbar = wrote: >>=20 >> Juergen,=20 >>=20 >> Of course, it is not confusing to you because you are in the box (vs. = many of us are outside the box looking in).=20 >>=20 >> RFC 6020 doesn't say all identities have to have a sub-identity.=20 >>=20 >>=20 >> My opinion only.=20 >>=20 >>=20 >> Linda=20 >>=20 >>=20 >> -----Original Message----- >> From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 >> Sent: Tuesday, May 10, 2016 10:38 AM >> To: Linda Dunbar >> Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas = D. Nadeau >> Subject: Re: Can you remove the "Identity acl-base" defined in = draft-ietf-netmod-acl-model-07 >>=20 >> On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: >>> Juergen, >>>=20 >>> If "acl-base" has some content more than the comment (i.e. the = description), then it makes sense. =20 >>>=20 >>> The comments in the "identity ipv4-acl" is enough to describe the = identity. Same with the identity ipv6-acl.=20 >>>=20 >>> I find it is very confusing to have the recursive reference of = identity (all of them are simply the description).=20 >>>=20 >>=20 >> I fail to see anything confusing here. Did you read the relevant = sections of RFC 6020? What is unclear about identities and how they = work? >>=20 >> /js >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >=20 From nobody Tue May 10 12:31:17 2016 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 E0B1E12D883; Tue, 10 May 2016 12:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, 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=lucidvision.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 tJIqaNKwhbpI; Tue, 10 May 2016 12:31:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 0F69412D514; Tue, 10 May 2016 12:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1462908630; bh=ykOTncKvNrwIDRgrSdA3xG+98mXbZkgT7hOizEMloOM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=JkfyrfJp6Bkzu8A2Lrs6fjjXoSnD3fH9x/LSX6FM21OaC2W+0u9fuZpFRZkcjThzE IFg6KpvOojY8L2Flqytj4t0m1sAED34NgiMQSSXrnWu2MqoX9Ngx2i7vmh/ZRle7el grAcpkCGXExGH9WOhcq0alN5gVys/MeNiRaPo7VI= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Nadeau Thomas In-Reply-To: <02377BE8-A572-4431-9A4F-6B5E09CCBA56@gmail.com> Date: Tue, 10 May 2016 15:31:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2BFC9E4D-F0D4-4A1A-AD3A-86707C064B92@lucidvision.com> References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> <20160510153737.GA50842@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> <0FDE92DF-52ED-4B48-ACBA-8BDC4BBE0024@lucidvision.com> <02377BE8-A572-4431-9A4F-6B5E09CCBA56@gmail.com> To: Dean Bogdanovic X-Mailer: Apple Mail (2.3124) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=19 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 361, in=3699, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 19:31:15 -0000 I understand. I was just pointing out that we might want to be a = little more collegial with people seeking help with models.=20 =E2=80=94Tom > On May 10, 2016:2:58 PM, at 2:58 PM, Dean Bogdanovic = wrote: >=20 > Tom, >=20 > It is how YANG does strong typing for identities. Please see Andy=E2=80= =99s email >=20 > Dean >=20 >> On May 10, 2016, at 2:17 PM, Nadeau Thomas = wrote: >>=20 >>=20 >> Yea, I agree that its probably worth giving a little more = latitude when helping people with models. 8) >>=20 >> =E2=80=94Tom >>=20 >>=20 >>> On May 10, 2016:12:55 PM, at 12:55 PM, Linda Dunbar = wrote: >>>=20 >>> Juergen,=20 >>>=20 >>> Of course, it is not confusing to you because you are in the box = (vs. many of us are outside the box looking in).=20 >>>=20 >>> RFC 6020 doesn't say all identities have to have a sub-identity.=20 >>>=20 >>>=20 >>> My opinion only.=20 >>>=20 >>>=20 >>> Linda=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 >>> Sent: Tuesday, May 10, 2016 10:38 AM >>> To: Linda Dunbar >>> Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas = D. Nadeau >>> Subject: Re: Can you remove the "Identity acl-base" defined in = draft-ietf-netmod-acl-model-07 >>>=20 >>> On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: >>>> Juergen, >>>>=20 >>>> If "acl-base" has some content more than the comment (i.e. the = description), then it makes sense. =20 >>>>=20 >>>> The comments in the "identity ipv4-acl" is enough to describe the = identity. Same with the identity ipv6-acl.=20 >>>>=20 >>>> I find it is very confusing to have the recursive reference of = identity (all of them are simply the description).=20 >>>>=20 >>>=20 >>> I fail to see anything confusing here. Did you read the relevant = sections of RFC 6020? What is unclear about identities and how they = work? >>>=20 >>> /js >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>=20 >=20 From nobody Tue May 10 14:14:32 2016 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 7895412D628; Tue, 10 May 2016 14:14:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160510211427.390.80951.idtracker@ietfa.amsl.com> Date: Tue, 10 May 2016 14:14:27 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 21:14:27 -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 : SYSLOG YANG Model Authors : Clyde Wildes Kiran Koushik Filename : draft-ietf-netmod-syslog-model-08.txt Pages : 35 Date : 2016-05-10 Abstract: This document describes a data model for the Syslog protocol which is used to convey event notification messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-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 May 10 14:22:54 2016 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 BDB7212B020 for ; Tue, 10 May 2016 14:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgOfqO0QEtGf for ; Tue, 10 May 2016 14:22:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB28A12D60B for ; Tue, 10 May 2016 14:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4484; q=dns/txt; s=iport; t=1462915370; x=1464124970; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1bHE9PiU0YfOFkuPgx83t5ZPLLHGXULFw6DUuwW28Jg=; b=GIzKry3D2+IY6HNhyAjVBOCiEt7R/zC0VW2J+yiGLXXOtv0TAQsZudHq HitQaN30aKDG5e3yqMVaUUsroBEdkg8m4ZVCn4NfC7DU2Ax1h2tsOVf9c uV9qG5rW8K3VAPTLLxKECksfZ6vIehGM1LCBlCBMv9TbLwTSAMdbNZfe+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgCKUDJX/5BdJa1dgzhVfQa5LwENg?= =?us-ascii?q?XYXC4UkSgIcgR04FAEBAQEBAQFlHAuEQgEBBAEBASAROhsCAQgaAiYCAgIlCxU?= =?us-ascii?q?QAgQTiCoBDqhUkGYBAQEBAQEBAQEBAQEBAQEBAQEBAQEVfIUkgXaCVoQcDYMWK?= =?us-ascii?q?4IuBY1fikgBhX2IIIFpToQBiGGGLYkSAR4BAUKDa26HTT4BfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,606,1454976000"; d="scan'208";a="105759989" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2016 21:22:49 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u4ALMn59010523 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 May 2016 21:22:49 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 10 May 2016 16:22:48 -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.1104.009; Tue, 10 May 2016 16:22:48 -0500 From: "Clyde Wildes (cwildes)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt Thread-Index: AQHRqwEIoPXkjp2l/k2OqqhnpwdmNZ+yjKoA Date: Tue, 10 May 2016 21:22:48 +0000 Message-ID: <3BC3991A-615F-47CE-A567-721C8272404E@cisco.com> References: <20160510211427.390.80951.idtracker@ietfa.amsl.com> In-Reply-To: <20160510211427.390.80951.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.69.106.41] Content-Type: text/plain; charset="utf-8" Content-ID: <03F6B1263B56F94296EC3DA570849832@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 21:22:53 -0000 SGksDQoNClRoaXMgdXBkYXRlIHRvIHRoZSBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwt MDggaW5jb3Jwb3JhdGVzIHRoZSBjaGFuZ2VzIGxpc3RlZCBiZWxvdyBiYXNlZCBvbiBmZWVkYmFj ayByZWNlaXZlZC4NCg0KQW4gYWRkaXRpb25hbCByZXZpc2lvbiB0byB0aGlzIGRyYWZ0IHdpbGwg YmUgbmVjZXNzYXJ5IHRvIGZpbmFsaXplIFRMUyBjb25maWd1cmF0aW9uIGxlYXZlcyBvbmNlIHRo ZSBpZXRmLXRscy1jbGllbnQtc2VydmVyLW1vZGVsIHRoYXQgdGhlIE5FVENPTkYgV0cgcGxhbnMg dG8gc3BpbiBvdXQgb2YgdGhlIG5ldGNvbmYtc2VydmVyLW1vZGVsIGRyYWZ0IGlzIGF2YWlsYWJs ZS4NCg0KQ2hhbmdlcyBmcm9tIGZlZWRiYWNrIGZyb20gTWFoZXNoIEo6DQotIGFkZGVkIHN1cHBv cnQgZm9yIGNvbmZpZ3VyaW5nIGEgc3lzbG9nIHNlcnZlcg0KDQpDaGFuZ2VzIGZyb20gZmVlZGJh Y2sgZnJvbSBUb20gUC46DQotIHJlbW92ZWQgZm91ciBmZWF0dXJlcyBmb3IgbG9nIGFjdGlvbiBs ZWF2ZXMgY29uc29sZSwgYnVmZmVyLCB0ZXJtaW5hbCBhbmQgc2Vzc2lvbiBzaW5jZSB0aGV5IGFy ZSBpbXBsZW1lbnRlZCBieSBtdWx0aXBsZSB2ZW5kb3JzLiBMYWNrIG9mIHN1cHBvcnQgZm9yIHRo ZXNlIGFjdGlvbnMgY2FuIGJlIGluZGljYXRlZCB1c2luZyBhIGRldmlhdGlvbi4NCi0gcmVtb3Zl ZCBmZWF0dXJlIGJ1ZmZlci1saW1pdC1tZXNzYWdlcyBzaW5jZSBpbXBsZW1lbnRhdGlvbiBieSBh bnkgdmVuZG9yIGlzIHVua25vd24NCi0gcmVuYW1lZCBmZWF0dXJlIHRlcm1pbmFsLWZhY2lsaXR5 LXVzZXItbG9nZ2luZy1jb25maWcgdG8gdGVybWluYWwtZmFjaWxpdHktZGV2aWNlLWxvZ2dpbmcg dG8gc2hvcnRlbiB0aGUgbmFtZSBhbmQgdG8gY2xhcmlmeQ0KLSByZW5hbWVkIGZlYXR1cmUgc2Vz c2lvbi1mYWNpbGl0eS11c2VyLWxvZ2dpbmctY29uZmlnIHRvIHNlc3Npb24tZmFjaWxpdHktdXNl ci1sb2dnaW5nIHRvIHNob3J0ZW4gdGhlIG5hbWUNCi0gcmVuYW1lZCBmZWF0dXJlIHNlbGVjdG9y LXNldm9wLWNvbmZpZyB0byBmZWF0dXJlIHNlbGVjdC1zZXYtY29tcGFyZSB0byBzaG9ydGVuIHRo ZSBuYW1lDQotIHJlbmFtZWQgZmVhdHVyZSBzZWxlY3Rvci1tYXRjaC1jb25maWcgdG8gZmVhdHVy ZSBzZWxlY3QtbWF0Y2ggdG8gc2hvcnRlbiB0aGUgbmFtZQ0KLSByZW5hbWVkIGZlYXR1cmUgc3Ry dWN0dXJlZC1kYXRhLWNvbmZpZyB0byBmZWF0dXJlIHN0cnVjdHVyZWQtZGF0YSB0byBzaG9ydGVu IHRoZSBuYW1lDQotIHJlbmFtZWQgZmVhdHVyZSBzaWduZWQtbWVzc2FnZXMtY29uZmlnIHRvIGZl YXR1cmUgc2lnbmVkLW1lc3NhZ2VzIHRvIHNob3J0ZW4gdGhlIG5hbWUNCi0gcmVtb3ZlZCB0aGUg bG9nLWJ1ZmZlciBsaXN0IGFuZCBuYW1lIGZyb20gbG9nLWFjdGlvbiBidWZmZXIgc2luY2UgaW1w bGVtZW50YXRpb24gYnkgYW55IHZlbmRvciBpcyB1bmtub3duDQotIHJlbW92ZWQgdGhlIHdvcmQg ZHJhZnQgZnJvbSBzZWN0aW9uIDENCi0gdXBkYXRlZCB0aGUgY29weXJpZ2h0IGRhdGVzIGFuZCB0 aGUgcmV2aXNpb24gZGF0ZXMgaW4gdGhlIG1vZGVscw0KLSBtb3ZlZCB0aGUgZXhhbXBsZSB0byBh biBBcHBlbmRpeA0KLSByZW1vdmVkIGUtbWFpbCBhZGRyZXNzZXMgZnJvbSB0aGUgYWNrbm93bGVk Z2VtZW50IHNlY3Rpb24NCg0KQ2hhbmdlcyBmcm9tIGZlZWRiYWNrIGZyb20gQmVub2l0Og0KLSBy ZW5hbWUgbW9kdWxlIHZlbmRvci1zeXNsb2ctdHlwZXMgdG8gbW9kdWxlIHZlbmRvci1zeXNsb2ct dHlwZXMtZXhhbXBsZQ0KDQoNClRoYW5rcywNCg0KS2lyYW4gYW5kIENseWRlDQoNCg0KDQoNCk9u IDUvMTAvMTYsIDI6MTQgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPlRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5FVENPTkYgRGF0YSBNb2RlbGluZyBMYW5n dWFnZSBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFNZU0xPRyBZ QU5HIE1vZGVsDQo+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBDbHlkZSBXaWxkZXMNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgIEtpcmFuIEtvdXNoaWsNCj4JRmlsZW5hbWUgICAgICAgIDog ZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTA4LnR4dA0KPglQYWdlcyAgICAgICAgICAg OiAzNQ0KPglEYXRlICAgICAgICAgICAgOiAyMDE2LTA1LTEwDQo+DQo+QWJzdHJhY3Q6DQo+ICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBkYXRhIG1vZGVsIGZvciB0aGUgU3lzbG9nIHByb3Rv Y29sIHdoaWNoIGlzDQo+ICAgdXNlZCB0byBjb252ZXkgZXZlbnQgbm90aWZpY2F0aW9uIG1lc3Nh Z2VzLg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0 bW9kLXN5c2xvZy1tb2RlbC8NCj4NCj5UaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2 YWlsYWJsZSBhdDoNCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRt b2Qtc3lzbG9nLW1vZGVsLTA4DQo+DQo+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMDgNCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u DQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5l dG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Wed May 11 01:19:49 2016 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 057B412D1CE; Wed, 11 May 2016 01:19: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, 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 QwZnljZuKJQi; Wed, 11 May 2016 01:19:46 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (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 0CF0A12D1C8; Wed, 11 May 2016 01:19:46 -0700 (PDT) Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u4B8Getn017898; Wed, 11 May 2016 01:19:27 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 22ue5kv27m-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 May 2016 01:19:27 -0700 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 02:19:24 -0600 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 10:19:23 +0200 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Wed, 11 May 2016 10:19:22 +0200 From: William Ivory To: Robert Wilton , Linda Dunbar Thread-Topic: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 Thread-Index: AdGqbibMI0ZS5SbaSgSLdPnQFDvHlP//6cWAgACzvgCAAAhqgIAAFdCAgAAIwgD//uYToA== Date: Wed, 11 May 2016 08:19:01 +0000 Deferred-Delivery: Wed, 11 May 2016 08:19:00 +0000 Message-ID: <998bc143d376428085e77696381cc097@EMEAWP-EXMB12.corp.brocade.com> References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> <20160510153737.GA50842@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.212.174] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-11_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1605110109 Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 08:19:48 -0000 Hi Rob, Probably a stupid question but how would you write a 'when' statement that checks identity type? What XPATH function / expression would allow you to access the YANG type? Thanks, William -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton Sent: 10 May 2016 18:27 To: Linda Dunbar Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org' Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 Hi Linda, I think that having the base identity makes the model safer and more extensible in future. I think that the general idea of a base identity is fairly standard and is perhaps a bit like defining an abstract base class in an OO language. So, in YANG, rather than a when statement having to explicitly check for ipv4-acl or ipv6-acl it can just check for any type derived from acl-base, which allows for new types of ACL to be defined in future (potentially in different modules). Conversely, it also helps prevent someone from using a completely inappropriate identity, e.g. say trying to use an interface type identity such as ift:ethernetCsmacd where a type of ACL identity is required. Thanks, Rob On 10/05/2016 17:55, Linda Dunbar wrote: > Juergen, > > Of course, it is not confusing to you because you are in the box (vs. many of us are outside the box looking in). > > RFC 6020 doesn't say all identities have to have a sub-identity. > > > My opinion only. > > > Linda > > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, May 10, 2016 10:38 AM > To: Linda Dunbar > Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas D. > Nadeau > Subject: Re: Can you remove the "Identity acl-base" defined in > draft-ietf-netmod-acl-model-07 > > On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: >> Juergen, >> >> If "acl-base" has some content more than the comment (i.e. the description), then it makes sense. >> >> The comments in the "identity ipv4-acl" is enough to describe the identity. Same with the identity ipv6-acl. >> >> I find it is very confusing to have the recursive reference of identity (all of them are simply the description). >> > I fail to see anything confusing here. Did you read the relevant sections of RFC 6020? What is unclear about identities and how they work? > > /js > _______________________________________________ netmod mailing list netmod@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=MlQZEKdXoP4IwlPcElVo_hIsmcgPxkS1AvAc3uGRU_E&s=iht1ryWsM95ONkVXCHgLCn-rGgsZVjmO0P_Hnhg2llM&e= From nobody Wed May 11 01:28:20 2016 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 DA5FB12D59D; Wed, 11 May 2016 01:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1tvE6nWHJ2A; Wed, 11 May 2016 01:28:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6321512D1C8; Wed, 11 May 2016 01:28:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D0EFD1169; Wed, 11 May 2016 10:28:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id IU6bCG6VBn8k; Wed, 11 May 2016 10:28:02 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 11 May 2016 10:28:13 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF8192004E; Wed, 11 May 2016 10:28:13 +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 0dLiDiho1o33; Wed, 11 May 2016 10:28:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41EB920047; Wed, 11 May 2016 10:28:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 092103ACEAE6; Wed, 11 May 2016 10:28:10 +0200 (CEST) Date: Wed, 11 May 2016 10:28:10 +0200 From: Juergen Schoenwaelder To: William Ivory Message-ID: <20160511082810.GA52653@elstar.local> Mail-Followup-To: William Ivory , Robert Wilton , Linda Dunbar , "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> <20160510153737.GA50842@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> <998bc143d376428085e77696381cc097@EMEAWP-EXMB12.corp.brocade.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <998bc143d376428085e77696381cc097@EMEAWP-EXMB12.corp.brocade.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 08:28:20 -0000 YANG 1.1 introduces special functions for identities such as derived-from() or derived-from-or-self(), for more details see section 10.4 of draft-ietf-netmod-rfc6020bis-12. /js On Wed, May 11, 2016 at 08:19:01AM +0000, William Ivory wrote: > Hi Rob, > > Probably a stupid question but how would you write a 'when' statement that checks identity type? What XPATH function / expression would allow you to access the YANG type? > > Thanks, > > William > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton > Sent: 10 May 2016 18:27 > To: Linda Dunbar > Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org' > Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 > > Hi Linda, > > I think that having the base identity makes the model safer and more extensible in future. I think that the general idea of a base identity is fairly standard and is perhaps a bit like defining an abstract base class in an OO language. > > So, in YANG, rather than a when statement having to explicitly check for ipv4-acl or ipv6-acl it can just check for any type derived from acl-base, which allows for new types of ACL to be defined in future (potentially in different modules). > > Conversely, it also helps prevent someone from using a completely inappropriate identity, e.g. say trying to use an interface type identity such as ift:ethernetCsmacd where a type of ACL identity is required. > > Thanks, > Rob > > > On 10/05/2016 17:55, Linda Dunbar wrote: > > Juergen, > > > > Of course, it is not confusing to you because you are in the box (vs. many of us are outside the box looking in). > > > > RFC 6020 doesn't say all identities have to have a sub-identity. > > > > > > My opinion only. > > > > > > Linda > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, May 10, 2016 10:38 AM > > To: Linda Dunbar > > Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas D. > > Nadeau > > Subject: Re: Can you remove the "Identity acl-base" defined in > > draft-ietf-netmod-acl-model-07 > > > > On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: > >> Juergen, > >> > >> If "acl-base" has some content more than the comment (i.e. the description), then it makes sense. > >> > >> The comments in the "identity ipv4-acl" is enough to describe the identity. Same with the identity ipv6-acl. > >> > >> I find it is very confusing to have the recursive reference of identity (all of them are simply the description). > >> > > I fail to see anything confusing here. Did you read the relevant sections of RFC 6020? What is unclear about identities and how they work? > > > > /js > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=MlQZEKdXoP4IwlPcElVo_hIsmcgPxkS1AvAc3uGRU_E&s=iht1ryWsM95ONkVXCHgLCn-rGgsZVjmO0P_Hnhg2llM&e= > > _______________________________________________ > 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 Wed May 11 01:40:48 2016 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 6F13012D1C8; Wed, 11 May 2016 01:40: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, 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 mDrHeKPJO0BI; Wed, 11 May 2016 01:40:45 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (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 340A112D094; Wed, 11 May 2016 01:40:45 -0700 (PDT) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u4B8aNc2007619; Wed, 11 May 2016 01:40:36 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 22u533n9v2-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 May 2016 01:40:36 -0700 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 02:40:25 -0600 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 10:40:24 +0200 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Wed, 11 May 2016 10:40:24 +0200 From: William Ivory To: Juergen Schoenwaelder Thread-Topic: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 Thread-Index: AdGqbibMI0ZS5SbaSgSLdPnQFDvHlP//6cWAgACzvgCAAAhqgIAAFdCAgAAIwgD//uYToIACFbMA///bw3A= Date: Wed, 11 May 2016 08:40:04 +0000 Deferred-Delivery: Wed, 11 May 2016 08:39:11 +0000 Message-ID: <8847389a24de48ce9132fc81fe7a1a77@EMEAWP-EXMB12.corp.brocade.com> References: <4A95BA014132FF49AE685FAB4B9F17F657E82F0A@dfweml501-mbb> <20160510042411.GA49737@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E83230@dfweml501-mbb> <20160510153737.GA50842@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657E833A3@dfweml501-mbb> <998bc143d376428085e77696381cc097@EMEAWP-EXMB12.corp.brocade.com> <20160511082810.GA52653@elstar.local> In-Reply-To: <20160511082810.GA52653@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.212.174] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-11_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1605110115 Archived-At: Cc: "draft-ietf-netmod-acl-model@ietf.org" , "'netmod@ietf.org'" Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 08:40:47 -0000 Thanks - had forgotten those YANG 1.1 extensions. William -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: 11 May 2016 09:28 To: William Ivory Cc: Robert Wilton ; Linda Dunbar ; draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org' Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 YANG 1.1 introduces special functions for identities such as derived-from() or derived-from-or-self(), for more details see section 10.4 of draft-ietf-netmod-rfc6020bis-12. /js On Wed, May 11, 2016 at 08:19:01AM +0000, William Ivory wrote: > Hi Rob, > > Probably a stupid question but how would you write a 'when' statement that checks identity type? What XPATH function / expression would allow you to access the YANG type? > > Thanks, > > William > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton > Sent: 10 May 2016 18:27 > To: Linda Dunbar > Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org' > Subject: Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 > > Hi Linda, > > I think that having the base identity makes the model safer and more extensible in future. I think that the general idea of a base identity is fairly standard and is perhaps a bit like defining an abstract base class in an OO language. > > So, in YANG, rather than a when statement having to explicitly check for ipv4-acl or ipv6-acl it can just check for any type derived from acl-base, which allows for new types of ACL to be defined in future (potentially in different modules). > > Conversely, it also helps prevent someone from using a completely inappropriate identity, e.g. say trying to use an interface type identity such as ift:ethernetCsmacd where a type of ACL identity is required. > > Thanks, > Rob > > > On 10/05/2016 17:55, Linda Dunbar wrote: > > Juergen, > > > > Of course, it is not confusing to you because you are in the box (vs. many of us are outside the box looking in). > > > > RFC 6020 doesn't say all identities have to have a sub-identity. > > > > > > My opinion only. > > > > > > Linda > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, May 10, 2016 10:38 AM > > To: Linda Dunbar > > Cc: draft-ietf-netmod-acl-model@ietf.org; 'netmod@ietf.org'; Thomas D. > > Nadeau > > Subject: Re: Can you remove the "Identity acl-base" defined in > > draft-ietf-netmod-acl-model-07 > > > > On Tue, May 10, 2016 at 03:07:30PM +0000, Linda Dunbar wrote: > >> Juergen, > >> > >> If "acl-base" has some content more than the comment (i.e. the description), then it makes sense. > >> > >> The comments in the "identity ipv4-acl" is enough to describe the identity. Same with the identity ipv6-acl. > >> > >> I find it is very confusing to have the recursive reference of identity (all of them are simply the description). > >> > > I fail to see anything confusing here. Did you read the relevant sections of RFC 6020? What is unclear about identities and how they work? > > > > /js > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=MlQZEKdXoP4IwlPcElVo_hIsmcgPxkS1AvAc3uGRU_E&s=iht1ryWsM95ONkVXCHgLCn-rGgsZVjmO0P_Hnhg2llM&e= > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=CwIBAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=9SqA4lSC3_C0sr1ZX9Wd7wI8KYym05LqlsRSMn9nS0k&s=VTDyjdlJ_E4CVhRCNWy3hNeKwtWozq2hfJn5IvnwR7g&e= -- 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 May 12 01:33:45 2016 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 831E612B044 for ; Thu, 12 May 2016 01:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 JpIzD-Zp3xL9 for ; Thu, 12 May 2016 01:33:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7A112B02D for ; Thu, 12 May 2016 01:33:40 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 841BEC128406 for ; Thu, 12 May 2016 08:33:37 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4C8Xcg7015700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 12 May 2016 08:33:38 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4C8XZTn018920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 May 2016 10:33:38 +0200 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.241]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 12 May 2016 10:33:36 +0200 From: "Bogaert, Bart (Nokia - BE)" To: "netmod@ietf.org" Thread-Topic: [netmod] yang-next Thread-Index: AQHRe39KZKSMweMrzky7bfSTyNQFZ5+1V1sA Date: Thu, 12 May 2016 08:33:36 +0000 Message-ID: References: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> <20160311.111749.461139040057688947.mbj@tail-f.com> In-Reply-To: <20160311.111749.461139040057688947.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0062_01D1AC39.BCD2CCE0" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] yang-next X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 08:33:44 -0000 ------=_NextPart_000_0062_01D1AC39.BCD2CCE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Not sure whether this has been requested before but has it ever been = considered to support higher versions of XPATH in YANG? As far as I = remember only XPATH 1.0 is supported in YANG although the RFC mentions = adopting of XPATH 2.0 with respect to handling of unprefixed names. = RFC6020bis lists a set of functions that have been added and that are = available in an XPATH context. XPATH itself at this moment is at = version 3.1. Some questions: - are there any plans to follow the XPATH evolution in YANG? - to me at least it is not specifically clear what is and what is not = supported w.r.t. XPATH in YANG. Is there no clarification required in = this context? Certain checks can't be expressed using an XPATH and require XQUERY = (e.g. when one need to follow a linked list in case of a lookup of a = specific node). Are there any plans to include support for XQUERY in = YANG? Best regards - Vriendelijke groeten, Bart Bogaert Broadband-Access System Architect Data Contact number +32 3 2408310 (+32 477 673952) NOKIA Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 0404 621 642 Register of Legal Entities Antwerp << This message (including any attachments) contains confidential = information intended for a specific individual and purpose, and is = protected by law. If you are not the intended recipient, you should = delete this message. Any disclosure, copying, or distribution of this = message, or the taking of any action based on it, is strictly prohibited = without the prior consent of its author. >>=20 -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT Martin = Bjorklund Sent: 11 March 2016 11:18 To: kwatsen@juniper.net Cc: netmod@ietf.org Subject: Re: [netmod] yang-next Hi, Kent Watsen wrote: >=20 > All, >=20 > I see too many emails go by where someone has an idea that = they=E2=80=99d like=20 > to get into a future version of YANG, and keep wishing that there were = > an easy way to capture these feature requests. With that in mind I=20 > created a new Github repository called "yang-next=E2=80=9D. This = repository=20 > is not for a draft, yet, its current existence is solely to have a=20 > publicly editable issue tracker. Please feel free to add all your=20 > good ideas (just one idea per issue please) here: > https://github.com/netmod-wg/yang-next/issues. I think it is a good idea to capture ideas like this, but I also think = that such ideas should be discussed on the ML. But maybe that's what = you meant. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0062_01D1AC39.BCD2CCE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNTEyMDgzMzM1WjAjBgkqhkiG9w0B CQQxFgQUAb/jdRrOCMieusJk/PsSQt1w6EswgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQBC igrXXvqqa9KVIAxA+AELQ1G4ewHkNOOBi6erp8fMzcYXziaLKwGXnlUtJApUVrsNcdPVS3r3RB8Q 3QqinMrBkGl4e1lY1Xi+9ZHV2RUF5kFTTb06CJxleQtsYPAus1GekLqdSqidbbmQir0hlILUbOE/ NIATmEkntOvE8R9SLbGhp8//3Vbz2ODuCAbGNpOj0/Ay+jt84b2JnkemqIrHpd4fZkIlzLY7kwwH 64AXGHQQnNSUtA0auwp/69BXpHF/UkLgiXR5F7CcQGm1QarMRf7I7Gry4Cwgzoec2kXITTZS48Vn HQBpdi0GZK6YgQjOimSH1gi7YveMu7Q04a+ZAAAAAAAA ------=_NextPart_000_0062_01D1AC39.BCD2CCE0-- From nobody Thu May 12 01:57:15 2016 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 28E9612D112 for ; Thu, 12 May 2016 01:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVbpOisOToeu for ; Thu, 12 May 2016 01:57:11 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3176812B044 for ; Thu, 12 May 2016 01:57:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F34918F4; Thu, 12 May 2016 10:57:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id byND3uQjIo-g; Thu, 12 May 2016 10:56:52 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 12 May 2016 10:57:08 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01DDD20054; Thu, 12 May 2016 10:57:08 +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 miD4sr5DyguK; Thu, 12 May 2016 10:57:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E48D20053; Thu, 12 May 2016 10:57:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 46A233AD178A; Thu, 12 May 2016 10:57:05 +0200 (CEST) Date: Thu, 12 May 2016 10:57:04 +0200 From: Juergen Schoenwaelder To: "Bogaert, Bart (Nokia - BE)" Message-ID: <20160512085702.GA55367@elstar.local> Mail-Followup-To: "Bogaert, Bart (Nokia - BE)" , "netmod@ietf.org" References: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> <20160311.111749.461139040057688947.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: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-next X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 08:57:14 -0000 On Thu, May 12, 2016 at 08:33:36AM +0000, Bogaert, Bart (Nokia - BE) wrote: > Hi, > > Not sure whether this has been requested before but has it ever been considered to support higher versions of XPATH in YANG? As far as I remember only XPATH 1.0 is supported in YANG although the RFC mentions adopting of XPATH 2.0 with respect to handling of unprefixed names. RFC6020bis lists a set of functions that have been added and that are available in an XPATH context. XPATH itself at this moment is at version 3.1. Some questions: > - are there any plans to follow the XPATH evolution in YANG? So far, XPATH 2.0 has been considered too complex to require and there were concerns of how widespread support there is for XPATH 2.0 (and 3.0 was never mentioned I think). > - to me at least it is not specifically clear what is and what is not supported w.r.t. XPATH in YANG. Is there no clarification required in this context? Can you further detail what you find missing or unclear in draft-ietf-netmod-rfc6020bis-12.txt regarding xpath? Simply search for xpath, there is quite some text in various places. > Certain checks can't be expressed using an XPATH and require XQUERY (e.g. when one need to follow a linked list in case of a lookup of a specific node). Are there any plans to include support for XQUERY in YANG? So far not. Note that the goal so far has been to be somewhat conservative, that is, to add features based on a good understanding which real-world problems are being solved and ideally based on implementation and even better early deployment experience. (A new feature that has been implemented and successfully used as proprietary extensions is likely more important to consider than something that exists as an idea on paper only). /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 May 12 02:28:45 2016 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 488A712D199 for ; Thu, 12 May 2016 02:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ZpmFZMsZe9n0 for ; Thu, 12 May 2016 02:28:40 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D1E12D17A for ; Thu, 12 May 2016 02:28:40 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id A0F6E50006DB3; Thu, 12 May 2016 09:28:36 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4C9SbQC030363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 May 2016 09:28:38 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4C9SUvV017108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 May 2016 11:28:36 +0200 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.241]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 12 May 2016 11:28:26 +0200 From: "Bogaert, Bart (Nokia - BE)" To: Juergen Schoenwaelder Thread-Topic: [netmod] yang-next Thread-Index: AQHRe39KZKSMweMrzky7bfSTyNQFZ5+1V1sA///ooQCAACThYA== Date: Thu, 12 May 2016 09:28:25 +0000 Message-ID: References: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> <20160311.111749.461139040057688947.mbj@tail-f.com> <20160512085702.GA55367@elstar.local> In-Reply-To: <20160512085702.GA55367@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007F_01D1AC41.65A15A60" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-next X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 09:28:43 -0000 ------=_NextPart_000_007F_01D1AC41.65A15A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Juergen, Thanks for the feedback. With respect to functions available when using XPATH: XPATH 1.0 refers to a Core Function Library. All the functions defined in there (Node set functions, string functions, Boolean and number functions) are available in a YANG XPATH context? How wide-spread XPATH 2.0 and 3.0 is I also do not have an idea (I'm currently "playing" with BaseX and there these versions are supported as far as I know) but the fact that there are multiple versions of the standard can cause confusion about what is "in" and what is "not in". So if, for RFC6020bis, the supported set of functions is: 1. the Core Function library of XPATH 1.0 2. the added functions listed in RFC6020bis We could conclude that the functionality is "confined". Maybe a statement about full support of the Core Function Library of XPATH 1.0 in the RFC could take away that ambiguity? Best regards - Vriendelijke groeten, Bart Bogaert Broadband-Access System Architect Data Contact number +32 3 2408310 (+32 477 673952) NOKIA Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 0404 621 642 Register of Legal Entities Antwerp << This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. >> -----Original Message----- From: EXT Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: 12 May 2016 10:57 To: Bogaert, Bart (Nokia - BE) Cc: netmod@ietf.org Subject: Re: [netmod] yang-next On Thu, May 12, 2016 at 08:33:36AM +0000, Bogaert, Bart (Nokia - BE) wrote: > Hi, > > Not sure whether this has been requested before but has it ever been considered to support higher versions of XPATH in YANG? As far as I remember only XPATH 1.0 is supported in YANG although the RFC mentions adopting of XPATH 2.0 with respect to handling of unprefixed names. RFC6020bis lists a set of functions that have been added and that are available in an XPATH context. XPATH itself at this moment is at version 3.1. Some questions: > - are there any plans to follow the XPATH evolution in YANG? So far, XPATH 2.0 has been considered too complex to require and there were concerns of how widespread support there is for XPATH 2.0 (and 3.0 was never mentioned I think). > - to me at least it is not specifically clear what is and what is not supported w.r.t. XPATH in YANG. Is there no clarification required in this context? Can you further detail what you find missing or unclear in draft-ietf-netmod-rfc6020bis-12.txt regarding xpath? Simply search for xpath, there is quite some text in various places. > Certain checks can't be expressed using an XPATH and require XQUERY (e.g. when one need to follow a linked list in case of a lookup of a specific node). Are there any plans to include support for XQUERY in YANG? So far not. Note that the goal so far has been to be somewhat conservative, that is, to add features based on a good understanding which real-world problems are being solved and ideally based on implementation and even better early deployment experience. (A new feature that has been implemented and successfully used as proprietary extensions is likely more important to consider than something that exists as an idea on paper only). /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_007F_01D1AC41.65A15A60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNTEyMDkyODI0WjAjBgkqhkiG9w0B CQQxFgQUzNL3qzu56XuacEgUyjN4HfoBMoAwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQBt mqGNbvVQf5AxDaRPclGnxH413hzuBw48qvvxys0SvzJBTfI9v+ib5kPEqvJgAzRjBqat+wGal8WC iK89upAga8Nbkle70g1nSRLMeIQlTB3cMtHSclBDGFaET2CvslClANIQsp+oxKTNEc1iqpxMqOiO 73RWwM4BHK/XF+xDlZuVDpZA7jGkzRdC+uOx4M4mtzvMkC8uZLGtTY+ZMY1gZ7ZRcpCpBXycuRGT VtuqxlOxcN68K6GO7EfnoQcfN3v6RLZYOC56o42XE+kaKlWKYYPN3EMExsxA0PBFqXxAeLTMLCl/ nia2+OD8kS+IrfAqQlZdhbj8/D1caHWh6kwiAAAAAAAA ------=_NextPart_000_007F_01D1AC41.65A15A60-- From nobody Thu May 12 03:12:50 2016 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 BFC2112DB1B for ; Thu, 12 May 2016 03:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzz-p76xAuhg for ; Thu, 12 May 2016 03:12:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E2C12D0C6 for ; Thu, 12 May 2016 03:10:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 51B3511D0; Thu, 12 May 2016 12:10:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gJQNvDCchVJu; Thu, 12 May 2016 12:10:29 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 12 May 2016 12:10:45 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 794762004E; Thu, 12 May 2016 12:10:45 +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 k3XPm1oTPlY0; Thu, 12 May 2016 12:10:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CA3A20050; Thu, 12 May 2016 12:10:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 346C43AD1954; Thu, 12 May 2016 12:10:42 +0200 (CEST) Date: Thu, 12 May 2016 12:10:42 +0200 From: Juergen Schoenwaelder To: "Bogaert, Bart (Nokia - BE)" Message-ID: <20160512101042.GA55560@elstar.local> Mail-Followup-To: "Bogaert, Bart (Nokia - BE)" , "netmod@ietf.org" References: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> <20160311.111749.461139040057688947.mbj@tail-f.com> <20160512085702.GA55367@elstar.local> 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: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-next X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 10:12:49 -0000 On Thu, May 12, 2016 at 09:28:25AM +0000, Bogaert, Bart (Nokia - BE) wrote: > Juergen, > > Thanks for the feedback. > With respect to functions available when using XPATH: XPATH 1.0 refers to a > Core Function Library. All the functions defined in there (Node set > functions, string functions, Boolean and number functions) are available in > a YANG XPATH context? The YANG specification refers to XPath 1.0 and https://www.w3.org/TR/1999/REC-xpath-19991116/#corelib (section 4 Core Function Library) says This section describes functions that XPath implementations must always include in the function library that is used to evaluate expressions. and hence I think a compliant implementation must support the XPath 1.0 Core Function Library. > How wide-spread XPATH 2.0 and 3.0 is I also do not have an idea (I'm > currently "playing" with BaseX and there these versions are supported as far > as I know) but the fact that there are multiple versions of the standard can > cause confusion about what is "in" and what is "not in". As far as I understand, libxml2 does not support XPath 2.0 (or 3.0) and having a well maintained open source XPath 2.0 implementation in C is likely of some importance. > So if, for > RFC6020bis, the supported set of functions is: > 1. the Core Function library of XPATH 1.0 > 2. the added functions listed in RFC6020bis > We could conclude that the functionality is "confined". Maybe a statement > about full support of the Core Function Library of XPATH 1.0 in the RFC > could take away that ambiguity? I agree that it is not explicitely stated that YANG 1.1 requires the support of 1. and 2. (see above) but if you follow the references to XPath 1.0, I think it is implicitely clear. /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 May 12 03:17:20 2016 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 BABBA12DB8A for ; Thu, 12 May 2016 03:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mg-soft.si 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 2X9t4ofUeJ2H for ; Thu, 12 May 2016 03:17:14 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id D527012D1BC for ; Thu, 12 May 2016 03:14:09 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id DFED8C42F811; Thu, 12 May 2016 12:14:05 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 galileo.mg-soft.si DFED8C42F811 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1463048045; bh=9w3PWMi0NGkGS8fE13jzyqWET6iLAACc3DAjc68lXso=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To:From; b=ZeW3aWHBpVHzPkH5a26Uy/mdI6KFXbACv+u5qBZuZkzCLwiVG3HoLu3cJ7w5iBcY6 W5lE4O/USifqdP5oGmVFBVrkdF7Uk54XQpaH7L1ssOye/61cNLEmYqxu/YVROd5zGk RKX5Gbi855wzQsUANBuou7LT/drU9xKRv94UVJMqfsPJEfxHaKV6Vmrfcn6zciXeIL XgCE3Dq+QvYA+uyjfsaAHN5TMtCrzTZ/cIFre/xg22Y2KtTpr9aWRL1mE1OHOuJ+Aq ROzchmrWWyd5H2seRfhzxzxJMFLgjfTgthwgAD9TNRmHwsbUylcQWtL1Teh22C9kJu a+5+UFMh/LSMg== References: <30334F54-3461-44B2-B19E-0C512ADFD802@juniper.net> <20160311.111749.461139040057688947.mbj@tail-f.com> <20160512085702.GA55367@elstar.local> To: "Bogaert, Bart (Nokia - BE)" , Juergen Schoenwaelder From: Jernej Tuljak Message-ID: Date: Thu, 12 May 2016 12:14:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C63EB30D35F1B6858E13152C" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-next X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jernej.tuljak@mg-soft.si List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 10:17:19 -0000 This is a multi-part message in MIME format. --------------C63EB30D35F1B6858E13152C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Bogaert, Bart (Nokia - BE) je 12.5.2016 ob 11:28 napisal: > Juergen, > > Thanks for the feedback. > With respect to functions available when using XPATH: XPATH 1.0 refers to a > Core Function Library. All the functions defined in there (Node set > functions, string functions, Boolean and number functions) are available in > a YANG XPATH context? Yes. All functions defined in XPATH spec [1] are available. Usage of some of them is discouraged, however. See Section 5.6.2 of usage guidelines document [2]. [1] - https://www.w3.org/TR/1999/REC-xpath-19991116/#corelib [2] - https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-06#section-5.6.2 Jernej > > How wide-spread XPATH 2.0 and 3.0 is I also do not have an idea (I'm > currently "playing" with BaseX and there these versions are supported as far > as I know) but the fact that there are multiple versions of the standard can > cause confusion about what is "in" and what is "not in". So if, for > RFC6020bis, the supported set of functions is: > 1. the Core Function library of XPATH 1.0 > 2. the added functions listed in RFC6020bis > We could conclude that the functionality is "confined". Maybe a statement > about full support of the Core Function Library of XPATH 1.0 in the RFC > could take away that ambiguity? > > Best regards - Vriendelijke groeten, > Bart Bogaert > Broadband-Access System Architect Data > Contact number +32 3 2408310 (+32 477 673952) > > NOKIA > Copernicuslaan 50, 2018 Antwerp, Belgium > Fortis 220-0002334-42 > VAT BE 0404 621 642 Register of Legal Entities Antwerp > > << > This message (including any attachments) contains confidential information > intended for a specific individual and purpose, and is protected by law. If > you are not the intended recipient, you should delete this message. Any > disclosure, copying, or distribution of this message, or the taking of any > action based on it, is strictly prohibited without the prior consent of its > author. > > -----Original Message----- > From: EXT Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 12 May 2016 10:57 > To: Bogaert, Bart (Nokia - BE) > Cc: netmod@ietf.org > Subject: Re: [netmod] yang-next > > On Thu, May 12, 2016 at 08:33:36AM +0000, Bogaert, Bart (Nokia - BE) wrote: >> Hi, >> >> Not sure whether this has been requested before but has it ever been > considered to support higher versions of XPATH in YANG? As far as I > remember only XPATH 1.0 is supported in YANG although the RFC mentions > adopting of XPATH 2.0 with respect to handling of unprefixed names. > RFC6020bis lists a set of functions that have been added and that are > available in an XPATH context. XPATH itself at this moment is at version > 3.1. Some questions: >> - are there any plans to follow the XPATH evolution in YANG? > So far, XPATH 2.0 has been considered too complex to require and there were > concerns of how widespread support there is for XPATH 2.0 (and > 3.0 was never mentioned I think). > >> - to me at least it is not specifically clear what is and what is not > supported w.r.t. XPATH in YANG. Is there no clarification required in this > context? > > Can you further detail what you find missing or unclear in > draft-ietf-netmod-rfc6020bis-12.txt regarding xpath? Simply search for > xpath, there is quite some text in various places. > >> Certain checks can't be expressed using an XPATH and require XQUERY (e.g. > when one need to follow a linked list in case of a lookup of a specific > node). Are there any plans to include support for XQUERY in YANG? > > So far not. > > Note that the goal so far has been to be somewhat conservative, that is, to > add features based on a good understanding which real-world problems are > being solved and ideally based on implementation and even better early > deployment experience. (A new feature that has been implemented and > successfully used as proprietary extensions is likely more important to > consider than something that exists as an idea on paper only). > > /js > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------C63EB30D35F1B6858E13152C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Bogaert, Bart (Nokia - BE) je 12.5.2016 ob 11:28napisal:
Juergen,

Thanks for the feedback.
With respect to functions available when using XPATH: XPATH 1.0 refers to a
Core Function Library.  All the functions defined in there (Node set
functions, string functions, Boolean and number functions) are available in
a YANG XPATH context?

Yes. All functions defined in XPATH spec [1] are available. Usage of some of them is discouraged, however. See Section 5.6.2 of usage guidelines document [2].

[1] - https://www.w3.org/TR/1999/REC-xpath-19991116/#corelib
[2] - https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-06#section-5.6.2

Jernej


How wide-spread XPATH 2.0 and 3.0 is I also do not have an idea (I'm
currently "playing" with BaseX and there these versions are supported as far
as I know) but the fact that there are multiple versions of the standard can
cause confusion about what is "in" and what is "not in".  So if, for
RFC6020bis, the supported set of functions is:
1. the Core Function library of XPATH 1.0
2. the added functions listed in RFC6020bis
We could conclude that the functionality is "confined".  Maybe a statement
about full support of the Core Function Library of XPATH 1.0 in the RFC
could take away that ambiguity?

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.


        

      

      

-----Original Message-----
From: EXT Juergen Schoenwaelder
[mailto:j.schoenwaelder@jacobs-university.de] 
Sent: 12 May 2016 10:57
To: Bogaert, Bart (Nokia - BE)
Cc: netmod@ietf.org
Subject: Re: [netmod] yang-next

On Thu, May 12, 2016 at 08:33:36AM +0000, Bogaert, Bart (Nokia - BE) wrote:


      

        
Hi,

Not sure whether this has been requested before but has it ever been


      

      
considered to support higher versions of XPATH in YANG?  As far as I
remember only XPATH 1.0 is supported in YANG although the RFC mentions
adopting of XPATH 2.0 with respect to handling of unprefixed names.
RFC6020bis lists a set of functions that have been added and that are
available in an XPATH context.  XPATH itself at this moment is at version
3.1.  Some questions:


      

        
- are there any plans to follow the XPATH evolution in YANG?


      

      
So far, XPATH 2.0 has been considered too complex to require and there were
concerns of how widespread support there is for XPATH 2.0 (and
3.0 was never mentioned I think).



      

        
- to me at least it is not specifically clear what is and what is not


      

      
supported w.r.t. XPATH in YANG.  Is there no clarification required in this
context?

Can you further detail what you find missing or unclear in
draft-ietf-netmod-rfc6020bis-12.txt regarding xpath? Simply search for
xpath, there is quite some text in various places.



      

        
Certain checks can't be expressed using an XPATH and require XQUERY (e.g.


      

      
when one need to follow a linked list in case of a lookup of a specific
node).  Are there any plans to include support for XQUERY in YANG?

So far not.

Note that the goal so far has been to be somewhat conservative, that is, to
add features based on a good understanding which real-world problems are
being solved and ideally based on implementation and even better early
deployment experience. (A new feature that has been implemented and
successfully used as proprietary extensions is likely more important to
consider than something that exists as an idea on paper only).

/js



      

      

      

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


    

    


    

  


--------------C63EB30D35F1B6858E13152C--


From nobody Thu May 12 03:21:05 2016
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 1E64812DBDE for ; Thu, 12 May 2016 03:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level: 
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkcK_HaTAOXG for ; Thu, 12 May 2016 03:20:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E13912DAFF for ; Thu, 12 May 2016 03:17:51 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 6911F1AE0426; Thu, 12 May 2016 12:17:50 +0200 (CEST)
Date: Thu, 12 May 2016 12:18:08 +0200 (CEST)
Message-Id: <20160512.121808.1775300231370838930.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20160512101042.GA55560@elstar.local>
References: <20160512085702.GA55367@elstar.local>  <20160512101042.GA55560@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] yang-next
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 May 2016 10:21:03 -0000

Juergen Schoenwaelder  wrote:
> On Thu, May 12, 2016 at 09:28:25AM +0000, Bogaert, Bart (Nokia - BE) wrote:
> > Juergen,
> > 
> > Thanks for the feedback.
> > With respect to functions available when using XPATH: XPATH 1.0 refers to a
> > Core Function Library.  All the functions defined in there (Node set
> > functions, string functions, Boolean and number functions) are available in
> > a YANG XPATH context?
> 
> The YANG specification refers to XPath 1.0 and
> 
> https://www.w3.org/TR/1999/REC-xpath-19991116/#corelib
> 
> (section 4 Core Function Library) says
> 
>   This section describes functions that XPath implementations must
>   always include in the function library that is used to evaluate
>   expressions.
> 
> and hence I think a compliant implementation must support the XPath
> 1.0 Core Function Library.
>  
> > How wide-spread XPATH 2.0 and 3.0 is I also do not have an idea (I'm
> > currently "playing" with BaseX and there these versions are supported as far
> > as I know) but the fact that there are multiple versions of the standard can
> > cause confusion about what is "in" and what is "not in".
> 
> As far as I understand, libxml2 does not support XPath 2.0 (or 3.0)
> and having a well maintained open source XPath 2.0 implementation in C
> is likely of some importance.
> 
> > So if, for
> > RFC6020bis, the supported set of functions is:
> > 1. the Core Function library of XPATH 1.0
> > 2. the added functions listed in RFC6020bis
> > We could conclude that the functionality is "confined".  Maybe a statement
> > about full support of the Core Function Library of XPATH 1.0 in the RFC
> > could take away that ambiguity?
> 
> I agree that it is not explicitely stated that YANG 1.1 requires the
> support of 1. and 2.

See section 6.4.1 of 6020bis, where it explicitly says:

   o  The function library is the core function library defined in
      [XPATH], and the functions defined in Section 10.


/martin


> (see above) but if you follow the references to
> XPath 1.0, I think it is implicitely clear.
> 
> /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 May 12 03:23:10 2016
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 A122312DB67 for ; Thu, 12 May 2016 03:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRWefPweoIvH for ; Thu, 12 May 2016 03:23:06 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B44612DB56 for ; Thu, 12 May 2016 03:20:19 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DF5A31260; Thu, 12 May 2016 12:20:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 78-HljiXZ3eh; Thu, 12 May 2016 12:19:58 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 12 May 2016 12:20:14 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F3062006A; Thu, 12 May 2016 12:20:14 +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 Nwvq2Sh-xDn5; Thu, 12 May 2016 12:19:59 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AA9C20055; Thu, 12 May 2016 12:19:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2F8A03AD1A46; Thu, 12 May 2016 12:19:55 +0200 (CEST)
Date: Thu, 12 May 2016 12:19:55 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20160512101955.GA55617@elstar.local>
Mail-Followup-To: Martin Bjorklund , bart.bogaert@nokia.com, netmod@ietf.org
References: <20160512085702.GA55367@elstar.local>  <20160512101042.GA55560@elstar.local> <20160512.121808.1775300231370838930.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160512.121808.1775300231370838930.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] yang-next
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 May 2016 10:23:08 -0000

On Thu, May 12, 2016 at 12:18:08PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Thu, May 12, 2016 at 09:28:25AM +0000, Bogaert, Bart (Nokia - BE) wrote:
> > > Juergen,
> > > 
> > > Thanks for the feedback.
> > > With respect to functions available when using XPATH: XPATH 1.0 refers to a
> > > Core Function Library.  All the functions defined in there (Node set
> > > functions, string functions, Boolean and number functions) are available in
> > > a YANG XPATH context?
> > 
> > The YANG specification refers to XPath 1.0 and
> > 
> > https://www.w3.org/TR/1999/REC-xpath-19991116/#corelib
> > 
> > (section 4 Core Function Library) says
> > 
> >   This section describes functions that XPath implementations must
> >   always include in the function library that is used to evaluate
> >   expressions.
> > 
> > and hence I think a compliant implementation must support the XPath
> > 1.0 Core Function Library.
> >  
> > > How wide-spread XPATH 2.0 and 3.0 is I also do not have an idea (I'm
> > > currently "playing" with BaseX and there these versions are supported as far
> > > as I know) but the fact that there are multiple versions of the standard can
> > > cause confusion about what is "in" and what is "not in".
> > 
> > As far as I understand, libxml2 does not support XPath 2.0 (or 3.0)
> > and having a well maintained open source XPath 2.0 implementation in C
> > is likely of some importance.
> > 
> > > So if, for
> > > RFC6020bis, the supported set of functions is:
> > > 1. the Core Function library of XPATH 1.0
> > > 2. the added functions listed in RFC6020bis
> > > We could conclude that the functionality is "confined".  Maybe a statement
> > > about full support of the Core Function Library of XPATH 1.0 in the RFC
> > > could take away that ambiguity?
> > 
> > I agree that it is not explicitely stated that YANG 1.1 requires the
> > support of 1. and 2.
> 
> See section 6.4.1 of 6020bis, where it explicitly says:
> 
>    o  The function library is the core function library defined in
>       [XPATH], and the functions defined in Section 10.
>

Yes, I just found it as well. Good.

/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 May 12 17:36:21 2016
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 557A112B01B for ; Thu, 12 May 2016 17:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 P1x5dger4LxE for ; Thu, 12 May 2016 17:36:14 -0700 (PDT)
Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 E7A9412D09C for ; Thu, 12 May 2016 17:36:13 -0700 (PDT)
Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by comcast with SMTP id 112ibFLqlp1Be115RbfBWg; Fri, 13 May 2016 00:36:13 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1463099773; bh=C4VN7gy6WjMOPhi65FQK+dKkY5m4yltEVFI1x5yYlzs=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=eihBjOx/zn26johXpMBKLKPDV1j+e4dX95Sr9UPipZ5kvpejSaadLdg7hu0+pT6MJ CtiUCBT+j9e+cWj/oThujLLjrNsfR+eaD5lSHpso7ZLyPzX2t3P+U9jrzPRn/Q34eR KhyLWm4ec6BpHtnyVSoqKmjPCMZGBaQs87sz1VThfqXVwuBv+0bsKX7mO8RNhBtX42 hWBKxN2aB96nq4g1fhFxlLQsdvI9Jnqm5oVYcdTWsFUG7+bzIV9uS9vuxI1dNJY0i4 shNJ6tmPGVRVOm4NKadWaclDQqgoaBYNOYybQUzxVJR7DMFVJOZQAtTSMLG1NNqWZk 9EQrONLKcuktw==
Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-15v.sys.comcast.net with comcast id tccC1s00B1nMCLR01ccCQt; Fri, 13 May 2016 00:36:13 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u4D0aAUZ032111 for ; Thu, 12 May 2016 20:36:10 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u4D0aA3B032108; Thu, 12 May 2016 20:36:10 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: netmod@ietf.org
Sender: worley@ariadne.com (Dale R. Worley)
Date: Thu, 12 May 2016 20:36:10 -0400
Message-ID: <877feyrdz9.fsf@hobgoblin.ariadne.com>
Archived-At: 
Subject: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 May 2016 00:36:19 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-netmod-rfc6020bis-12
Reviewer: Dale R. Worley
Review Date: 2016-05-12
IETF LC End Date: 2016-05-12
IESG Telechat date: 2016-05-19

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.  I have a large number of
editorial comments.  A few of these comments address technical
uncertainties, but I strongly suspect that the technical issues have
long since been fixed, as this is a revision of Yang 1, and the
only needed work is clarifying the text.

- Abstract

This Abstract does not list what the document does.  E.g., define Yang
1.1.  Also might help to mention upward-incompatibility.  Basically,
go through section 1 to see what should be in Abstract.  Perhaps:

   YANG is a data modeling language originally designed to model
   configuration and state data manipulated by the Network
   Configuration Protocol (NETCONF), NETCONF remote procedure calls,
   and NETCONF notifications.  This document describes the syntax and
   semantics of version 1.1 of the YANG language.  YANG version 1.1 is
   a maintenance release of the YANG language, addressing ambiguities
   and defects in the original specification.  There are a small
   number of upward-incompatibilities from Yang 1.  This document also
   describes how a data model defined in a YANG module is encoded in
   the Extensible Markup Language (XML), and how NETCONF operations
   are used to manipulate the data.

- section 1.1

The incompatibilities should be marked whether the old, incompatible
usage always causes an error "at compile time", "at run time", or
changed behavior.

A number of later items seem to be upward-incompatibilities but not
marked as such:

   o  Made the "yang-version" statement mandatory.

   o  Made noncharacters illegal in the built-in type "string".

- section 3

   o  identifier: Used to identify different kinds of YANG items by
      name.

This item, unlike the others, does not start with a noun phrase.
Perhaps, "A string used to ..."?

   o  leaf: A data node that exists in at most one instance in the data
      tree.  A leaf has a value but no child nodes.

I'm not sure that this is correct; a leaf schema node inside a list
schema node can have many instances in a data tree.  The real
criterion is that it has a value but no child nodes.

   o  leaf-list: Like the leaf node but defines a set of uniquely
      identifiable nodes rather than a single node.  Each node has a
      value but no child nodes.

Better to say a "sequence of nodes".  Without the concept that the
nodes are a sequence (and can be identified by location within the
sequence), there's no assurance that the nodes are uniquely
identifiable (since they can have duplicate values in state data).

   o  mandatory node: A mandatory node is one of:
      ...
      *  A container node without a "presence" statement, which has at
         least one mandatory node as a child.

Perhaps replace the comma with "and"?

It would be useful to insert a note somewhere that all data is either
"configuration" or "state" data.  It's hard to learn that now, because
the terms "configuration data" and "state data" are defined only by
reference to RFC 6241.

There are general issues with the terms "namespace" and "prefix".

"namespace" is used to identify both the namespaces of identifiers in
Yang source (6.2.1) as well as XML namespaces in the XML encodings of
data trees.  It would make things clearer if all uses that refer to
XML namespaces used the form "XML namespace".

"prefix" is used to name both identifier prefixes in Yang source code
and XMLNS prefixes.  Worse, the prefix statement is used to declare
one string, which is then both the prefix used within the Yang source
code and also the preferred (but not mandatory!) XMLNS prefix used to
refer to the associated XML namespace.  It would help if "XMLNS
prefix" was used whenever talking specifically about prefixes used in
XML.  See also comments on section 7.1.4.

- section 3.1

There is an overall question regarding whitespace in XML in
"non-significant" places.  Is it allowed in the XML representation of
data trees?  And if so, precisely what whitespace is allowed?  Also,
to what degree is the whitespace shown in examples what is allowed on
the wire, and to what degree is it there just to make the example
easier to read?  (It's possible that XML has implemented some sort of
global solution for the issue of non-significant whitespace, but back
when I was using it regularly, there was none.)

- section 4.1

   YANG structures data models into modules and submodules.  A module
   can import data from other external modules, and include data from
   submodules.

"data" has other meanings.  Perhaps change to "elements of models" or
"definitions"?

   The instantiation of these groupings can refine or augment the
   nodes, allowing it to tailor the nodes to its particular needs.

"instantiate" is used with two meanings, the more common one being
the relationship between nodes and data tree elements, and the
insertion of a grouping into a node tree.  E.g., see the definitions
of "data tree" and "uses" in section 3.  It would make life easier if
there was a different word for the second meaning -- perhaps "use"?
In any case, this particular sentence has no context to disambiguate
the two meanings.

   The conversion from YANG to
   YIN is lossless, so content in YIN can be round-tripped back into
   YANG.

This is almost certainly not true.  But there is no loss of Yang
semantics, or something like that, and that could be stated.

   YANG strikes a balance between high-level data modeling and low-level
   bits-on-the-wire encoding.  The reader of a YANG module can see the
   high-level view of the data model while understanding how the data
   will be encoded on-the-wire.

Is that true in cases where the NETCONF XML wire encoding is not used?
Or is that encoding mandatory in some sense, even if the environment
is not NETCONF?  If Yang is intended to describe data which will
*always* be expressed in XML in a certain way, that fact should be
introduced earlier in the document.

- section 4.2.1

Section should start with a definition of "module" and what modules
are used for.  The current text is a list of details about "module"
without telling what the *point* of a module is.

   A module may be divided into submodules, based on the needs of the
   module owner.

There is a global problem that the reader needs to know the
relationships between "module" and "submodule", but those are not
stated explicitly anywhere.  (This is probably a candidate for
inclusion in section 3.)  AFAICT:

    A module
    - is defined by a module statement in its own file
    - defines a group of data trees, etc. that can be used by NETCONF
    - "includes" the submodules that "belong to" it

    A submodule
    - is defined by a submodule statement in its own file
    - defines things that can be used in the module statement
    - "belongs to" a single module, which is specified in the "belongs-to"
      substatement of the submodule statement
    - does NOT have submodules of its own

"module owner" is not defined in section 3.  And is it the right term;
is there an ownership relationship, or does this just mean "whoever
wrote the module"?  Or is there an understood social context in which
a module will be written that needs to be paid attention to in this
document?  (E.g., regarding allocation of XML namespaces.)

There is also the risk of misunderstanding between "own" and "belong
to" -- a submodule "belongs to" its module but the module doesn't
"own" the submodule.

Also, the module isn't "divided" into submodules, since there is
always a module statement.

Perhaps a better version of this paragraph is:

   A module may have portions of its definition separated into
   submodules, based on the needs of the module writer.  This
   separation is not visible outside the text of the module and
   submodules; neither importation into other modules nor the data
   encodings are affected.

--

   The "import" statement allows a module or submodule to reference
   material defined in other modules.

There is no definition of "material".  Clearly, it means "things that
can be referenced", but this points out that there is no term for
"things that can be referenced", but it would be useful to have one.
Then one could state, e.g., that a module can reference ???s defined
in its submodules, or it can reference ???s defined in modules that it
imports.

   The "include" statement is used by a module to incorporate the
   contents of its submodules into the module.

In a sense, "include" isn't really like "import", because it's not
optional; it's the mandatory reverse-link of the "belongs-to"
statement in the submodule.  (The module and all submodules
automatically have access to definitions in all submodules due to
their relationship.)

And that has been the cause of a lot of my confusion on this topic;
"include" and "import" are discussed together in many places, making
it unclear that "a module includes a submodule" is really a *static*
relationship, not a statement that the programmer could insert or not
according to need.  A clearer statement would be:

   The "include" statement is used in a module to identify each
   submodule that belongs to it.  The module's definitions have access
   to the definitions in the submodule.

It might be useful to define "include" and "belong to" in section 3.

- section 4.2.2.1

     leaf host-name {
       type string;
       description
         "Hostname for this system";
     }

It might be useful here to provide a forward reference to 6.3 as a
reference for the syntax of statements.  If you don't already know the
syntax, it can be hard to figure out that "host-name" is the node's
identifier.  Or perhaps the forward reference could be put at the end
of 4.2.2.

- section 4.2.2.3

   A container may contain any number of child nodes of any type
   (leafs, lists, containers, leaf- lists, actions, and
   notifications).

If the plural of "leaf" is "leafs" (rather than the standard English
"leaves"), that should be noted in the entry in section 3.

- section 4.2.2.4

   A list defines a sequence of list entries.  Each entry is like a
   structure or a record instance, and is uniquely identified by the
   values of its key leafs.  A list can define multiple key leafs and
   may contain any number of child nodes of any type (including leafs,
   lists, containers etc.).

Each entry is like a *container*, which was just defined above, which
might be a more intuitive way to describe it.

Perhaps "... is uniquely identified by the values of one or more
specified leaf children, the key leafs."

   XML Encoding Example:

     
       glocks
       Goldie Locks
       intruder
     
     
       snowey
       Snow White
       free-loader
     
     
       rzell
       Rapun Zell
       tower
     

I note that this example, unlike the previous ones, is not a single
XML element; there is no XML element that designates the list as a
whole.  That seems to be a general pattern in the XML encodings for
Yang, that groups of elements can be defined in Yang, but the
resulting set of elements is not wrapped in a single element in the
XML.  That happens with lists (where each list element is an element
but the list as a whole is not), leaf-list (where there is no element
surrounding the repeated leaf element), groupings, and choices with
their child cases.  Perhaps this is a general pattern in XML used for
network management, but it's not quite what one would expect if one
thinks of data structures in a programming language.  Perhaps it would
be helpful to point out this pattern somewhere that global XML issues
are described (e.g., whitespace issues).

- section 4.2.3

   YANG can model state data, as well as configuration data, based on
   the "config" statement.  When a node is tagged with "config false",
   its subhierarchy is flagged as state data.  In NETCONF, state data is
   reported using the  operation, not the  operation.
   Parent containers, lists, and key leafs are reported also, giving the
   context for the state data.

Does this mean that  returns the state data and 
returns the configuration data?  Or does  return both the state
and configuration data?  Perhaps this is not really a question for
this document, but if the behavior of  and  is
mentioned, they should be described thoroughly.

- section 4.2.4

   YANG has a set of built-in types, similar to those of many
   programming languages, but with some differences due to special
   requirements from the management domain.

"from the management domain" is awkward, and "domain" has no previous
definition; better "requirements of network management".

       | enumeration         | Enumerated strings                  |

Perhaps "one of an enumerated set of strings".

       | string              | Human-readable string               |

What does "human-readable" mean?  Can passwords be stored in such
leafs?  Does this really mean "a string of Unicode characters"?
Perhaps "character string" would be better.

- section 4.2.7

   YANG allows the data model to segregate incompatible nodes into
   distinct choices using the "choice" and "case" statements.  The
   "choice" statement contains a set of "case" statements that define
   sets of schema nodes that cannot appear together.  Each "case" may
   contain multiple nodes, but each node may appear in only one "case"
   under a "choice".

   When a node from one case is created in the data tree, all nodes from
   all other cases are implicitly deleted.  The server handles the
   enforcement of the constraint, preventing incompatibilities from
   existing in the configuration.

   The choice and case nodes appear only in the schema tree but not in
   the data tree.  The additional levels of hierarchy are not needed
   beyond the conceptual schema.

This description reads very oddly.  AFAICT, "choice" simply defines a
union type, where each alternative is a container (usually called a
structure or record).  Or rather, it's conceptually a container, but
in an XML instance of data, there is no start-end tags for the
structure as a whole (paralleling the lack of start-end tags for lists
as a whole).  Once you state that, it's clear why there are "sets of
schema nodes that cannot appear together".

- section 4.2.8

It would help to give a general discussion of augmenting.  If one
module augments another, is the augmented data definition part of the
data structures defined by augmenting module or the augmented one?

If I've got it right, this module:

   module /system/login/user {
     namespace "urn:user";
     prefix "user";

     list user {
       key "name";
       leaf name {
         type string;
       }
       leaf full-name {
         type string;
       }
       leaf class {
         type string;
       }
     }
   }

gives this as the XML encoding of a typical data tree:

     
       alicew
       Alice N. Wonderland
       drop-out
       1024
     

whereas the *existence* (in some sense) of this module:

   module /system/login/user-augmenter {
     namespace "urn:user-extension";
     prefix "ext";

     augment /system/login/user {
       when "class != 'wheel'";
       leaf uid {
         type uint16 {
           range "1000 .. 30000";
         }
       }
     }
   }

changes the encoding of the data tree to:

     
       alicew
       Alice N. Wonderland
       drop-out
       1024
     

What is it that triggers this action-at-a-distance?

   If a module augments another module, the XML encoding of the data
   will reflect the prefix of the augmenting module.  For example, if
   the above augmentation were in a module with prefix "other", the XML
   would look like:

This is hard to interpret.  Better would be:

   If a module augments another module, the XML elements that are
   added to the encoding are in the namespace of the augmenting module
   (which should preferentially be associated with the prefix of the
   augmenting module).

The restriction is on the XML namespace of the new element, not its
XMLNS prefix.

- section 5.1

   The module is the base unit of definition in YANG.  A module defines
   a single data model.  A module can define a complete, cohesive model,
   or augment an existing data model with additional nodes.

What is the semantic content of "complete, cohesive"?  It seems like
"defines a data model" is shorter and equally accurate.

If I understand Yang correctly, every module defines a data model
(which may have no leafs!), but some also augment other data models.
If that's so, the use of "or" is misleading, and it would be more
accurate to say:

   The module is the base unit of definition in YANG.  A module
   defines a single data model.  A module can also augment an existing
   data model with additional nodes.

Then again, perhaps a module that defines no data nodes cannot be
referenced as a data model.  If so, that should be stated.

--

   Developers of YANG modules and submodules are RECOMMENDED to choose
   names ...

"RECOMMENDED" is an adjective which qualifies the choice, not an
adverb that qualifies the act of choosing.  I think you want
"... SHOULD choose ...".  See RFC 2119.

   A module uses the "include" statement to include all its submodules,
   and the "import" statement to reference external modules.  Similarly,
   a submodule uses the "import" statement to reference other modules.

This tends to confuse the nature of "include" and "import".  I would
prefer:

   A module has an "include" statement for each of its submodules.  A
   module, or submodule belonging to that module, can reference
   definitions in the module and all submodules included by the
   module.

   A module or submodule uses the "import" statement to reference
   external modules.  Statements in the module or submodule can
   reference definitions in the external module using the prefix
   specified in the "import" statement.

--

   For backward compatibility with YANG version 1, a submodule is ...

It's not clear why backward compatibility is needed here, since
yang-version marks each module explicitly with the language version
that is used.

   References to definitions in the local module MAY use the prefix
   notation.

I would add "... using the prefix defined for the module."

- The syntax of colon

Note there are four uses of ":" in the text:

section 5.1

   When a definition in an external module is referenced, a locally
   defined prefix MUST be used, followed by ":", and then the external
   identifier.

section 6.1.2

   A keyword
   is either one of the YANG keywords defined in this document, or a
   prefix identifier, followed by ":", followed by a language extension
   keyword.

section 7.1.4

   When a reference to an identifier from the imported
   module is used, the prefix string for the imported module is used in
   combination with a colon (":") and the identifier, e.g.,
   "if:ifIndex".

section 7.19

   The
   statement's name is created by combining the prefix of the module in
   which the extension was defined, a colon (":"), and the extension's
   keyword, with no interleaving whitespace.

The BNF shows that in all cases, no whitespace is allowed around the
":".  I think that consistent wording should be used in all four
locations to make it clear that whitespace/comments/newlines are not
allowed.  Also "combined with" is unnecessarily inexact, "concatenated
with" or "followed by" is much better.

- section 5.1.1

The beginning of this section should be a discussion of the nature of
revisions abstractly.  AFAICT, an (abstract) module has one or more
revisions, each of which is identified by a distinct revision date.
Each of these is described by one module statement, each of which is
in a separate file.  It seems to be preferred (but seemingly not
required) that a revision of a module will have revision statements
that specify the revision dates of itself and all older revisions in
reverse chronological order -- the actual specification of the
revision date of a module seems to be done externally to the module
statement.

In regard to submodules, it seems that a revision of the module
specifies the revisions of all of its submodules, but a revision of a
submodule only specifies the module's identifier, not its revision.

   When a module is written, it can import the current revisions of
   other modules, based on what is available at the time.

"current" is a dangerous word to use, because it means the narrative
present moment.  You want to say:

   When a module is written, it can import the revisions of other
   modules that are current when the module is written.

--

   When the author of the
   module is prepared to move to the most recently published revision of
   an imported module, the module is republished with an updated
s/the module is republished/the author's module is republished/
   "import" statement.  By republishing with the new revision, the
   authors explicitly indicate their acceptance of any changes in the
s/their acceptance of any changes in/the use of the newer revision of/
   imported module.

Why is "acceptance" being used here?  It has political connotations.
It seems like "use of" carries less baggage.

   For submodules, the issue is related but simpler.  A module or
   submodule that includes submodules needs to specify the revision of
   the included submodules.  If a submodule changes, any module or
   submodule that includes it needs to be updated.

The second sentence is unclear.  I think you mean "In order for a
module or submodule to use definitions in a new revision of a
submodule, the module must be updated to include the new revision of
the referenced submodule."

   If a module is not imported with a specific revision, it is undefined
   which exact revision is used.

Delete "exact" here; it isn't needed and is too informal.  Perhaps
replace with "specific".  (There are other instances of "exact" with
the same issue.)

- section 5.1.2

   YANG allows modeling of data in multiple hierarchies, where data may
   have more than one top-level node.  Models that have multiple top-
   level nodes are sometimes convenient, and are supported by YANG.

Any single module seems to define only one data structure, the one
whose elements are the items listed in the module, and Yang doesn't
seem to provide for any sort of "model" definition other than a
module.  Or are the nodes at the top level within the module all
usable as independent data structures?  I.e., given a module
statement, what is the set of allowed root XML elements for data trees
in its XML namespace?

- section 5.1.2.1

   For example:

     module example-config {
       yang-version 1.1;
       namespace "urn:example:config";
       prefix "co";

       container system { ... }
       container routing { ... }
     }

   could be encoded in NETCONF as:

s/For example/For example, an instance of/

   NETCONF is capable of carrying any XML content as the payload in the
    and  elements.  The top-level nodes of YANG modules
   are encoded as child elements, in any order, within these elements.

This isn't very clear.  AFAICT from the example:

   NETCONF  and  elements each contain sequences of
   instances of top-level nodes of the appropriate YANG module.

Given that this example is about a particular module, it would help if
the module namespace and prefix was used correctly in the XML example.

- section 5.2

   YANG modules and submodules are typically stored in files, one module
   or submodule per file.

This might be clearer as "... one module or submodule statement per
file."

   The name of the file SHOULD be of the form:

     module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )

Does the extension ('.yang' or '.yin') correspond to whether the
contents of the file are in Yang or Yin syntax?

- section 5.3

   All YANG definitions are specified within a module that is bound to a
   particular XML namespace [XML-NAMES], which is a globally unique URI
   [RFC3986].

This doesn't clearly specify the range of "particular" and "unique".
A better phrasing is

   All YANG definitions are specified within a module.  Each module is
   bound to a distinct XML namespace [XML-NAMES], which is a globally
   unique URI [RFC3986].

--

   XML namespaces for private modules are assigned by the organization
   owning the module without a central registry.  Namespace URIs MUST be
   chosen so they cannot collide with standard or other enterprise
   namespaces, for example by using the enterprise or organization name
   in the namespace.

I don't see the use of "without a central registry"; haven't you
already said the module is is private?  (Or is "without a central
registry" a term of art?)

Also, the second sentence is redundant, as you've previously said that
the URI is globally unique, which implies that whoever assigned the
URI has some mechanism for assuring its uniqueness.

- section 5.4

   There is no worry over conflicts if both modules define the
   type, since there is no ambiguity.

I think you mean "There is no ambiguity if both modules define types
with the same name.".

- section 5.5

This section talks a great deal about why scoping is done, but isn't
specifically clear what the rules are.  (Traditionally, the rule is
stated as either what range of source text a particular definition is
visible in, or given an identifier use, how the matching definition is
found.)

   Scoped definitions MUST NOT shadow definitions at a higher scope.  A
   type or grouping cannot be defined if a higher level in the schema
   hierarchy has a definition with a matching identifier.

I think the second sentence is confusing, because (to me) the term
"schema hierarchy" implies the data tree structure, whereas the
scoping rule seems to be intended to be entirely lexical.  In either
case, this needs to be clarified.

- section 5.6

   Conformance is a measure of how accurately a server follows the
   model.

There is no model already under discussion, so you can't use "the
model".  Perhaps

   Conformance to a model is a measure of how accurately a server
   follows a model.

- section 5.6.5

I suspect that if a server implements module A, and A imports B, the
server is not required to implement B.  (Even if A references
groupings in B.)  The answer to that should probably be stated
explicitly.

   If a server lists a module C in the "/modules-state/module" list from
   "ietf-yang-library", and there are other modules Ms listed that
   import C without specifying the revision date of module C, the server
   MUST use the definitions from the most recent revision of C listed
   for modules Ms.

I think the end of that would be clearer as

   ... the server MUST implement Ms by importing the most recent
   revision of C listed in the "/modules-state/module" list.

     module b {
       yang-version 1.1;
       namespace "urn:example:b";
       prefix "b";

       revision 2015-04-04;
       revision 2015-01-01;

       typedef myenum {
         type enumeration {
           enum zero; // added in 2015-01-01
           enum one;  // added in 2015-04-04
         }
       }

       container x {  // added in 2015-01-01
         container y; // added in 2015-04-04
       }
     }

Is this the correct way to specify multiple revisions of this module?
Or is this an informal notation for the two module definitions:

     module b {
       yang-version 1.1;
       namespace "urn:example:b";
       prefix "b";

       revision 2015-04-04;
       revision 2015-01-01;

       typedef myenum {
         type enumeration {
           enum zero; // added in 2015-01-01
           enum one;  // added in 2015-04-04
         }
       }

       container x {  // added in 2015-01-01
         container y; // added in 2015-04-04
       }
     }

     module b {
       yang-version 1.1;
       namespace "urn:example:b";
       prefix "b";

       revision 2015-01-01;

       typedef myenum {
         type enumeration {
           enum zero; // added in 2015-01-01
         }
       }

       container x {  // added in 2015-01-01
       }
     }

If it is the latter, it would help the new reader to explain the
convention (as no example of a multi-revision module is given in the
document).

- section 6

   YANG modules use the UTF-8 [RFC3629] character encoding.

Better to say that YANG modules use the Unicode character set and are
stored in files using the UTF-8 character encoding.

Verify that form-feed (0x0C) is not allowed.

This might be a good place to talk about line-breaks in Yang source
files.  It looks from section 14 that line-breaks MUST be either CRLF
or LF.

It is worth noting (either here or in 6.1.3) how line-breaks inside
quoted strings are transcribed into the string's value.  As now
written, it seems that the line-break is transcribed identically to
how it is represented in the source.  That means (1) If the source is
recoded with the other type of line break, the semantics of the Yang
code change; and (2) if the source uses line-breaks of one type (CRLF
or LF), only that type can be directly transcribed into string values.
(But regardless of the source line-breaks, an LF can be transcribed
into a double-quoted string with "\n".  But a CRLF cannot be
transcribed into a double-quoted string with escape sequences.  Was
that intended, or was "\r" intended to be legal?)

- section 6.1

   This section details the rules for recognizing tokens from an input
   stream.

Generally, language definitions intersperse the narrative text with
the relevant grammar definitions.  Yang's statement grammar is simple
enough that one doesn't need to see the context-free part of the
grammar to understand the narrative for statements.  But when reading
about tokenization, not having the grammar presented at the same time
is quite a burden.  I'd recommend duplicating the relevant productions
from section 14 into the subsections of section 6.

There is some sort of exposition problem.  The result of
"tokenization" is that the sequence of characters of the source is
converted into a sequence of "tokens".  Then some subset of the tokens
is discarded as being non-significant (e.g., whitespace and comments),
and the remainder is parsed with a context-free grammar.  Here I can't
figure out what the set of tokens is.  Looking at the grammar in
section 14, it seems to be a context-free grammar on characters.  But
that implies that there is no separate tokenization phase.

An example that shows the problems:

   mod:ext

Is this one token, which is also an extension keyword, or is it a
sequence of three tokens?

- section 6.1.1

   A block comment is enclosed within "/*" and "*/".

Should say "starts with "/*" and ends with the nearest following
"*/"".

- section 6.1.2

   A token in YANG is either a keyword, a string, a semicolon (";"), or
   braces ("{" or "}").

What is the intention of this sentence?  One interpretation is that it
defines "token" as the union of several other classes.  But that has
the limitation that those classes are not well-defined in this
section.  E.g., what is the syntax of an "unquoted string"?  The other
interpretation is that the Yang file is already separated into
"tokens", and that the set of tokens is further subdivided, with all
tokens that are not keywords, quoted strings, semicolons, or braces
being unquoted strings, whose value is the sequence of characters
within the token.  But the separation into tokens is not described.

"string" is particularly confusing.  In most languages, "string"
values are always quoted in source code.  But it seems that in Yang,
any "token" that isn't a keyword or one of ;, {, }, is automatically
an "unquoted string".  If that's so, it needs to be stated explicitly,
since it's unusual.

- section 6.1.3

   If a string contains any space, tab, or newline characters, a single
   or double quote character, a semicolon (";"), braces ("{" or "}"), or
   comment sequences ("//", "/*", or "*/"), then it MUST be enclosed
   within double or single quotes.

Is a string containing "*/" required to be quoted?  I ask because the
character sequence "*/" is not ambiguous if it is not preceded by "/*"
-- it must be an unquoted string.

   If a double-quoted string contains a line break followed by space or
   tab characters that are used to indent the text according to the
   layout in the YANG file, this leading whitespace is stripped from the
   string, up to and including the column of the double quote character,
   or to the first non-whitespace character, whichever occurs first.  In
   this process, a tab character is treated as 8 space characters.

This description isn't quite careful enough.  Better:

   If a double-quoted string contains a line break followed by space or
   tab characters, an initial part of this whitespace is removed from the
   string.  The amount removed is the longest prefix whose width is no
   larger than the width of the prefix of Yang source line containing
   the opening double quote character of the string to and including the
   opening double quote character.  For this purpose, the width of a
   tab character is 8 and the width of any other character is 1.

This does assume that all tabs are considered to have width 8, that
is, tabs do not have the usual semantics of "advance to the next
column that is divisible by 8".  That will sometimes cause unexpected
results, e.g., if some source lines start with SPC TAB.  (Consider
that whitespace before a line break is removed, which suggests the
intention is that the value of the string should depend only on its
visual appearance.)

Also, we're using the convention that "whitespace" does NOT include CR
or LF, which is not always how the term is used.  Perhaps a definition
of "whitespace" should be put in section 3.

There is also the special case:

   SPC " LF
   TAB x "

Is the initial TAB of the second line to be removed or not?  There is
no whitespace removal in the second line that will exactly reach the
opening double quote.  As I've written it, the TAB is not removed.

   Within a double-quoted string (enclosed within " "), a backslash
   character introduces a special character, which depends on the
   character that immediately follows the backslash:

s/introduces a special character/introduces a representation of a
special character/

Verify that CR cannot be specified by an escape.

   If a quoted string is followed by a plus character ("+"), followed by
   another quoted string, the two strings are concatenated into one
   string, allowing multiple concatenations to build one string.

Are whitespace, line endings, or comments allowed between the quoted
strings and the "+"?  (This description is in the lexical section, so
non-significant lexemes can't be assumed to have been removed.)  (See
also comments on section 14.)

   If a quoted string is followed by a plus character ("+"), followed by
   another quoted string, the two strings are concatenated into one
   string, allowing multiple concatenations to build one string.
   Whitespace trimming is done before substitution of backslash-escaped
   characters in double-quoted strings.  Concatenation is performed as
   the last step.

I think you want to reverse the phrase order in the second sentence:
"In double-quoted strings, whitespace trimming is done before
substitution of backslash-escaped characters."  However, it's not
clear that that matters; only a backslash followed by whitespace would
be affected by whitespace trimming, and whitespace trimming would
leave the backslash followed by CR or LF -- all of those cases are
invalid.

Also, if you keep that second sentence, it should be moved earlier --
the first and third sentences of the paragraph apply to all quoted
strings, but the second sentence only applies to double-quoted
strings, and should be in a paragraph that deals with only
double-quoted strings.

- section 6.1.3.1

   The following examples show some illegal strings:

     ''''  - a single-quoted string cannot contain single quotes
     """   - a double quote must be escaped in a double-quoted string

These shouldn't be described as "illegal" strings; they aren't
strings, truly, but the lexing process doesn't isolate them as tokens,
after which they are decreed to be improper.  The first example is two
single-quoted strings (''), one after the other.  The second is a
double-quoted string (""), followed by the double-quote that starts
another double-quoted string.  Better to say "The following examples
are not string tokens:".

- section 6.2

   Identifiers can be specified as quoted or unquoted strings.

If there is no lexical difference between how identifiers may be
represented and how strings may be represented, and what is an
identifier is distinguished only by the syntactic context, it would be
helpful if that was stated explicitly in section 6.1.  (Though the
characters allowed in identifiers are restricted.)

- section 6.3.1

   The processing of extensions depends on whether support for those
   extensions is claimed for a given YANG parser or the tool set in
   which it is embedded.  An unsupported extension, appearing in a YANG
   module as an unknown-statement (see Section 14) MAY be ignored in its
   entirety.  Any supported extension MUST be processed in accordance
   with the specification governing that extension.

This allows a loophole, where an implementation can not claim support,
but then not ignore the extension.  I think you want to say "An
unsupported extension ... MUST be ignored in its entirety."  (See also
7.20.1, which implies that an unsupported *feature* must be ignored.)
If you really mean "MAY", what are the limits regarding what the
server can do?

- section 6.5

   In an absolute
   schema node identifier, the first identifier after the leading slash
   is any top-level schema node in the local module or in all imported
   modules.

I think "in all imported modules" should be "in an imported module".
(The prefix of the identifier will tell which module.)

- section 7.1

   The module
   name follows the rules for identifiers in Section 6.2.

Why not say "The module name is an identifier."?  Similarly for all
other occurrences of "follows the rules for identifiers".  (I don't
think we hang any semantics on the term "identifier", only syntax.)

- section 7.1.4

See discussion of "prefix" in comments for section 1.1.  I think all
that is needed is to update the second paragraph to:

   When used inside the "module" statement, the "prefix" statement
   defines the prefix suggested to be used when this module is imported.

   To improve readability of the NETCONF XML, a NETCONF client or server
   that generates XML or XPath that use prefixes SHOULD use the prefix
   defined by the module as the XMLNS prefix to associate with the
   module's namespace (which may be impossible if there is a conflict
   with another XMLNS prefix).

The important thing is that the discussion of using the prefix value
as an XMLNS prefix is split into a separate paragraph, so it's clear
that it is a different subject.

   The
   prefix string MAY be used to refer to definitions contained in the
   module, e.g., "if:ifName".

I think this should be qualified "MAY be used within the module to
refer to the definitions contained"; the following paragraph suggests
that a module that imports this module can specify a different prefix
for its references to use, and this prefix will not work in that
module.

- section 7.1.5

   Multiple
   "import" statements may be specified to import from different
   modules.

Is this a requirement that two "import" statements in the same module
MUST import different modules?  If not, the sentence should be shorted
to "Multiple "import" statements may be specified.", or omitted
entirely.  But if a module can't be imported twice, that should
probably be made clearer

   Multiple "import" statements may be specified, but they must import
   from different modules.

- section 7.1.6

   When a module includes a submodule, it incorporates the contents of
   the submodule into the node hierarchy of the module.

What does this mean?  The "include" statement is a top-level statement
within its module, so how is its contents part of the node hierarchy
-- what node is the parent of its nodes?  Perhaps the meaning is that
top-level nodes of the submodule are implicitly top-level nodes of the
module.

- section 7.2

   While the primary unit in YANG is a module, a YANG module can itself
   be constructed out of several submodules.

This doesn't really capture the essence.  What you want to say is

   While the primary unit in YANG is a module, a YANG module can
   include submodules, whose definitions are incorporated into it.

- section 7.5.1

   In the first style, the container has no meaning of its own, existing
   only to contain child nodes.

I think it would be good to add here "In particular, the presence of
the container element with no child elements is semantically
equivalent to the absence of the container element."

- section 7.5.4.3

       must "ifType != 'ethernet' or " +
            "(ifType = 'ethernet' and ifMTU = 1500)" {
	    ...
       }
       must "ifType != 'atm' or " +
            "(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
	    ...

Are these a preferred style?  I ask because it would be shorter to say

       must "ifType != 'ethernet' or ifMTU = 1500" {

       must "ifType != 'atm' or " +
            "(ifMTU <= 17966 and ifMTU >= 64)" {

(Perhaps the ifMTU element is optional, but even then, "and" must
short-circuit for the given expressions to always be valid, so it
seems that "or" must short-circuit.)

- section 7.5.7

I suspect that child elements can be omitted if they're not mandatory,
but their order need not match the order in the schema.

- section 7.6.1

   Note that if the leaf or any of its ancestors has a "when" condition
   or "if-feature" expression that evaluates to "false", then the
   default value is not in use.

ISTM that this is not a "Note that" but rather a precondition of the
analysis of the preceding paragraphs, so it should be moved above
"Otherwise, the usage of the default value...".  (See also the similar
condition in 7.7.2.)

- section 7.6.4

   The default value MUST NOT be marked with an "if-feature" statement.

I think you want "The definition of the default value..." rather than
"The default value...".

But it's not clear what the whole set of situations is that should be
forbidden.  For instance, this should work:

     typedef xyz {
       type enumeration {
	 enum blue { if-feature blue; }
	 ...
       }
     }

     leaf color {
       if-feature blue;
       type xyz;
       default blue;
     }

Whereas this won't:

     typedef xyz {
       type enumeration {
	 enum blue { if-feature blue; }
	 ...
       }
     }

     leaf color {
       // No if-feature here.
       type xyz;
       default blue;
     }

Is this rule only meant to cover the situation where the leaf's type
is an "in-line" enum and the particular enum value has an if-feature?

- section 7.7.1

It might be worth mentioning that duplicated values are allowed and
are significant, since that has changed since Yang 1.  I.e., even in a
system ordered list, the number of list elements with any particular
value must be preserved.

- section 7.7.2

It appears to be assumed that the server's behavior is the same if (1)
a leaf-list node is specified with zero values, and (2) if the
leaf-list node is absent and has no default values.

   Otherwise, if the leaf-list's type has
   a default value, and the leaf-list does not have a "min-elements"
   statement with a value greater than or equal to one, then the leaf-
   list's default value is the type's default value.  In all other
   cases, the leaf-list does not have any default values.

I think it would help to s/the type's default value/one instance of
the type's default value/.

Is the final condition correct?  E.g., if the leaf-list's type has a
default value, and it has a min-elements with value 2, then the
leaf-list has no default values -- which is invalid.

- section 7.7.7.1

   The entries in the list are sorted according to an order determined
   by the system.  The "description" string for the list may suggest an
   order to the server implementor.  If not, an implementation is free
   to sort the entries in the most appropriate order.

This is mealy-mouthed about what is required and what is recommended.
Better would be to omit "If not, an implementation is free to sort the
entries in the most appropriate order."

- section 7.7.7.2

   The entries in the list are sorted according to an order defined by
   the user.  This order is controlled by using special XML attributes
   in the  request.

Actually, the entries aren't "sorted", as there is no requirement that
any particular set of values always has a particular order; the user
can insert 1, 2, 3 at one time, and 3, 2, 1 at another.  The correct
meaning is splicing these two sentences:

   The user orders entries in the list by using special XML attributes
   in the  request.

- section 7.7.8

   The XML elements
   representing leaf-list entries MAY be interleaved with other sibling
   elements, ...

I think it would be more accurate to say "interleaved with elements
for siblings of the leaf-list node".  (See also section 7.8.5.)

- section 7.8

   A list entry is uniquely identified by the values of the list's keys,
   if defined.

What does "if defined" apply to?  Is the point that if keys are not
defined, then list entries have no such uniqueness requirement?  If
the latter, then the text "Each entry ... is uniquely identified by
the values of its key leafs." in section 4.2.2.4 needs to be changed.

- section 7.8.2

   The "key" statement, which MUST be present if the list represents
   configuration, and MAY be present otherwise, takes as an argument a
   string that specifies a space-separated list of leaf identifiers of
   this list.

It would help to change to "list of one or more leaf identifiers"

- section 7.8.3

   The "unique" constraint specifies that the combined values of all the
   leaf instances specified in the argument string, including leafs with
   default values, MUST be unique within all list entry instances in
   which all referenced leafs exist.

Should that sentence end "... within all list entry instances in which
all referenced leafs exist or have default values"?

- section 7.9

   The "choice" statement defines a set of alternatives, only one of
   which may exist at any one time.

Better, "only one of which may be present in any one data tree".

   A choice node does not exist in the data tree.

This is a good phrase and should be applied to list nodes (in that
there is no node for the list, only for each list element).

   A choice consists of a number of branches, defined with the "case"
   substatement.

Better, "each defined with a "case" substatement".

   As a shorthand, the "case" statement can be omitted if the branch
   contains a single "anydata", "anyxml", "choice", "container", "leaf",
   "list", or "leaf-list" statement.  In this case, the case node still
   exists in the schema tree, and its identifier is the same as the
   identifier in the branch statement.

There is no "branch" statement...  How about:

   As a shorthand, the "case" statement can be replaced by just the
   statement for the child node if the branch contains a single
   "anydata", "anyxml", "choice", "container", "leaf", "list", or
   "leaf-list" statement.  In this case, the case node still exists in
   the schema tree, and its identifier is the same as the identifier
   of the child node.

- section 7.9.3

   The argument is the identifier of the "case" statement.

Better, "The argument is the identifier of the default "case"
statement."

- section 7.9.5.  XML Encoding Rules

   The choice and case nodes are not visible in XML.

Use this sort of statement for lists and leaf-lists, which have no
visible XML for the lists as a whole.

- section 7.10

   The "anydata" statement is used to represent an unknown set of nodes
   that can be modelled with YANG, except anyxml, ...

What is the practical consequence of this restriction?  It's not at
all clear to me which chunks of XML could be modelled with Yang and
which could not.

- section 7.12

   A grouping is like a "structure" or a "record" in conventional
   programming languages.

Add, "... though no grouping node exists in the XML."

- section 7.15

   The "action" statement is used to define an operation connected to a
   specific container or list data node.

Might it be better to say "list element data node"?  What isn't being
said explicitly is that an action that appears in a list statement is
an action on a single element of the list, rather than an action on
the list as a whole.  Similarly for notifications, section 7.16.

- section 7.15.2

   The last container or list contains an XML element that ...

Would "innermost" be better than "last"?

- section 7.17

   The "augment" statement allows a module or submodule to add to >a<
   schema tree defined in an external module, or >in< the current module and
   its submodules, and to add to the nodes from a grouping in a "uses"
   statement.

I think adding "in" where indicated makes the sentence clearer.

I've changed a "the" is changed to an "a" where indicated.  The
question is whether the module defines a schema tree or a schema
forest, a set of trees.  That depends on whether each top-level node
can be used independently as the root of a data tree or whether they
have to be used together.  See comments on section 5.1.2.

- section 7.18

It would help to insert a discussion of the global purpose and use of
identities.  In particular, what things can refer to them?  It looks
like only identityref leafs can do so, but I could easily be wrong.
Also, more discussion in the example (7.18.3) would be helpful.

   The "identity" statement is used to define a new globally unique,
   abstract, and untyped identity.  Its only purpose is to denote its
   name, semantics, and existence.

The two uses of "its" in the second sentence are ambiguous.  I think
you mean "The statement's only purpose is to denote the identity's
name, semantics, and existence."  Though I'm not sure that an identity
has any semantics beyond its existence and base identities.

- section 7.19

   The statement's argument is an identifier that is the new keyword for
   the extension and must be followed by a block of substatements that
   holds detailed extension information.

s/The statement's/The "extension" statement's/ -- this talks about the
"extension" statement that defines the extension statement [sic!].

- section 7.20.2.1

   In this example, the container "target" is implemented if any of the
   features "outbound-tls" or "outbound-ssh" are supported by the
   server.

"either" is better than "any" if there are only two choices.

- section 7.21.4

   The "reference" statement takes as an argument a string ...

Perhaps s/a string/a human-readable string/.

- section 7.21.5

Note that if a data definition has both an "if-feature" and a "when",
then the "if-feature" is tested first.

   If the XPath expression references any node that also has associated
   "when" statements, these "when" expressions MUST be evaluated first.
   There MUST NOT be any circular dependencies in these "when"
   expressions.

I think this could be better phrased:

   If the XPath expression references any node that also has
   associated "when" statements, then the "when" expressions of the
   referenced nodes MUST be evaluated first.  There MUST NOT be any
   circular dependencies among "when" expressions.

- section 9.3.4

Can one apply a fraction-digits restriction to a derived type that
already has a fraction-digits restriction?  ISTM that this is sensible
if the fraction-digits numbers of the two restrictions are the same.
Then again, that would be pointless, and we might want to forbid
fraction-digits re-restrictions.

The fraction-digits statement doesn't seem to have any of the
substatements (e.g., description, error-app-tag) that other
restrictions (e.g., length, pattern, range) do.  (The grammar in
section 14. agrees.)  Is this OK?  It seems like a value could fail to
conform to fraction-digits.

- section 9.6.3

   An enumeration can be restricted with the "enum" (Section 9.6.4)
   statement.

This should be fleshed out:  "... can be restricted with one or more
"enum" (Section 9.6.4) statements, which enumerate a subset of the
values of the base type."

- section 9.7.2

   The lexical representation of the bits type is a space-separated list
   of the individual bit values that are set.

I think that should be "... list of the names of the bits that are
set."  I tend to think of a "bit value" as 0 or 1.

- section 9.8.3

   The canonical form of a binary value follows the rules in [RFC4648].

Best specify "the rules of 'Base 64 Encoding' in [RFC4648]."

- section 9.9

   The leafref type is used to declare a constraint on the value space
   of a leaf, based on a reference to a set of leaf instances in the
   data tree.  The "path" substatement (Section 9.9.2) selects a set of
   leaf instances, and the leafref value space is the set of values of
   these leaf instances.

The first sentence isn't quite right.  Perhaps:

   The value space of a leaf with leafref type is one of the values of
   a set of leaf instances in the data tree.  The "path" substatement
   (Section 9.9.2) selects the set of leaf instances, and the leafref
   value space is the set of values of these leaf instances.

- section 9.9.3

   If "require-instance" is "true", it means that the instance being
   referred MUST exist for the data to be valid.  This constraint is
   enforced according to the rules in Section 8.

   If "require-instance" is "false", it means that the instance being
   referred MAY exist in valid data.

What does "the instance being referred" mean?  Perhaps you meant "the
instance being referred to"?

Also, I think the second paragraph means that if require-instance is
false, the referred-to instance need not exist.  But it's not clear to
me what that would mean -- if there are no instances referenced by the
XPath expression, then the set of value values of the leafref would be
empty and the leafref would necessarily be invalid. ...  I think these
paragraphs need to be expanded in some way.

(require-instance is also used in instance-identifier, which may have
subtly different semantics than when it is used in leafref.)

- section 9.9.4.  Lexical Representation

   A leafref value is lexically represented the same way as the leaf it
   references.

Probably better as "... the same way as the leaf it references
represents its value."

- section 9.12

   It is used to repeatedly specify each member type of the
   union.

I think you want "It is used repeatedly to specify ..." --
"repeatedly" modifies "used", not "specify".

   In the XML encoding, a value representing a union data type is
   validated consecutively against each member type, in the order they
   are specified in the "type" statement, until a match is found.  The
   type that matched will be the type of the value for the node that was
   validated.

I think a distinction needs to be made here between generating XML and
interpreting XML:

   When generating an XML encoding, a value is encoded according to
   the rules of the member type to which the value belongs.  When
   interpreting an XML encoding, a value is validated consecutively
   against each member type, in the order they are specified in the
   "type" statement, until a match is found.  The type that matched
   will be the type of the value for the node that was validated, and
   the encoding is interpreted according to the rules for that type.

- section 10.3.1

   If the first argument node is of type leafref, the function returns a
   node set that contains the nodes that the leafref refers to.

I *think* that this means the set of nodes that the leafref's XPath
selects, but a plausible alternative is the subset of those nodes
which have the same value as the leafref does.  This hinges on the
meaning of "the leafref refers to a node", which isn't defined
unambiguously in section 9.9.

- section 11

   o  A "description" statement may be added or clarified without
      changing the semantics of the definition.

Probably better to change "clarified" to "changed".  (What is the
specificational content of "clarified"?)

   o  A "type" statement may be replaced with another "type" statement
      that does not change the syntax or semantics of the type.  For
      example, an inline type definition may be replaced with a typedef,
      but an int8 type cannot be replaced by an int16, since the syntax
      would change.

Is the last sentence correct?  Any value that was previously valid
would remain valid.  This is similar to changing "range '-128..127'"
to "range '-32768..32767'".

- section 13

   The translated module is called a YIN module.  This
   section describes symmetric mapping rules between the two formats.

I don't think "symmetric" is the right word; perhaps "bidirectional".

- section 14

   This grammar assumes that the scanner replaces YANG comments with a
   single space character.

It would probably be better to explicitly include comments in the
separator nonterminals:

   ;; 'comment' is specified in Section 6.1.1

   sep                 = 1*(WSP / line-break / comment)
                         ; unconditional separator

   optsep              = *(WSP / line-break / comment)

   stmtsep             = *(WSP / line-break / comment / unknown-statement)

--

   module-stmt         = optsep module-keyword sep identifier-arg-str
   		       	 ...

This has the consequence that 'module"name"{...' is invalid, because
there is no separator after 'module', even though traditional
tokenizers would handle it.  Verify that this is intended.  (This
pattern is consistent for all statement types.)

   linkage-stmts       = ;; these stmts can appear in any order
                         *import-stmt
                         *include-stmt

This could easily be handled like body-stmts:

   linkage-stmts       = *(import-stmt /
                           include-stmt)

--

   if-feature-expr     = "(" if-feature-expr ")" /
                         if-feature-expr sep boolean-operator sep
                           if-feature-expr /
                         not-keyword sep if-feature-expr /
                         identifier-ref-arg

This should probably be marked ";; precedence rules specified in
Section 7.20.2", as the grammar is ambiguous and does not specify the
precedence, whereas typical programming language grammars encode the
precedence rules.

   instance-identifier-specification =
                         [require-instance-stmt]

Why is require-instance-stmt in [...]?  The only use of
instance-identifier-specification is in type-body-stmts, and the only
use of type-body-stmts is in type-stmt, where it is in [...].  Compare
with numerical-restrictions:

   numerical-restrictions = range-stmt

--

   binary-specification = [length-stmt]

Similarly.

   quoted-string       = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)

   string              = < an unquoted string as returned by >
                         < the scanner, that matches the rule >
                         < yang-string >

The handling of "string" is hard to follow and/or inexact.  First, we
need a term for the "value" of a string written in Yang source, so we
can say

   prefix-arg-str      = < a string whose ??? matches the rule >
                         < prefix-arg >

The text that is now used is not too difficult to understand, but it's
inexact and makes it hard to write specifications about how the value
is determined.

(Also, there seem to be too many <...>, dividing the narrative text
into two parts.  The natural way to write it would be:

   prefix-arg-str      = < a string whose ??? matches the rule
                           prefix-arg >

But it might not be worth the effort to change the use of <...>
throughout section 14.)

We need a production that tells exactly the syntax of "an unquoted
string as return by the scanner".

We also need productions for quoted strings.  I can reconstruct these:

   quoted-string       = (single-quoted-string / double-quoted-string)
   		         *(optsep "+" optsep
                             (single-quoted-string / double-quoted-string))

   single-quoted-string = SQUOTE *(yang-char excluding "'") SQUOTE

(I don't know a good way to exclude one character from a character set
in ABNF.)

   double-quoted-string = DQUOTE *dq-char DQUOTE

   dq-char = yang-char excluding BACKSLASH and DQUOTE /
             BACKSLASH ( "n" / "t" / DQUOTE / BACKSLASH )

Verify that "optsep" is what is allowed to appear around "+".

Needs a comment pointing to Section 6.1.3 as telling how to interpret
quoted-strings.

[END]


From nobody Fri May 13 07:04:40 2016
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 EBBA612D534; Fri, 13 May 2016 07:04:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160513140439.10628.19471.idtracker@ietfa.amsl.com>
Date: Fri, 13 May 2016 07:04:39 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-entity-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 May 2016 14:04:40 -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 Entity Management
        Authors         : Andy Bierman
                          Martin Bjorklund
                          Jie Dong
                          Dan Romascanu
	Filename        : draft-ietf-netmod-entity-00.txt
	Pages           : 36
	Date            : 2016-05-13

Abstract:
   This document defines a YANG data model for the management of
   multiple physical entities managed by a single server.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-entity-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 May 17 08:00:31 2016
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 46AB712D6E3 for ; Tue, 17 May 2016 08:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level: 
X-Spam-Status: No, score=-15.947 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=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 ViLYqZ2P3FLG for ; Tue, 17 May 2016 08:00:26 -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 EA19F12D95E for ; Tue, 17 May 2016 07:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67538; q=dns/txt; s=iport; t=1463496856; x=1464706456; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=uGUAx5oF0NMqSjxWtLChXLFMi31t5QiuyfQWvpjMOgA=; b=fGdmA/LEpL4nEVhRIgOH58b5sp94UKDXsXWFQhXcuR6dLYiaov/IH5Xq pc1QZunaKMvJdQvXuyeJjy8N+gj0GU5WqPwneZfGfk4ISqjenL+8CgOBD C8lsE6stNvYT4Rk1kc4Tv6mTJjMvMMFkDpFkZjxahaw47EUoTumSnuMnJ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBAAjMDtX/xbLJq1SAQMGhAx+u3IEF?= =?us-ascii?q?wuFJUoCggIBAQEBAQFmJ4RDAQEDAQEBAQsMAR0tAgcEBgYLCxQNFg8JAwIBAgE?= =?us-ascii?q?VMAYBDAQCAgEBFQKIDAgOxGYBAQEBAQEBAwEBAQEBAQEBAR6GJYNKgQOEFwERC?= =?us-ascii?q?A6FWQEEhXCCEIVfhTyFDoV/gniCXw6CO4FpToQBgwcje4Q8hRWBGYkUYoIGHIF?= =?us-ascii?q?NOgMvAYZJJYEXAQEB?=
X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="637510188"
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; 17 May 2016 14:54:11 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4HEsBmZ005269; Tue, 17 May 2016 14:54:11 GMT
To: "Dale R. Worley" , netmod@ietf.org, Martin Bjorklund 
References: <877feyrdz9.fsf@hobgoblin.ariadne.com>
From: Benoit Claise 
Message-ID: <573B3092.9010102@cisco.com>
Date: Tue, 17 May 2016 16:54:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <877feyrdz9.fsf@hobgoblin.ariadne.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 15:00:30 -0000

Martin, al.,

Please engage in the discussion/resolution, even before the telechat 
(this Thursday).

Regards, Benoit


> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-netmod-rfc6020bis-12
> Reviewer: Dale R. Worley
> Review Date: 2016-05-12
> IETF LC End Date: 2016-05-12
> IESG Telechat date: 2016-05-19
>
> Summary: This draft is basically ready for publication, but has nits
> that should be fixed before publication.  I have a large number of
> editorial comments.  A few of these comments address technical
> uncertainties, but I strongly suspect that the technical issues have
> long since been fixed, as this is a revision of Yang 1, and the
> only needed work is clarifying the text.
>
> - Abstract
>
> This Abstract does not list what the document does.  E.g., define Yang
> 1.1.  Also might help to mention upward-incompatibility.  Basically,
> go through section 1 to see what should be in Abstract.  Perhaps:
>
>     YANG is a data modeling language originally designed to model
>     configuration and state data manipulated by the Network
>     Configuration Protocol (NETCONF), NETCONF remote procedure calls,
>     and NETCONF notifications.  This document describes the syntax and
>     semantics of version 1.1 of the YANG language.  YANG version 1.1 is
>     a maintenance release of the YANG language, addressing ambiguities
>     and defects in the original specification.  There are a small
>     number of upward-incompatibilities from Yang 1.  This document also
>     describes how a data model defined in a YANG module is encoded in
>     the Extensible Markup Language (XML), and how NETCONF operations
>     are used to manipulate the data.
>
> - section 1.1
>
> The incompatibilities should be marked whether the old, incompatible
> usage always causes an error "at compile time", "at run time", or
> changed behavior.
>
> A number of later items seem to be upward-incompatibilities but not
> marked as such:
>
>     o  Made the "yang-version" statement mandatory.
>
>     o  Made noncharacters illegal in the built-in type "string".
>
> - section 3
>
>     o  identifier: Used to identify different kinds of YANG items by
>        name.
>
> This item, unlike the others, does not start with a noun phrase.
> Perhaps, "A string used to ..."?
>
>     o  leaf: A data node that exists in at most one instance in the data
>        tree.  A leaf has a value but no child nodes.
>
> I'm not sure that this is correct; a leaf schema node inside a list
> schema node can have many instances in a data tree.  The real
> criterion is that it has a value but no child nodes.
>
>     o  leaf-list: Like the leaf node but defines a set of uniquely
>        identifiable nodes rather than a single node.  Each node has a
>        value but no child nodes.
>
> Better to say a "sequence of nodes".  Without the concept that the
> nodes are a sequence (and can be identified by location within the
> sequence), there's no assurance that the nodes are uniquely
> identifiable (since they can have duplicate values in state data).
>
>     o  mandatory node: A mandatory node is one of:
>        ...
>        *  A container node without a "presence" statement, which has at
>           least one mandatory node as a child.
>
> Perhaps replace the comma with "and"?
>
> It would be useful to insert a note somewhere that all data is either
> "configuration" or "state" data.  It's hard to learn that now, because
> the terms "configuration data" and "state data" are defined only by
> reference to RFC 6241.
>
> There are general issues with the terms "namespace" and "prefix".
>
> "namespace" is used to identify both the namespaces of identifiers in
> Yang source (6.2.1) as well as XML namespaces in the XML encodings of
> data trees.  It would make things clearer if all uses that refer to
> XML namespaces used the form "XML namespace".
>
> "prefix" is used to name both identifier prefixes in Yang source code
> and XMLNS prefixes.  Worse, the prefix statement is used to declare
> one string, which is then both the prefix used within the Yang source
> code and also the preferred (but not mandatory!) XMLNS prefix used to
> refer to the associated XML namespace.  It would help if "XMLNS
> prefix" was used whenever talking specifically about prefixes used in
> XML.  See also comments on section 7.1.4.
>
> - section 3.1
>
> There is an overall question regarding whitespace in XML in
> "non-significant" places.  Is it allowed in the XML representation of
> data trees?  And if so, precisely what whitespace is allowed?  Also,
> to what degree is the whitespace shown in examples what is allowed on
> the wire, and to what degree is it there just to make the example
> easier to read?  (It's possible that XML has implemented some sort of
> global solution for the issue of non-significant whitespace, but back
> when I was using it regularly, there was none.)
>
> - section 4.1
>
>     YANG structures data models into modules and submodules.  A module
>     can import data from other external modules, and include data from
>     submodules.
>
> "data" has other meanings.  Perhaps change to "elements of models" or
> "definitions"?
>
>     The instantiation of these groupings can refine or augment the
>     nodes, allowing it to tailor the nodes to its particular needs.
>
> "instantiate" is used with two meanings, the more common one being
> the relationship between nodes and data tree elements, and the
> insertion of a grouping into a node tree.  E.g., see the definitions
> of "data tree" and "uses" in section 3.  It would make life easier if
> there was a different word for the second meaning -- perhaps "use"?
> In any case, this particular sentence has no context to disambiguate
> the two meanings.
>
>     The conversion from YANG to
>     YIN is lossless, so content in YIN can be round-tripped back into
>     YANG.
>
> This is almost certainly not true.  But there is no loss of Yang
> semantics, or something like that, and that could be stated.
>
>     YANG strikes a balance between high-level data modeling and low-level
>     bits-on-the-wire encoding.  The reader of a YANG module can see the
>     high-level view of the data model while understanding how the data
>     will be encoded on-the-wire.
>
> Is that true in cases where the NETCONF XML wire encoding is not used?
> Or is that encoding mandatory in some sense, even if the environment
> is not NETCONF?  If Yang is intended to describe data which will
> *always* be expressed in XML in a certain way, that fact should be
> introduced earlier in the document.
>
> - section 4.2.1
>
> Section should start with a definition of "module" and what modules
> are used for.  The current text is a list of details about "module"
> without telling what the *point* of a module is.
>
>     A module may be divided into submodules, based on the needs of the
>     module owner.
>
> There is a global problem that the reader needs to know the
> relationships between "module" and "submodule", but those are not
> stated explicitly anywhere.  (This is probably a candidate for
> inclusion in section 3.)  AFAICT:
>
>      A module
>      - is defined by a module statement in its own file
>      - defines a group of data trees, etc. that can be used by NETCONF
>      - "includes" the submodules that "belong to" it
>
>      A submodule
>      - is defined by a submodule statement in its own file
>      - defines things that can be used in the module statement
>      - "belongs to" a single module, which is specified in the "belongs-to"
>        substatement of the submodule statement
>      - does NOT have submodules of its own
>
> "module owner" is not defined in section 3.  And is it the right term;
> is there an ownership relationship, or does this just mean "whoever
> wrote the module"?  Or is there an understood social context in which
> a module will be written that needs to be paid attention to in this
> document?  (E.g., regarding allocation of XML namespaces.)
>
> There is also the risk of misunderstanding between "own" and "belong
> to" -- a submodule "belongs to" its module but the module doesn't
> "own" the submodule.
>
> Also, the module isn't "divided" into submodules, since there is
> always a module statement.
>
> Perhaps a better version of this paragraph is:
>
>     A module may have portions of its definition separated into
>     submodules, based on the needs of the module writer.  This
>     separation is not visible outside the text of the module and
>     submodules; neither importation into other modules nor the data
>     encodings are affected.
>
> --
>
>     The "import" statement allows a module or submodule to reference
>     material defined in other modules.
>
> There is no definition of "material".  Clearly, it means "things that
> can be referenced", but this points out that there is no term for
> "things that can be referenced", but it would be useful to have one.
> Then one could state, e.g., that a module can reference ???s defined
> in its submodules, or it can reference ???s defined in modules that it
> imports.
>
>     The "include" statement is used by a module to incorporate the
>     contents of its submodules into the module.
>
> In a sense, "include" isn't really like "import", because it's not
> optional; it's the mandatory reverse-link of the "belongs-to"
> statement in the submodule.  (The module and all submodules
> automatically have access to definitions in all submodules due to
> their relationship.)
>
> And that has been the cause of a lot of my confusion on this topic;
> "include" and "import" are discussed together in many places, making
> it unclear that "a module includes a submodule" is really a *static*
> relationship, not a statement that the programmer could insert or not
> according to need.  A clearer statement would be:
>
>     The "include" statement is used in a module to identify each
>     submodule that belongs to it.  The module's definitions have access
>     to the definitions in the submodule.
>
> It might be useful to define "include" and "belong to" in section 3.
>
> - section 4.2.2.1
>
>       leaf host-name {
>         type string;
>         description
>           "Hostname for this system";
>       }
>
> It might be useful here to provide a forward reference to 6.3 as a
> reference for the syntax of statements.  If you don't already know the
> syntax, it can be hard to figure out that "host-name" is the node's
> identifier.  Or perhaps the forward reference could be put at the end
> of 4.2.2.
>
> - section 4.2.2.3
>
>     A container may contain any number of child nodes of any type
>     (leafs, lists, containers, leaf- lists, actions, and
>     notifications).
>
> If the plural of "leaf" is "leafs" (rather than the standard English
> "leaves"), that should be noted in the entry in section 3.
>
> - section 4.2.2.4
>
>     A list defines a sequence of list entries.  Each entry is like a
>     structure or a record instance, and is uniquely identified by the
>     values of its key leafs.  A list can define multiple key leafs and
>     may contain any number of child nodes of any type (including leafs,
>     lists, containers etc.).
>
> Each entry is like a *container*, which was just defined above, which
> might be a more intuitive way to describe it.
>
> Perhaps "... is uniquely identified by the values of one or more
> specified leaf children, the key leafs."
>
>     XML Encoding Example:
>
>       
>         glocks
>         Goldie Locks
>         intruder
>       
>       
>         snowey
>         Snow White
>         free-loader
>       
>       
>         rzell
>         Rapun Zell
>         tower
>       
>
> I note that this example, unlike the previous ones, is not a single
> XML element; there is no XML element that designates the list as a
> whole.  That seems to be a general pattern in the XML encodings for
> Yang, that groups of elements can be defined in Yang, but the
> resulting set of elements is not wrapped in a single element in the
> XML.  That happens with lists (where each list element is an element
> but the list as a whole is not), leaf-list (where there is no element
> surrounding the repeated leaf element), groupings, and choices with
> their child cases.  Perhaps this is a general pattern in XML used for
> network management, but it's not quite what one would expect if one
> thinks of data structures in a programming language.  Perhaps it would
> be helpful to point out this pattern somewhere that global XML issues
> are described (e.g., whitespace issues).
>
> - section 4.2.3
>
>     YANG can model state data, as well as configuration data, based on
>     the "config" statement.  When a node is tagged with "config false",
>     its subhierarchy is flagged as state data.  In NETCONF, state data is
>     reported using the  operation, not the  operation.
>     Parent containers, lists, and key leafs are reported also, giving the
>     context for the state data.
>
> Does this mean that  returns the state data and 
> returns the configuration data?  Or does  return both the state
> and configuration data?  Perhaps this is not really a question for
> this document, but if the behavior of  and  is
> mentioned, they should be described thoroughly.
>
> - section 4.2.4
>
>     YANG has a set of built-in types, similar to those of many
>     programming languages, but with some differences due to special
>     requirements from the management domain.
>
> "from the management domain" is awkward, and "domain" has no previous
> definition; better "requirements of network management".
>
>         | enumeration         | Enumerated strings                  |
>
> Perhaps "one of an enumerated set of strings".
>
>         | string              | Human-readable string               |
>
> What does "human-readable" mean?  Can passwords be stored in such
> leafs?  Does this really mean "a string of Unicode characters"?
> Perhaps "character string" would be better.
>
> - section 4.2.7
>
>     YANG allows the data model to segregate incompatible nodes into
>     distinct choices using the "choice" and "case" statements.  The
>     "choice" statement contains a set of "case" statements that define
>     sets of schema nodes that cannot appear together.  Each "case" may
>     contain multiple nodes, but each node may appear in only one "case"
>     under a "choice".
>
>     When a node from one case is created in the data tree, all nodes from
>     all other cases are implicitly deleted.  The server handles the
>     enforcement of the constraint, preventing incompatibilities from
>     existing in the configuration.
>
>     The choice and case nodes appear only in the schema tree but not in
>     the data tree.  The additional levels of hierarchy are not needed
>     beyond the conceptual schema.
>
> This description reads very oddly.  AFAICT, "choice" simply defines a
> union type, where each alternative is a container (usually called a
> structure or record).  Or rather, it's conceptually a container, but
> in an XML instance of data, there is no start-end tags for the
> structure as a whole (paralleling the lack of start-end tags for lists
> as a whole).  Once you state that, it's clear why there are "sets of
> schema nodes that cannot appear together".
>
> - section 4.2.8
>
> It would help to give a general discussion of augmenting.  If one
> module augments another, is the augmented data definition part of the
> data structures defined by augmenting module or the augmented one?
>
> If I've got it right, this module:
>
>     module /system/login/user {
>       namespace "urn:user";
>       prefix "user";
>
>       list user {
>         key "name";
>         leaf name {
>           type string;
>         }
>         leaf full-name {
>           type string;
>         }
>         leaf class {
>           type string;
>         }
>       }
>     }
>
> gives this as the XML encoding of a typical data tree:
>
>       
>         alicew
>         Alice N. Wonderland
>         drop-out
>         1024
>       
>
> whereas the *existence* (in some sense) of this module:
>
>     module /system/login/user-augmenter {
>       namespace "urn:user-extension";
>       prefix "ext";
>
>       augment /system/login/user {
>         when "class != 'wheel'";
>         leaf uid {
>           type uint16 {
>             range "1000 .. 30000";
>           }
>         }
>       }
>     }
>
> changes the encoding of the data tree to:
>
>       
>         alicew
>         Alice N. Wonderland
>         drop-out
>         1024
>       
>
> What is it that triggers this action-at-a-distance?
>
>     If a module augments another module, the XML encoding of the data
>     will reflect the prefix of the augmenting module.  For example, if
>     the above augmentation were in a module with prefix "other", the XML
>     would look like:
>
> This is hard to interpret.  Better would be:
>
>     If a module augments another module, the XML elements that are
>     added to the encoding are in the namespace of the augmenting module
>     (which should preferentially be associated with the prefix of the
>     augmenting module).
>
> The restriction is on the XML namespace of the new element, not its
> XMLNS prefix.
>
> - section 5.1
>
>     The module is the base unit of definition in YANG.  A module defines
>     a single data model.  A module can define a complete, cohesive model,
>     or augment an existing data model with additional nodes.
>
> What is the semantic content of "complete, cohesive"?  It seems like
> "defines a data model" is shorter and equally accurate.
>
> If I understand Yang correctly, every module defines a data model
> (which may have no leafs!), but some also augment other data models.
> If that's so, the use of "or" is misleading, and it would be more
> accurate to say:
>
>     The module is the base unit of definition in YANG.  A module
>     defines a single data model.  A module can also augment an existing
>     data model with additional nodes.
>
> Then again, perhaps a module that defines no data nodes cannot be
> referenced as a data model.  If so, that should be stated.
>
> --
>
>     Developers of YANG modules and submodules are RECOMMENDED to choose
>     names ...
>
> "RECOMMENDED" is an adjective which qualifies the choice, not an
> adverb that qualifies the act of choosing.  I think you want
> "... SHOULD choose ...".  See RFC 2119.
>
>     A module uses the "include" statement to include all its submodules,
>     and the "import" statement to reference external modules.  Similarly,
>     a submodule uses the "import" statement to reference other modules.
>
> This tends to confuse the nature of "include" and "import".  I would
> prefer:
>
>     A module has an "include" statement for each of its submodules.  A
>     module, or submodule belonging to that module, can reference
>     definitions in the module and all submodules included by the
>     module.
>
>     A module or submodule uses the "import" statement to reference
>     external modules.  Statements in the module or submodule can
>     reference definitions in the external module using the prefix
>     specified in the "import" statement.
>
> --
>
>     For backward compatibility with YANG version 1, a submodule is ...
>
> It's not clear why backward compatibility is needed here, since
> yang-version marks each module explicitly with the language version
> that is used.
>
>     References to definitions in the local module MAY use the prefix
>     notation.
>
> I would add "... using the prefix defined for the module."
>
> - The syntax of colon
>
> Note there are four uses of ":" in the text:
>
> section 5.1
>
>     When a definition in an external module is referenced, a locally
>     defined prefix MUST be used, followed by ":", and then the external
>     identifier.
>
> section 6.1.2
>
>     A keyword
>     is either one of the YANG keywords defined in this document, or a
>     prefix identifier, followed by ":", followed by a language extension
>     keyword.
>
> section 7.1.4
>
>     When a reference to an identifier from the imported
>     module is used, the prefix string for the imported module is used in
>     combination with a colon (":") and the identifier, e.g.,
>     "if:ifIndex".
>
> section 7.19
>
>     The
>     statement's name is created by combining the prefix of the module in
>     which the extension was defined, a colon (":"), and the extension's
>     keyword, with no interleaving whitespace.
>
> The BNF shows that in all cases, no whitespace is allowed around the
> ":".  I think that consistent wording should be used in all four
> locations to make it clear that whitespace/comments/newlines are not
> allowed.  Also "combined with" is unnecessarily inexact, "concatenated
> with" or "followed by" is much better.
>
> - section 5.1.1
>
> The beginning of this section should be a discussion of the nature of
> revisions abstractly.  AFAICT, an (abstract) module has one or more
> revisions, each of which is identified by a distinct revision date.
> Each of these is described by one module statement, each of which is
> in a separate file.  It seems to be preferred (but seemingly not
> required) that a revision of a module will have revision statements
> that specify the revision dates of itself and all older revisions in
> reverse chronological order -- the actual specification of the
> revision date of a module seems to be done externally to the module
> statement.
>
> In regard to submodules, it seems that a revision of the module
> specifies the revisions of all of its submodules, but a revision of a
> submodule only specifies the module's identifier, not its revision.
>
>     When a module is written, it can import the current revisions of
>     other modules, based on what is available at the time.
>
> "current" is a dangerous word to use, because it means the narrative
> present moment.  You want to say:
>
>     When a module is written, it can import the revisions of other
>     modules that are current when the module is written.
>
> --
>
>     When the author of the
>     module is prepared to move to the most recently published revision of
>     an imported module, the module is republished with an updated
> s/the module is republished/the author's module is republished/
>     "import" statement.  By republishing with the new revision, the
>     authors explicitly indicate their acceptance of any changes in the
> s/their acceptance of any changes in/the use of the newer revision of/
>     imported module.
>
> Why is "acceptance" being used here?  It has political connotations.
> It seems like "use of" carries less baggage.
>
>     For submodules, the issue is related but simpler.  A module or
>     submodule that includes submodules needs to specify the revision of
>     the included submodules.  If a submodule changes, any module or
>     submodule that includes it needs to be updated.
>
> The second sentence is unclear.  I think you mean "In order for a
> module or submodule to use definitions in a new revision of a
> submodule, the module must be updated to include the new revision of
> the referenced submodule."
>
>     If a module is not imported with a specific revision, it is undefined
>     which exact revision is used.
>
> Delete "exact" here; it isn't needed and is too informal.  Perhaps
> replace with "specific".  (There are other instances of "exact" with
> the same issue.)
>
> - section 5.1.2
>
>     YANG allows modeling of data in multiple hierarchies, where data may
>     have more than one top-level node.  Models that have multiple top-
>     level nodes are sometimes convenient, and are supported by YANG.
>
> Any single module seems to define only one data structure, the one
> whose elements are the items listed in the module, and Yang doesn't
> seem to provide for any sort of "model" definition other than a
> module.  Or are the nodes at the top level within the module all
> usable as independent data structures?  I.e., given a module
> statement, what is the set of allowed root XML elements for data trees
> in its XML namespace?
>
> - section 5.1.2.1
>
>     For example:
>
>       module example-config {
>         yang-version 1.1;
>         namespace "urn:example:config";
>         prefix "co";
>
>         container system { ... }
>         container routing { ... }
>       }
>
>     could be encoded in NETCONF as:
>
> s/For example/For example, an instance of/
>
>     NETCONF is capable of carrying any XML content as the payload in the
>      and  elements.  The top-level nodes of YANG modules
>     are encoded as child elements, in any order, within these elements.
>
> This isn't very clear.  AFAICT from the example:
>
>     NETCONF  and  elements each contain sequences of
>     instances of top-level nodes of the appropriate YANG module.
>
> Given that this example is about a particular module, it would help if
> the module namespace and prefix was used correctly in the XML example.
>
> - section 5.2
>
>     YANG modules and submodules are typically stored in files, one module
>     or submodule per file.
>
> This might be clearer as "... one module or submodule statement per
> file."
>
>     The name of the file SHOULD be of the form:
>
>       module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
>
> Does the extension ('.yang' or '.yin') correspond to whether the
> contents of the file are in Yang or Yin syntax?
>
> - section 5.3
>
>     All YANG definitions are specified within a module that is bound to a
>     particular XML namespace [XML-NAMES], which is a globally unique URI
>     [RFC3986].
>
> This doesn't clearly specify the range of "particular" and "unique".
> A better phrasing is
>
>     All YANG definitions are specified within a module.  Each module is
>     bound to a distinct XML namespace [XML-NAMES], which is a globally
>     unique URI [RFC3986].
>
> --
>
>     XML namespaces for private modules are assigned by the organization
>     owning the module without a central registry.  Namespace URIs MUST be
>     chosen so they cannot collide with standard or other enterprise
>     namespaces, for example by using the enterprise or organization name
>     in the namespace.
>
> I don't see the use of "without a central registry"; haven't you
> already said the module is is private?  (Or is "without a central
> registry" a term of art?)
>
> Also, the second sentence is redundant, as you've previously said that
> the URI is globally unique, which implies that whoever assigned the
> URI has some mechanism for assuring its uniqueness.
>
> - section 5.4
>
>     There is no worry over conflicts if both modules define the
>     type, since there is no ambiguity.
>
> I think you mean "There is no ambiguity if both modules define types
> with the same name.".
>
> - section 5.5
>
> This section talks a great deal about why scoping is done, but isn't
> specifically clear what the rules are.  (Traditionally, the rule is
> stated as either what range of source text a particular definition is
> visible in, or given an identifier use, how the matching definition is
> found.)
>
>     Scoped definitions MUST NOT shadow definitions at a higher scope.  A
>     type or grouping cannot be defined if a higher level in the schema
>     hierarchy has a definition with a matching identifier.
>
> I think the second sentence is confusing, because (to me) the term
> "schema hierarchy" implies the data tree structure, whereas the
> scoping rule seems to be intended to be entirely lexical.  In either
> case, this needs to be clarified.
>
> - section 5.6
>
>     Conformance is a measure of how accurately a server follows the
>     model.
>
> There is no model already under discussion, so you can't use "the
> model".  Perhaps
>
>     Conformance to a model is a measure of how accurately a server
>     follows a model.
>
> - section 5.6.5
>
> I suspect that if a server implements module A, and A imports B, the
> server is not required to implement B.  (Even if A references
> groupings in B.)  The answer to that should probably be stated
> explicitly.
>
>     If a server lists a module C in the "/modules-state/module" list from
>     "ietf-yang-library", and there are other modules Ms listed that
>     import C without specifying the revision date of module C, the server
>     MUST use the definitions from the most recent revision of C listed
>     for modules Ms.
>
> I think the end of that would be clearer as
>
>     ... the server MUST implement Ms by importing the most recent
>     revision of C listed in the "/modules-state/module" list.
>
>       module b {
>         yang-version 1.1;
>         namespace "urn:example:b";
>         prefix "b";
>
>         revision 2015-04-04;
>         revision 2015-01-01;
>
>         typedef myenum {
>           type enumeration {
>             enum zero; // added in 2015-01-01
>             enum one;  // added in 2015-04-04
>           }
>         }
>
>         container x {  // added in 2015-01-01
>           container y; // added in 2015-04-04
>         }
>       }
>
> Is this the correct way to specify multiple revisions of this module?
> Or is this an informal notation for the two module definitions:
>
>       module b {
>         yang-version 1.1;
>         namespace "urn:example:b";
>         prefix "b";
>
>         revision 2015-04-04;
>         revision 2015-01-01;
>
>         typedef myenum {
>           type enumeration {
>             enum zero; // added in 2015-01-01
>             enum one;  // added in 2015-04-04
>           }
>         }
>
>         container x {  // added in 2015-01-01
>           container y; // added in 2015-04-04
>         }
>       }
>
>       module b {
>         yang-version 1.1;
>         namespace "urn:example:b";
>         prefix "b";
>
>         revision 2015-01-01;
>
>         typedef myenum {
>           type enumeration {
>             enum zero; // added in 2015-01-01
>           }
>         }
>
>         container x {  // added in 2015-01-01
>         }
>       }
>
> If it is the latter, it would help the new reader to explain the
> convention (as no example of a multi-revision module is given in the
> document).
>
> - section 6
>
>     YANG modules use the UTF-8 [RFC3629] character encoding.
>
> Better to say that YANG modules use the Unicode character set and are
> stored in files using the UTF-8 character encoding.
>
> Verify that form-feed (0x0C) is not allowed.
>
> This might be a good place to talk about line-breaks in Yang source
> files.  It looks from section 14 that line-breaks MUST be either CRLF
> or LF.
>
> It is worth noting (either here or in 6.1.3) how line-breaks inside
> quoted strings are transcribed into the string's value.  As now
> written, it seems that the line-break is transcribed identically to
> how it is represented in the source.  That means (1) If the source is
> recoded with the other type of line break, the semantics of the Yang
> code change; and (2) if the source uses line-breaks of one type (CRLF
> or LF), only that type can be directly transcribed into string values.
> (But regardless of the source line-breaks, an LF can be transcribed
> into a double-quoted string with "\n".  But a CRLF cannot be
> transcribed into a double-quoted string with escape sequences.  Was
> that intended, or was "\r" intended to be legal?)
>
> - section 6.1
>
>     This section details the rules for recognizing tokens from an input
>     stream.
>
> Generally, language definitions intersperse the narrative text with
> the relevant grammar definitions.  Yang's statement grammar is simple
> enough that one doesn't need to see the context-free part of the
> grammar to understand the narrative for statements.  But when reading
> about tokenization, not having the grammar presented at the same time
> is quite a burden.  I'd recommend duplicating the relevant productions
> from section 14 into the subsections of section 6.
>
> There is some sort of exposition problem.  The result of
> "tokenization" is that the sequence of characters of the source is
> converted into a sequence of "tokens".  Then some subset of the tokens
> is discarded as being non-significant (e.g., whitespace and comments),
> and the remainder is parsed with a context-free grammar.  Here I can't
> figure out what the set of tokens is.  Looking at the grammar in
> section 14, it seems to be a context-free grammar on characters.  But
> that implies that there is no separate tokenization phase.
>
> An example that shows the problems:
>
>     mod:ext
>
> Is this one token, which is also an extension keyword, or is it a
> sequence of three tokens?
>
> - section 6.1.1
>
>     A block comment is enclosed within "/*" and "*/".
>
> Should say "starts with "/*" and ends with the nearest following
> "*/"".
>
> - section 6.1.2
>
>     A token in YANG is either a keyword, a string, a semicolon (";"), or
>     braces ("{" or "}").
>
> What is the intention of this sentence?  One interpretation is that it
> defines "token" as the union of several other classes.  But that has
> the limitation that those classes are not well-defined in this
> section.  E.g., what is the syntax of an "unquoted string"?  The other
> interpretation is that the Yang file is already separated into
> "tokens", and that the set of tokens is further subdivided, with all
> tokens that are not keywords, quoted strings, semicolons, or braces
> being unquoted strings, whose value is the sequence of characters
> within the token.  But the separation into tokens is not described.
>
> "string" is particularly confusing.  In most languages, "string"
> values are always quoted in source code.  But it seems that in Yang,
> any "token" that isn't a keyword or one of ;, {, }, is automatically
> an "unquoted string".  If that's so, it needs to be stated explicitly,
> since it's unusual.
>
> - section 6.1.3
>
>     If a string contains any space, tab, or newline characters, a single
>     or double quote character, a semicolon (";"), braces ("{" or "}"), or
>     comment sequences ("//", "/*", or "*/"), then it MUST be enclosed
>     within double or single quotes.
>
> Is a string containing "*/" required to be quoted?  I ask because the
> character sequence "*/" is not ambiguous if it is not preceded by "/*"
> -- it must be an unquoted string.
>
>     If a double-quoted string contains a line break followed by space or
>     tab characters that are used to indent the text according to the
>     layout in the YANG file, this leading whitespace is stripped from the
>     string, up to and including the column of the double quote character,
>     or to the first non-whitespace character, whichever occurs first.  In
>     this process, a tab character is treated as 8 space characters.
>
> This description isn't quite careful enough.  Better:
>
>     If a double-quoted string contains a line break followed by space or
>     tab characters, an initial part of this whitespace is removed from the
>     string.  The amount removed is the longest prefix whose width is no
>     larger than the width of the prefix of Yang source line containing
>     the opening double quote character of the string to and including the
>     opening double quote character.  For this purpose, the width of a
>     tab character is 8 and the width of any other character is 1.
>
> This does assume that all tabs are considered to have width 8, that
> is, tabs do not have the usual semantics of "advance to the next
> column that is divisible by 8".  That will sometimes cause unexpected
> results, e.g., if some source lines start with SPC TAB.  (Consider
> that whitespace before a line break is removed, which suggests the
> intention is that the value of the string should depend only on its
> visual appearance.)
>
> Also, we're using the convention that "whitespace" does NOT include CR
> or LF, which is not always how the term is used.  Perhaps a definition
> of "whitespace" should be put in section 3.
>
> There is also the special case:
>
>     SPC " LF
>     TAB x "
>
> Is the initial TAB of the second line to be removed or not?  There is
> no whitespace removal in the second line that will exactly reach the
> opening double quote.  As I've written it, the TAB is not removed.
>
>     Within a double-quoted string (enclosed within " "), a backslash
>     character introduces a special character, which depends on the
>     character that immediately follows the backslash:
>
> s/introduces a special character/introduces a representation of a
> special character/
>
> Verify that CR cannot be specified by an escape.
>
>     If a quoted string is followed by a plus character ("+"), followed by
>     another quoted string, the two strings are concatenated into one
>     string, allowing multiple concatenations to build one string.
>
> Are whitespace, line endings, or comments allowed between the quoted
> strings and the "+"?  (This description is in the lexical section, so
> non-significant lexemes can't be assumed to have been removed.)  (See
> also comments on section 14.)
>
>     If a quoted string is followed by a plus character ("+"), followed by
>     another quoted string, the two strings are concatenated into one
>     string, allowing multiple concatenations to build one string.
>     Whitespace trimming is done before substitution of backslash-escaped
>     characters in double-quoted strings.  Concatenation is performed as
>     the last step.
>
> I think you want to reverse the phrase order in the second sentence:
> "In double-quoted strings, whitespace trimming is done before
> substitution of backslash-escaped characters."  However, it's not
> clear that that matters; only a backslash followed by whitespace would
> be affected by whitespace trimming, and whitespace trimming would
> leave the backslash followed by CR or LF -- all of those cases are
> invalid.
>
> Also, if you keep that second sentence, it should be moved earlier --
> the first and third sentences of the paragraph apply to all quoted
> strings, but the second sentence only applies to double-quoted
> strings, and should be in a paragraph that deals with only
> double-quoted strings.
>
> - section 6.1.3.1
>
>     The following examples show some illegal strings:
>
>       ''''  - a single-quoted string cannot contain single quotes
>       """   - a double quote must be escaped in a double-quoted string
>
> These shouldn't be described as "illegal" strings; they aren't
> strings, truly, but the lexing process doesn't isolate them as tokens,
> after which they are decreed to be improper.  The first example is two
> single-quoted strings (''), one after the other.  The second is a
> double-quoted string (""), followed by the double-quote that starts
> another double-quoted string.  Better to say "The following examples
> are not string tokens:".
>
> - section 6.2
>
>     Identifiers can be specified as quoted or unquoted strings.
>
> If there is no lexical difference between how identifiers may be
> represented and how strings may be represented, and what is an
> identifier is distinguished only by the syntactic context, it would be
> helpful if that was stated explicitly in section 6.1.  (Though the
> characters allowed in identifiers are restricted.)
>
> - section 6.3.1
>
>     The processing of extensions depends on whether support for those
>     extensions is claimed for a given YANG parser or the tool set in
>     which it is embedded.  An unsupported extension, appearing in a YANG
>     module as an unknown-statement (see Section 14) MAY be ignored in its
>     entirety.  Any supported extension MUST be processed in accordance
>     with the specification governing that extension.
>
> This allows a loophole, where an implementation can not claim support,
> but then not ignore the extension.  I think you want to say "An
> unsupported extension ... MUST be ignored in its entirety."  (See also
> 7.20.1, which implies that an unsupported *feature* must be ignored.)
> If you really mean "MAY", what are the limits regarding what the
> server can do?
>
> - section 6.5
>
>     In an absolute
>     schema node identifier, the first identifier after the leading slash
>     is any top-level schema node in the local module or in all imported
>     modules.
>
> I think "in all imported modules" should be "in an imported module".
> (The prefix of the identifier will tell which module.)
>
> - section 7.1
>
>     The module
>     name follows the rules for identifiers in Section 6.2.
>
> Why not say "The module name is an identifier."?  Similarly for all
> other occurrences of "follows the rules for identifiers".  (I don't
> think we hang any semantics on the term "identifier", only syntax.)
>
> - section 7.1.4
>
> See discussion of "prefix" in comments for section 1.1.  I think all
> that is needed is to update the second paragraph to:
>
>     When used inside the "module" statement, the "prefix" statement
>     defines the prefix suggested to be used when this module is imported.
>
>     To improve readability of the NETCONF XML, a NETCONF client or server
>     that generates XML or XPath that use prefixes SHOULD use the prefix
>     defined by the module as the XMLNS prefix to associate with the
>     module's namespace (which may be impossible if there is a conflict
>     with another XMLNS prefix).
>
> The important thing is that the discussion of using the prefix value
> as an XMLNS prefix is split into a separate paragraph, so it's clear
> that it is a different subject.
>
>     The
>     prefix string MAY be used to refer to definitions contained in the
>     module, e.g., "if:ifName".
>
> I think this should be qualified "MAY be used within the module to
> refer to the definitions contained"; the following paragraph suggests
> that a module that imports this module can specify a different prefix
> for its references to use, and this prefix will not work in that
> module.
>
> - section 7.1.5
>
>     Multiple
>     "import" statements may be specified to import from different
>     modules.
>
> Is this a requirement that two "import" statements in the same module
> MUST import different modules?  If not, the sentence should be shorted
> to "Multiple "import" statements may be specified.", or omitted
> entirely.  But if a module can't be imported twice, that should
> probably be made clearer
>
>     Multiple "import" statements may be specified, but they must import
>     from different modules.
>
> - section 7.1.6
>
>     When a module includes a submodule, it incorporates the contents of
>     the submodule into the node hierarchy of the module.
>
> What does this mean?  The "include" statement is a top-level statement
> within its module, so how is its contents part of the node hierarchy
> -- what node is the parent of its nodes?  Perhaps the meaning is that
> top-level nodes of the submodule are implicitly top-level nodes of the
> module.
>
> - section 7.2
>
>     While the primary unit in YANG is a module, a YANG module can itself
>     be constructed out of several submodules.
>
> This doesn't really capture the essence.  What you want to say is
>
>     While the primary unit in YANG is a module, a YANG module can
>     include submodules, whose definitions are incorporated into it.
>
> - section 7.5.1
>
>     In the first style, the container has no meaning of its own, existing
>     only to contain child nodes.
>
> I think it would be good to add here "In particular, the presence of
> the container element with no child elements is semantically
> equivalent to the absence of the container element."
>
> - section 7.5.4.3
>
>         must "ifType != 'ethernet' or " +
>              "(ifType = 'ethernet' and ifMTU = 1500)" {
> 	    ...
>         }
>         must "ifType != 'atm' or " +
>              "(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
> 	    ...
>
> Are these a preferred style?  I ask because it would be shorter to say
>
>         must "ifType != 'ethernet' or ifMTU = 1500" {
>
>         must "ifType != 'atm' or " +
>              "(ifMTU <= 17966 and ifMTU >= 64)" {
>
> (Perhaps the ifMTU element is optional, but even then, "and" must
> short-circuit for the given expressions to always be valid, so it
> seems that "or" must short-circuit.)
>
> - section 7.5.7
>
> I suspect that child elements can be omitted if they're not mandatory,
> but their order need not match the order in the schema.
>
> - section 7.6.1
>
>     Note that if the leaf or any of its ancestors has a "when" condition
>     or "if-feature" expression that evaluates to "false", then the
>     default value is not in use.
>
> ISTM that this is not a "Note that" but rather a precondition of the
> analysis of the preceding paragraphs, so it should be moved above
> "Otherwise, the usage of the default value...".  (See also the similar
> condition in 7.7.2.)
>
> - section 7.6.4
>
>     The default value MUST NOT be marked with an "if-feature" statement.
>
> I think you want "The definition of the default value..." rather than
> "The default value...".
>
> But it's not clear what the whole set of situations is that should be
> forbidden.  For instance, this should work:
>
>       typedef xyz {
>         type enumeration {
> 	 enum blue { if-feature blue; }
> 	 ...
>         }
>       }
>
>       leaf color {
>         if-feature blue;
>         type xyz;
>         default blue;
>       }
>
> Whereas this won't:
>
>       typedef xyz {
>         type enumeration {
> 	 enum blue { if-feature blue; }
> 	 ...
>         }
>       }
>
>       leaf color {
>         // No if-feature here.
>         type xyz;
>         default blue;
>       }
>
> Is this rule only meant to cover the situation where the leaf's type
> is an "in-line" enum and the particular enum value has an if-feature?
>
> - section 7.7.1
>
> It might be worth mentioning that duplicated values are allowed and
> are significant, since that has changed since Yang 1.  I.e., even in a
> system ordered list, the number of list elements with any particular
> value must be preserved.
>
> - section 7.7.2
>
> It appears to be assumed that the server's behavior is the same if (1)
> a leaf-list node is specified with zero values, and (2) if the
> leaf-list node is absent and has no default values.
>
>     Otherwise, if the leaf-list's type has
>     a default value, and the leaf-list does not have a "min-elements"
>     statement with a value greater than or equal to one, then the leaf-
>     list's default value is the type's default value.  In all other
>     cases, the leaf-list does not have any default values.
>
> I think it would help to s/the type's default value/one instance of
> the type's default value/.
>
> Is the final condition correct?  E.g., if the leaf-list's type has a
> default value, and it has a min-elements with value 2, then the
> leaf-list has no default values -- which is invalid.
>
> - section 7.7.7.1
>
>     The entries in the list are sorted according to an order determined
>     by the system.  The "description" string for the list may suggest an
>     order to the server implementor.  If not, an implementation is free
>     to sort the entries in the most appropriate order.
>
> This is mealy-mouthed about what is required and what is recommended.
> Better would be to omit "If not, an implementation is free to sort the
> entries in the most appropriate order."
>
> - section 7.7.7.2
>
>     The entries in the list are sorted according to an order defined by
>     the user.  This order is controlled by using special XML attributes
>     in the  request.
>
> Actually, the entries aren't "sorted", as there is no requirement that
> any particular set of values always has a particular order; the user
> can insert 1, 2, 3 at one time, and 3, 2, 1 at another.  The correct
> meaning is splicing these two sentences:
>
>     The user orders entries in the list by using special XML attributes
>     in the  request.
>
> - section 7.7.8
>
>     The XML elements
>     representing leaf-list entries MAY be interleaved with other sibling
>     elements, ...
>
> I think it would be more accurate to say "interleaved with elements
> for siblings of the leaf-list node".  (See also section 7.8.5.)
>
> - section 7.8
>
>     A list entry is uniquely identified by the values of the list's keys,
>     if defined.
>
> What does "if defined" apply to?  Is the point that if keys are not
> defined, then list entries have no such uniqueness requirement?  If
> the latter, then the text "Each entry ... is uniquely identified by
> the values of its key leafs." in section 4.2.2.4 needs to be changed.
>
> - section 7.8.2
>
>     The "key" statement, which MUST be present if the list represents
>     configuration, and MAY be present otherwise, takes as an argument a
>     string that specifies a space-separated list of leaf identifiers of
>     this list.
>
> It would help to change to "list of one or more leaf identifiers"
>
> - section 7.8.3
>
>     The "unique" constraint specifies that the combined values of all the
>     leaf instances specified in the argument string, including leafs with
>     default values, MUST be unique within all list entry instances in
>     which all referenced leafs exist.
>
> Should that sentence end "... within all list entry instances in which
> all referenced leafs exist or have default values"?
>
> - section 7.9
>
>     The "choice" statement defines a set of alternatives, only one of
>     which may exist at any one time.
>
> Better, "only one of which may be present in any one data tree".
>
>     A choice node does not exist in the data tree.
>
> This is a good phrase and should be applied to list nodes (in that
> there is no node for the list, only for each list element).
>
>     A choice consists of a number of branches, defined with the "case"
>     substatement.
>
> Better, "each defined with a "case" substatement".
>
>     As a shorthand, the "case" statement can be omitted if the branch
>     contains a single "anydata", "anyxml", "choice", "container", "leaf",
>     "list", or "leaf-list" statement.  In this case, the case node still
>     exists in the schema tree, and its identifier is the same as the
>     identifier in the branch statement.
>
> There is no "branch" statement...  How about:
>
>     As a shorthand, the "case" statement can be replaced by just the
>     statement for the child node if the branch contains a single
>     "anydata", "anyxml", "choice", "container", "leaf", "list", or
>     "leaf-list" statement.  In this case, the case node still exists in
>     the schema tree, and its identifier is the same as the identifier
>     of the child node.
>
> - section 7.9.3
>
>     The argument is the identifier of the "case" statement.
>
> Better, "The argument is the identifier of the default "case"
> statement."
>
> - section 7.9.5.  XML Encoding Rules
>
>     The choice and case nodes are not visible in XML.
>
> Use this sort of statement for lists and leaf-lists, which have no
> visible XML for the lists as a whole.
>
> - section 7.10
>
>     The "anydata" statement is used to represent an unknown set of nodes
>     that can be modelled with YANG, except anyxml, ...
>
> What is the practical consequence of this restriction?  It's not at
> all clear to me which chunks of XML could be modelled with Yang and
> which could not.
>
> - section 7.12
>
>     A grouping is like a "structure" or a "record" in conventional
>     programming languages.
>
> Add, "... though no grouping node exists in the XML."
>
> - section 7.15
>
>     The "action" statement is used to define an operation connected to a
>     specific container or list data node.
>
> Might it be better to say "list element data node"?  What isn't being
> said explicitly is that an action that appears in a list statement is
> an action on a single element of the list, rather than an action on
> the list as a whole.  Similarly for notifications, section 7.16.
>
> - section 7.15.2
>
>     The last container or list contains an XML element that ...
>
> Would "innermost" be better than "last"?
>
> - section 7.17
>
>     The "augment" statement allows a module or submodule to add to >a<
>     schema tree defined in an external module, or >in< the current module and
>     its submodules, and to add to the nodes from a grouping in a "uses"
>     statement.
>
> I think adding "in" where indicated makes the sentence clearer.
>
> I've changed a "the" is changed to an "a" where indicated.  The
> question is whether the module defines a schema tree or a schema
> forest, a set of trees.  That depends on whether each top-level node
> can be used independently as the root of a data tree or whether they
> have to be used together.  See comments on section 5.1.2.
>
> - section 7.18
>
> It would help to insert a discussion of the global purpose and use of
> identities.  In particular, what things can refer to them?  It looks
> like only identityref leafs can do so, but I could easily be wrong.
> Also, more discussion in the example (7.18.3) would be helpful.
>
>     The "identity" statement is used to define a new globally unique,
>     abstract, and untyped identity.  Its only purpose is to denote its
>     name, semantics, and existence.
>
> The two uses of "its" in the second sentence are ambiguous.  I think
> you mean "The statement's only purpose is to denote the identity's
> name, semantics, and existence."  Though I'm not sure that an identity
> has any semantics beyond its existence and base identities.
>
> - section 7.19
>
>     The statement's argument is an identifier that is the new keyword for
>     the extension and must be followed by a block of substatements that
>     holds detailed extension information.
>
> s/The statement's/The "extension" statement's/ -- this talks about the
> "extension" statement that defines the extension statement [sic!].
>
> - section 7.20.2.1
>
>     In this example, the container "target" is implemented if any of the
>     features "outbound-tls" or "outbound-ssh" are supported by the
>     server.
>
> "either" is better than "any" if there are only two choices.
>
> - section 7.21.4
>
>     The "reference" statement takes as an argument a string ...
>
> Perhaps s/a string/a human-readable string/.
>
> - section 7.21.5
>
> Note that if a data definition has both an "if-feature" and a "when",
> then the "if-feature" is tested first.
>
>     If the XPath expression references any node that also has associated
>     "when" statements, these "when" expressions MUST be evaluated first.
>     There MUST NOT be any circular dependencies in these "when"
>     expressions.
>
> I think this could be better phrased:
>
>     If the XPath expression references any node that also has
>     associated "when" statements, then the "when" expressions of the
>     referenced nodes MUST be evaluated first.  There MUST NOT be any
>     circular dependencies among "when" expressions.
>
> - section 9.3.4
>
> Can one apply a fraction-digits restriction to a derived type that
> already has a fraction-digits restriction?  ISTM that this is sensible
> if the fraction-digits numbers of the two restrictions are the same.
> Then again, that would be pointless, and we might want to forbid
> fraction-digits re-restrictions.
>
> The fraction-digits statement doesn't seem to have any of the
> substatements (e.g., description, error-app-tag) that other
> restrictions (e.g., length, pattern, range) do.  (The grammar in
> section 14. agrees.)  Is this OK?  It seems like a value could fail to
> conform to fraction-digits.
>
> - section 9.6.3
>
>     An enumeration can be restricted with the "enum" (Section 9.6.4)
>     statement.
>
> This should be fleshed out:  "... can be restricted with one or more
> "enum" (Section 9.6.4) statements, which enumerate a subset of the
> values of the base type."
>
> - section 9.7.2
>
>     The lexical representation of the bits type is a space-separated list
>     of the individual bit values that are set.
>
> I think that should be "... list of the names of the bits that are
> set."  I tend to think of a "bit value" as 0 or 1.
>
> - section 9.8.3
>
>     The canonical form of a binary value follows the rules in [RFC4648].
>
> Best specify "the rules of 'Base 64 Encoding' in [RFC4648]."
>
> - section 9.9
>
>     The leafref type is used to declare a constraint on the value space
>     of a leaf, based on a reference to a set of leaf instances in the
>     data tree.  The "path" substatement (Section 9.9.2) selects a set of
>     leaf instances, and the leafref value space is the set of values of
>     these leaf instances.
>
> The first sentence isn't quite right.  Perhaps:
>
>     The value space of a leaf with leafref type is one of the values of
>     a set of leaf instances in the data tree.  The "path" substatement
>     (Section 9.9.2) selects the set of leaf instances, and the leafref
>     value space is the set of values of these leaf instances.
>
> - section 9.9.3
>
>     If "require-instance" is "true", it means that the instance being
>     referred MUST exist for the data to be valid.  This constraint is
>     enforced according to the rules in Section 8.
>
>     If "require-instance" is "false", it means that the instance being
>     referred MAY exist in valid data.
>
> What does "the instance being referred" mean?  Perhaps you meant "the
> instance being referred to"?
>
> Also, I think the second paragraph means that if require-instance is
> false, the referred-to instance need not exist.  But it's not clear to
> me what that would mean -- if there are no instances referenced by the
> XPath expression, then the set of value values of the leafref would be
> empty and the leafref would necessarily be invalid. ...  I think these
> paragraphs need to be expanded in some way.
>
> (require-instance is also used in instance-identifier, which may have
> subtly different semantics than when it is used in leafref.)
>
> - section 9.9.4.  Lexical Representation
>
>     A leafref value is lexically represented the same way as the leaf it
>     references.
>
> Probably better as "... the same way as the leaf it references
> represents its value."
>
> - section 9.12
>
>     It is used to repeatedly specify each member type of the
>     union.
>
> I think you want "It is used repeatedly to specify ..." --
> "repeatedly" modifies "used", not "specify".
>
>     In the XML encoding, a value representing a union data type is
>     validated consecutively against each member type, in the order they
>     are specified in the "type" statement, until a match is found.  The
>     type that matched will be the type of the value for the node that was
>     validated.
>
> I think a distinction needs to be made here between generating XML and
> interpreting XML:
>
>     When generating an XML encoding, a value is encoded according to
>     the rules of the member type to which the value belongs.  When
>     interpreting an XML encoding, a value is validated consecutively
>     against each member type, in the order they are specified in the
>     "type" statement, until a match is found.  The type that matched
>     will be the type of the value for the node that was validated, and
>     the encoding is interpreted according to the rules for that type.
>
> - section 10.3.1
>
>     If the first argument node is of type leafref, the function returns a
>     node set that contains the nodes that the leafref refers to.
>
> I *think* that this means the set of nodes that the leafref's XPath
> selects, but a plausible alternative is the subset of those nodes
> which have the same value as the leafref does.  This hinges on the
> meaning of "the leafref refers to a node", which isn't defined
> unambiguously in section 9.9.
>
> - section 11
>
>     o  A "description" statement may be added or clarified without
>        changing the semantics of the definition.
>
> Probably better to change "clarified" to "changed".  (What is the
> specificational content of "clarified"?)
>
>     o  A "type" statement may be replaced with another "type" statement
>        that does not change the syntax or semantics of the type.  For
>        example, an inline type definition may be replaced with a typedef,
>        but an int8 type cannot be replaced by an int16, since the syntax
>        would change.
>
> Is the last sentence correct?  Any value that was previously valid
> would remain valid.  This is similar to changing "range '-128..127'"
> to "range '-32768..32767'".
>
> - section 13
>
>     The translated module is called a YIN module.  This
>     section describes symmetric mapping rules between the two formats.
>
> I don't think "symmetric" is the right word; perhaps "bidirectional".
>
> - section 14
>
>     This grammar assumes that the scanner replaces YANG comments with a
>     single space character.
>
> It would probably be better to explicitly include comments in the
> separator nonterminals:
>
>     ;; 'comment' is specified in Section 6.1.1
>
>     sep                 = 1*(WSP / line-break / comment)
>                           ; unconditional separator
>
>     optsep              = *(WSP / line-break / comment)
>
>     stmtsep             = *(WSP / line-break / comment / unknown-statement)
>
> --
>
>     module-stmt         = optsep module-keyword sep identifier-arg-str
>     		       	 ...
>
> This has the consequence that 'module"name"{...' is invalid, because
> there is no separator after 'module', even though traditional
> tokenizers would handle it.  Verify that this is intended.  (This
> pattern is consistent for all statement types.)
>
>     linkage-stmts       = ;; these stmts can appear in any order
>                           *import-stmt
>                           *include-stmt
>
> This could easily be handled like body-stmts:
>
>     linkage-stmts       = *(import-stmt /
>                             include-stmt)
>
> --
>
>     if-feature-expr     = "(" if-feature-expr ")" /
>                           if-feature-expr sep boolean-operator sep
>                             if-feature-expr /
>                           not-keyword sep if-feature-expr /
>                           identifier-ref-arg
>
> This should probably be marked ";; precedence rules specified in
> Section 7.20.2", as the grammar is ambiguous and does not specify the
> precedence, whereas typical programming language grammars encode the
> precedence rules.
>
>     instance-identifier-specification =
>                           [require-instance-stmt]
>
> Why is require-instance-stmt in [...]?  The only use of
> instance-identifier-specification is in type-body-stmts, and the only
> use of type-body-stmts is in type-stmt, where it is in [...].  Compare
> with numerical-restrictions:
>
>     numerical-restrictions = range-stmt
>
> --
>
>     binary-specification = [length-stmt]
>
> Similarly.
>
>     quoted-string       = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)
>
>     string              = < an unquoted string as returned by >
>                           < the scanner, that matches the rule >
>                           < yang-string >
>
> The handling of "string" is hard to follow and/or inexact.  First, we
> need a term for the "value" of a string written in Yang source, so we
> can say
>
>     prefix-arg-str      = < a string whose ??? matches the rule >
>                           < prefix-arg >
>
> The text that is now used is not too difficult to understand, but it's
> inexact and makes it hard to write specifications about how the value
> is determined.
>
> (Also, there seem to be too many <...>, dividing the narrative text
> into two parts.  The natural way to write it would be:
>
>     prefix-arg-str      = < a string whose ??? matches the rule
>                             prefix-arg >
>
> But it might not be worth the effort to change the use of <...>
> throughout section 14.)
>
> We need a production that tells exactly the syntax of "an unquoted
> string as return by the scanner".
>
> We also need productions for quoted strings.  I can reconstruct these:
>
>     quoted-string       = (single-quoted-string / double-quoted-string)
>     		         *(optsep "+" optsep
>                               (single-quoted-string / double-quoted-string))
>
>     single-quoted-string = SQUOTE *(yang-char excluding "'") SQUOTE
>
> (I don't know a good way to exclude one character from a character set
> in ABNF.)
>
>     double-quoted-string = DQUOTE *dq-char DQUOTE
>
>     dq-char = yang-char excluding BACKSLASH and DQUOTE /
>               BACKSLASH ( "n" / "t" / DQUOTE / BACKSLASH )
>
> Verify that "optsep" is what is allowed to appear around "+".
>
> Needs a comment pointing to Section 6.1.3 as telling how to interpret
> quoted-strings.
>
> [END]
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Tue May 17 20:59:22 2016
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 35C8612D89C; Tue, 17 May 2016 20:59:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Suresh Krishnan" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160518035920.24734.39237.idtracker@ietfa.amsl.com>
Date: Tue, 17 May 2016 20:59:20 -0700
Archived-At: 
Cc: netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-rfc6020bis@ietf.org
Subject: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 03:59:20 -0000

Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc6020bis-12: 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-rfc6020bis/



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

Meta comment:

Shouldn't this document obsolete RFC6060. There is no Obsoletes: tag in
the draft

Section 4.2.4:

s/A reference a data tree node/A reference to a data tree node

Section 9.4.7:

It is not clear why the following refinement is illegal. Can you
clarify?

     type my-base-str-type {
       // illegal length refinement
       length "1..999";
     }


IANA considerations:

Not sure what is the correct method for doing this in -bis documents, but
I would have expected a note that instructs IANA to switch references to
RFC6020 in IANA registries over to this one.



From nobody Tue May 17 23:10:13 2016
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 6015712B03B; Tue, 17 May 2016 23:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.646
X-Spam-Level: 
X-Spam-Status: No, score=-5.646 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=-1.426, 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 AlGDrFrB4qlJ; Tue, 17 May 2016 23:10:07 -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 92A0712B029; Tue, 17 May 2016 23:10:06 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COX41221; Wed, 18 May 2016 06:10:03 +0000 (GMT)
Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 18 May 2016 07:10:02 +0100
Received: from szxeml561-mbs.china.huawei.com ([169.254.6.98]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0235.001; Wed, 18 May 2016 14:09:57 +0800
From: Rohit pobbathi 
To: netconf , "netmod@ietf.org" 
Thread-Topic: Conflicting usage scenario for "invalid-value" error-tag between RFC 6241 & RFC 6020
Thread-Index: AdGwy+Y03p/3Jjn0Rlaa0Z7VvPBCdg==
Importance: high
X-Priority: 1
Date: Wed, 18 May 2016 06:09:57 +0000
Message-ID: <2730B0D5F3302249A30EBF0DAE96D4CB44C103EA@SZXEML561-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.210.230]
Content-Type: multipart/alternative; boundary="_000_2730B0D5F3302249A30EBF0DAE96D4CB44C103EASZXEML561MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.573C073C.00C8, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.6.98, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a6f2baf49f21960eaa22e5342166db6d
Archived-At: 
Subject: [netmod] Conflicting usage scenario for "invalid-value" error-tag between RFC 6241 & RFC 6020
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 06:10:09 -0000

--_000_2730B0D5F3302249A30EBF0DAE96D4CB44C103EASZXEML561MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I have noticed a conflict in the usage of error-tag for payload parsing sce=
nario between RFC 6241 & RFC 6020

RFC 6241 Appendix A.  NETCONF Error List - provides the below description f=
or "invalid-value" & "bad-element"
   error-tag:         invalid-value
   error-type:       protocol, application
   error-severity: error
   error-info:       none
   Description:    The request specifies an unacceptable value for one
                             or more parameters.

   error-tag:         bad-element
   error-type:       protocol, application
   error-severity: error
   error-info:         : name of the element w/ bad value
   Description:     An element value is not correct; e.g., wrong type,
                              out of range, pattern mismatch.

RFC 6020 Section 8.3.1.  Payload Parsing
   o  If a leaf data value does not match the type constraints for the
      leaf, including those defined in the type's "range", "length", and
      "pattern" properties, the server MUST reply with an
      "invalid-value" error-tag in the rpc-error, and with the error-
      app-tag and error-message associated with the constraint, if any
      exist.

For leaf data value mismatch in range/length/pattern there is conflict in t=
he error-tag suggested by RFC 6241 & RFC 6020.

Please confirm which is the right error-tag to be used in a standard Netcon=
f Server implementation.

Regards,
Rohit Pobbathi

--_000_2730B0D5F3302249A30EBF0DAE96D4CB44C103EASZXEML561MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I have noticed a conflict in the usage of error-tag =
for payload parsing scenario between RFC 6241 & RFC 6020


 


RFC 6241 Appendix A.  NETCONF Error List =
211; provides the below description for “invalid-value” & &=
#8220;bad-element”


   error-tag:     =
;    invalid-value


   error-type:     &nb=
sp; protocol, application


   error-severity: error


   error-info:     &nb=
sp; none


   Description:    The request specifies an unacceptable value for one=



    &=
nbsp;           &nbs=
p;            or mor=
e parameters.


 <=
/p>

   error-tag:     =
;    bad-element


   error-type:     &nb=
sp; protocol, application


   error-severity: error


   error-info:     &nb=
sp;  <bad-element> : name of the element w/ bad value<=
/o:p>


   Description:     An element value is not correct; e.g., wrong type,=



    &=
nbsp;           &nbs=
p;             =
out of range, pattern mismatch.


 <=
/p>

RFC 6020 Section 8.3.=
1.  Payload Parsing


   o  If =
a leaf data value does not match the type constraints for the


    =
  leaf, including those defined in th=
e type's "range", "length", and


    &n=
bsp; "pattern" properties, the server MUST reply with an


    &n=
bsp; "invalid-value" error-tag=
 in the rpc-error, and with the error-


    =
  app-tag and error-message associated with the constraint, if any


    =
  exist.


 =



For leaf data value mism=
atch in range/length/pattern there is conflict in the error-tag suggested b=
y RFC 6241 & RFC 6020.


 =



Please confirm which is =
the right error-tag to be used in a standard Netconf Server implementation.=



 =



Regards,


Rohit Pobbathi






--_000_2730B0D5F3302249A30EBF0DAE96D4CB44C103EASZXEML561MBSchi_--


From nobody Tue May 17 23:58:56 2016
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 D7BBF12D0DA; Tue, 17 May 2016 23:58:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 3R-bs59uldzJ; Tue, 17 May 2016 23:58:47 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC9E12D0D3; Tue, 17 May 2016 23:58:47 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BBA56770; Wed, 18 May 2016 08:58:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hNZub1HsIqh5; Wed, 18 May 2016 08:58:34 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 May 2016 08:58:44 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D954B2004E; Wed, 18 May 2016 08:58:44 +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 1BZHwhsB5snx; Wed, 18 May 2016 08:58:44 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A65A920047; Wed, 18 May 2016 08:58:43 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 8D4A33AD7FFC; Wed, 18 May 2016 08:58:43 +0200 (CEST)
Date: Wed, 18 May 2016 08:58:43 +0200
From: Juergen Schoenwaelder 
To: Suresh Krishnan 
Message-ID: <20160518065843.GB5141@elstar.local>
Mail-Followup-To: Suresh Krishnan , The IESG , draft-ietf-netmod-rfc6020bis@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org
References: <20160518035920.24734.39237.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160518035920.24734.39237.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod-chairs@ietf.org, The IESG , netmod@ietf.org, draft-ietf-netmod-rfc6020bis@ietf.org
Subject: Re: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 06:58:50 -0000

On Tue, May 17, 2016 at 08:59:20PM -0700, Suresh Krishnan wrote:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-netmod-rfc6020bis-12: 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-rfc6020bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Meta comment:
> 
> Shouldn't this document obsolete RFC6060. There is no Obsoletes: tag in
> the draft

I guess this is because there are a couple of RFCs that depend on
RFC6020 and so we can't retire RFC6020 right now.

> Section 4.2.4:
> 
> s/A reference a data tree node/A reference to a data tree node
> 
> Section 9.4.7:
> 
> It is not clear why the following refinement is illegal. Can you
> clarify?
> 
>      type my-base-str-type {
>        // illegal length refinement
>        length "1..999";
>      }
>

Because my-base-str-type is restricted to length "1..255" and you
can't enlarge the length restriction in a refinement.

> IANA considerations:
> 
> Not sure what is the correct method for doing this in -bis documents, but
> I would have expected a note that instructs IANA to switch references to
> RFC6020 in IANA registries over to this one.

This is what the WG originally thought but then we got advice that the
original IANA allocation should stay in force...

/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 May 18 01:16:39 2016
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 2920A12D09C; Wed, 18 May 2016 01:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level: 
X-Spam-Status: No, score=-15.946 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=-1.426, 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 Q6FNhyBvuOpx; Wed, 18 May 2016 01:16:34 -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 D520B12D098; Wed, 18 May 2016 01:16:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9115; q=dns/txt; s=iport; t=1463559394; x=1464768994; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=mTy8o+I6M6Qemevv2q6yrpZRNDkkoUbhGV6rA/NtH/o=; b=Hy0gg1aJMskGxKwts2B7J29xwzkJMNh5eUH9PHtQHQgn6dOtt7gM4ifJ FbN4mFzd6Fsa1b64ff7b0flwbjSl+rKnvWhSpeVwykBK9MTfeIR64qeaK t5UgH9Q/qZRHnfKZLHmIA4Aub3YwbxjAKwdjwlrI4dxa+c94jcHukW1Qw A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaKAAZJDxX/xbLJq1UCYQ3p22NYIZKM?= =?us-ascii?q?oYRAoIIAQEBAQEBZieEQwEBBCNOGAsYKgICVwYBDAQEAQGIK7BOkVUBAQEBAQE?= =?us-ascii?q?BAQIBAQEBAQEBAQEBAQ4OiBuCV4QYFYMSgj0cAQSYK4MrgWiBXYcwgWmET4MIh?= =?us-ascii?q?VqPSWKCBgUXgU06A4g1AQEB?=
X-IronPort-AV: E=Sophos;i="5.26,328,1459814400";  d="asc'?scan'208,217";a="635699862"
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; 18 May 2016 08:16:31 +0000
Received: from [10.61.103.219] (dhcp-10-61-103-219.cisco.com [10.61.103.219]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4I8GUPk008884;  Wed, 18 May 2016 08:16:31 GMT
To: Michael Richardson , netmod@ietf.org, "opsawg@ietf.org" 
References: <29371.1460055085@obiwan.sandelman.ca> <5706B779.5050602@cisco.com> <28476.1460063381@obiwan.sandelman.ca> <5707BB90.3020700@cisco.com> <7855.1460145900@obiwan.sandelman.ca>
From: Eliot Lear 
Message-ID: 
Date: Wed, 18 May 2016 10:16:30 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <7855.1460145900@obiwan.sandelman.ca>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DFLefJJd358QUXej2kBvmgwsbFHEGDhBW"
Archived-At: 
Subject: Re: [netmod] mud documents
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 08:16:36 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--DFLefJJd358QUXej2kBvmgwsbFHEGDhBW
Content-Type: multipart/mixed; boundary="MuqEDUj7jbBpek96MpcVLbAHrrJH2WaXG"
From: Eliot Lear 
To: Michael Richardson , netmod@ietf.org,
 "opsawg@ietf.org" 
Message-ID: 
Subject: Re: mud documents
References: <29371.1460055085@obiwan.sandelman.ca>
 <5706B779.5050602@cisco.com> <28476.1460063381@obiwan.sandelman.ca>
 <5707BB90.3020700@cisco.com> <7855.1460145900@obiwan.sandelman.ca>
In-Reply-To: <7855.1460145900@obiwan.sandelman.ca>

--MuqEDUj7jbBpek96MpcVLbAHrrJH2WaXG
Content-Type: multipart/alternative;
 boundary="------------1FDB536B51AC3B15E9EF5C3F"

This is a multi-part message in MIME format.
--------------1FDB536B51AC3B15E9EF5C3F
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

[It looks like we're moving some of this discussion to OPSAWG, so CCing
opsawg].

Getting back to some old threads.

On 4/8/16 10:05 PM, Michael Richardson wrote:
> Eliot and I have been conversing about policies.  I proposed that I wan=
t a
> policy like:
>
> He asked me three questions:
>
> 0 what happens when the policy enforcement point (PEP) that actually
>   operationalizes the policy does not understand the policy in its
>   entirety? Does it implement what it can, or does it discard?
>
> 1 Where does connections per unit of time fit in the above?
> 2 Where does logging/notification fit into the above?
>
> I proposed that we wanted policies like this:
>
>> ---<
> I am a printer.
> I accept connections on the IPP port.
> Please be suspicious when the connections are non-local.
>
> Eliot asked:
>     > There is no concept today of .  Let me ask what ne=
twork
>     > behavior you would associate with that?
>
> I answered:
> mcr> Consider blocking them if they occur too frequently, or the
> mcr> connections have a small number of RTTs.
>
> I also think that the "be-suspicious" part might be significantly modif=
ied by
> local policy.  It could be that this results in no connections, it coul=
d be
> that it must be approved by an admin, that it's subject to some kind of=

> site-wide ACL (such connections from the VPN, intranet and partners oka=
y, not
> the wild internet...)
>
> We discussed whether we could clearly articulate other policies like
> connections/minute or connections/day that would be not-suspicious.
>
> I also suggested that this could extend beyond "THINGS" to *APPS* as we=
ll:
>
>    consider that the MUD could well be packaged with PC/Android/iPhone
>    *apps* as part of their security profile.
>    SELinux pretends to do this, but in practice configuring it is still=
 close
>    to impossible.  The MUD specification would help a lot I think.
>

I think the following criteria are built into the MUD design that makes
these sorts of changes hard:

  * The identity of the Thing is tied to either DHCP, LLDP, or 802.1AR
    attributes, which are all around the Thing itself and not an app.=20
    This having been said, if there is a way for an app to inform the
    network that it too has a MUD file, then the network can use that
    information.  The principle here is that the URL is distinct from
    its transmission means.  Also, our initial focus has been on
    admitting the device onto the network itself.  And so I think what
    we have here is future work, and I invite Michael to write a draft ;-=
)
  * As currently defined we're using the least common denominator for
    ACL capabilities.  That way the most network elements can implement
    MUD.  Question: is a time-based ACL common on a home router?  2nd
    question: what would happen to the policy if a part of it is not
    implementable?  It might be possible to put some #ifdef-like
    capability in there, but that leads to the final design criterion..
  * Keep it simple for the manufacturers, at least for the first
    version.  If they need to scratch their heads too much they'll just
    give up.

Eliot



--------------1FDB536B51AC3B15E9EF5C3F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
[It looks like we're moving some of this discussion to OPSAWG, so
      CCing opsawg].

    Getting back to some old threads.

    

    
On 4/8/16 10:05 PM, Michael Richardson=

      wrote:

    

    

      
Eliot and I have been conversing about policies.  I proposed that I want =
a
policy like:

He asked me three questions:

0 what happens when the policy enforcement point (PEP) that actually
  operationalizes the policy does not understand the policy in its
  entirety? Does it implement what it can, or does it discard?

1 Where does connections per unit of time fit in the above?
2 Where does logging/notification fit into the above?

I proposed that we wanted policies like this:



      

        
---<


      

      
I am a printer.
I accept connections on the IPP port.
Please be suspicious when the connections are non-local.

Eliot asked:
    > There is no concept today of <be-suspicious>.  Let me ask =
what network
    > behavior you would associate with that?

I answered:
mcr> Consider blocking them if they occur too frequently, or the
mcr> connections have a small number of RTTs.

I also think that the "be-suspicious" part might be significantly modifie=
d by
local policy.  It could be that this results in no connections, it could =
be
that it must be approved by an admin, that it's subject to some kind of
site-wide ACL (such connections from the VPN, intranet and partners okay,=
 not
the wild internet...)

We discussed whether we could clearly articulate other policies like
connections/minute or connections/day that would be not-suspicious.

I also suggested that this could extend beyond "THINGS" to *APPS* as well=
:

   consider that the MUD could well be packaged with PC/Android/iPhone
   *apps* as part of their security profile.
   SELinux pretends to do this, but in practice configuring it is still c=
lose
   to impossible.  The MUD specification would help a lot I think.



    

    

    I think the following criteria are built into the MUD design that
    makes these sorts of changes hard:

    
    
      
  • The identity of the Thing is tied to either DHCP, LLDP, or
        802.1AR attributes, which are all around the Thing itself and
        not an app.=C2=A0 This having been said, if there is a way for an=
 app
        to inform the network that it too has a MUD file, then the
        network can use that information.=C2=A0 The principle here is tha=
t
        the URL is distinct from its transmission means.=C2=A0 Also, our
        initial focus has been on admitting the device onto the network
        itself.=C2=A0 And so I think what we have here is future work, an=
d I
        invite Michael to write a draft ;-)
    
      
    • 
      
  • As currently defined we're using the least common denominator
        for ACL capabilities.=C2=A0 That way the most network elements ca=
n
        implement MUD.=C2=A0 Question: is a time-based ACL common on a ho=
me
        router?=C2=A0 2nd question: what would happen to the policy if a =
part
        of it is not implementable?=C2=A0 It might be possible to put som=
e
        #ifdef-like capability in there, but that leads to the final
        design criterion..
    • 
      
  • Keep it simple for the manufacturers, at least for the first
        version.=C2=A0 If they need to scratch their heads too much they'=
ll
        just give up.
    • 
    

    
Eliot

    


    

  


--------------1FDB536B51AC3B15E9EF5C3F--

--MuqEDUj7jbBpek96MpcVLbAHrrJH2WaXG--

--DFLefJJd358QUXej2kBvmgwsbFHEGDhBW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJXPCTeAAoJEIe2a0bZ0nozYI4H/iOkaPNSoQYDLrdRm7maoNBB
XdSQrGhkBy3dp1KdsxA5pWxsG+yNQjRnyf2cKjNSlSt4BMhhTutIEcDSfLxmctA4
80rfeyiAgK6OULgav7nz6MCBFG0HyI3EzG1462DVtOjdjP7j2eRFcnyLSz4iSCMj
mdAXKDRUolttq3QWRcaRwMk3wqPrd0RPHRV0bmLdydmlw1FQhwAEnyp1NVesBtpV
k3MBMwYbKCvT9wlSmM64SXBKKe+QhWt1H95cx+a/tPu7ylj2OttQprLCVHoawLhT
qq0LMf0pzdemjDk2T7hPXsTxQ6T9JE4JwdixfgIAtj57eHb+QI3LVLy5LXnm+y4=
=btAA
-----END PGP SIGNATURE-----

--DFLefJJd358QUXej2kBvmgwsbFHEGDhBW--


From nobody Wed May 18 03:51:41 2016
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 E07A212D0D9; Wed, 18 May 2016 03:51:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160518105137.14689.96067.idtracker@ietfa.amsl.com>
Date: Wed, 18 May 2016 03:51:37 -0700
Archived-At: 
Cc: netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-rfc6020bis@ietf.org
Subject: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 10:51:38 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-netmod-rfc6020bis-12: 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-rfc6020bis/



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


- I'm not sure I properly understand what the rpc and action
statements really do, but can an action statement result in
sensitive information being in a place in the model that
previously only contained non-sensitive information? If so,
does that warrant a mention in the security considerations,
like the existing one about RPCs? (I mean the 3rd para of
section 17.) 

- anydata (section 7.10) is new, right? Doesn't that mean
that new kinds of stuff (that might be dangerous) can be
found in a module? So if it's true that before yang 1.1 a
parser only had to be careful to parse XML correctly, and if
the addition of anydata means that a parser (via some
extension mechanism) might now be parsing say images, (say
via ImageMagick:-) then that'd likely create new potential
vulnerabilities and might be worth a mention in section 17.



From nobody Wed May 18 05:18:57 2016
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 D8F4F12D111; Wed, 18 May 2016 05:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 xva1LNMafyuy; Wed, 18 May 2016 05:18:53 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DBFA12D130; Wed, 18 May 2016 05:18:53 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4544593D; Wed, 18 May 2016 14:18:52 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MFhiljpJcQPf; Wed, 18 May 2016 14:18:39 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 May 2016 14:18:51 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C4D32004E; Wed, 18 May 2016 14:18: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 9uEDpMyocIVQ; Wed, 18 May 2016 14:18:49 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A54C20047; Wed, 18 May 2016 14:18:49 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 586A83AD85A4; Wed, 18 May 2016 14:18:49 +0200 (CEST)
Date: Wed, 18 May 2016 14:18:49 +0200
From: Juergen Schoenwaelder 
To: Stephen Farrell 
Message-ID: <20160518121849.GA5456@elstar.local>
Mail-Followup-To: Stephen Farrell , The IESG , draft-ietf-netmod-rfc6020bis@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org
References: <20160518105137.14689.96067.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160518105137.14689.96067.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod-chairs@ietf.org, The IESG , netmod@ietf.org, draft-ietf-netmod-rfc6020bis@ietf.org
Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 12:18:56 -0000

On Wed, May 18, 2016 at 03:51:37AM -0700, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-netmod-rfc6020bis-12: 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-rfc6020bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - I'm not sure I properly understand what the rpc and action
> statements really do, but can an action statement result in
> sensitive information being in a place in the model that
> previously only contained non-sensitive information? If so,
> does that warrant a mention in the security considerations,
> like the existing one about RPCs? (I mean the 3rd para of
> section 17.)

They define a signature of an RPC call. The rpc statement defines a
global RPC while an action defines an RPC that is tied to some data
object (a method in OO slang but YANG is not OO). Are RPC special from
a privacy perspective? I do not know, I guess multiple answers are
valid here (including no they aren't since they are not worse than
other YANG defined data objects but of course you can define RPCs that
are bad form a privacy perspective but this is equally true for
regular data objects or notifications so I am not sure RPCs are in any
way special).
 
> - anydata (section 7.10) is new, right? Doesn't that mean
> that new kinds of stuff (that might be dangerous) can be
> found in a module? So if it's true that before yang 1.1 a
> parser only had to be careful to parse XML correctly, and if
> the addition of anydata means that a parser (via some
> extension mechanism) might now be parsing say images, (say
> via ImageMagick:-) then that'd likely create new potential
> vulnerabilities and might be worth a mention in section 17.

YANG defined data can be encoded in XML (the original encoding) but
also in JSON and people are working on CBOR. In YANG 1 we had anyxml,
which is problematic with other encodings since it is 'any XML' not
not 'any YANG-defined data' and hence we now have anydata, which means
'any YANG-defined data'. This means anydata is a subset of anyxml if
you use XML encoding. anydata is more restictive than anyxml and no it
anydata does not open the floor to let parsers parse image format or
anything like that.

/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 May 18 05:49:49 2016
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 A58EC12D144; Wed, 18 May 2016 05:49:48 -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 GewLp1kLbYub; Wed, 18 May 2016 05:49:43 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9261A12D0ED; Wed, 18 May 2016 05:49:42 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 977A61CC0230; Wed, 18 May 2016 14:49:43 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Suresh Krishnan 
In-Reply-To: <20160518065843.GB5141@elstar.local>
References: <20160518035920.24734.39237.idtracker@ietfa.amsl.com> <20160518065843.GB5141@elstar.local>
User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 18 May 2016 14:49:43 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netmod@ietf.org, draft-ietf-netmod-rfc6020bis@ietf.org
Subject: Re: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 12:49:48 -0000

Juergen Schoenwaelder  writes:

> On Tue, May 17, 2016 at 08:59:20PM -0700, Suresh Krishnan wrote:
>> Suresh Krishnan has entered the following ballot position for
>> draft-ietf-netmod-rfc6020bis-12: 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-rfc6020bis/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Meta comment:
>> 
>> Shouldn't this document obsolete RFC6060. There is no Obsoletes: tag in
>> the draft
>
> I guess this is because there are a couple of RFCs that depend on
> RFC6020 and so we can't retire RFC6020 right now.
>
>> Section 4.2.4:
>> 
>> s/A reference a data tree node/A reference to a data tree node
>> 
>> Section 9.4.7:
>> 
>> It is not clear why the following refinement is illegal. Can you
>> clarify?
>> 
>>      type my-base-str-type {
>>        // illegal length refinement
>>        length "1..999";
>>      }
>>
>
> Because my-base-str-type is restricted to length "1..255" and you
> can't enlarge the length restriction in a refinement.
>
>> IANA considerations:
>> 
>> Not sure what is the correct method for doing this in -bis documents, but
>> I would have expected a note that instructs IANA to switch references to
>> RFC6020 in IANA registries over to this one.
>
> This is what the WG originally thought but then we got advice that the
> original IANA allocation should stay in force...

Right, and this is also, I believe, a specific reason why 6020 cannot be
obsoleted.

Lada

>
> /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

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


From nobody Wed May 18 07:23:22 2016
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 0C31812D50F; Wed, 18 May 2016 07:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.948
X-Spam-Level: 
X-Spam-Status: No, score=-15.948 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=-1.426, 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 JMRMtWsowIrU; Wed, 18 May 2016 07:23:08 -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 412F612D506; Wed, 18 May 2016 07:23:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2841; q=dns/txt; s=iport; t=1463581387; x=1464790987; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=lrLjUNAXHj5cVMcl7HFtSVM5VEQo3PFO854eFaCr6mc=; b=bElAvOq/vf3qZSikjmV7BVjW/PritBJQU7fuUVzpek3iiSUqdUKHzBuy 3mqQpr1s/5Lmmo4hPeVQQ7MGbPkgp2/0LYcoVAsTqpwHMy3S667otsB8L hAkfkHe1zZJK6QTXKBYnqeNPaqc9tk5+gsOQhJKNwUyqGPOhO4Fae22Dk g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQDneTxX/xbLJq1ehAx+t2SCDwENg?= =?us-ascii?q?XUihW8CgW4UAQEBAQEBAWUnhEIBAQEDATg6BhELGAkWDwkDAgECAUUGAQwIAQG?= =?us-ascii?q?IIwgOwyEBAQEBAQEBAQEBAQEBAQEBAQEBGQWGJYRNhBERAYV1AQSHf5AshgCII?= =?us-ascii?q?IFphE+DCIVaj0keAQFCgjiBNzoyAYZQgTUBAQE?=
X-IronPort-AV: E=Sophos;i="5.26,329,1459814400"; d="scan'208";a="677243170"
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; 18 May 2016 14:23:05 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4IEN4ej032426; Wed, 18 May 2016 14:23:05 GMT
To: Suresh Krishnan , The IESG ,  draft-ietf-netmod-rfc6020bis@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org
References: <20160518035920.24734.39237.idtracker@ietfa.amsl.com> <20160518065843.GB5141@elstar.local>
From: Benoit Claise 
Message-ID: <573C7AC8.1070500@cisco.com>
Date: Wed, 18 May 2016 16:23:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20160518065843.GB5141@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 14:23:10 -0000

On 5/18/2016 8:58 AM, Juergen Schoenwaelder wrote:
> On Tue, May 17, 2016 at 08:59:20PM -0700, Suresh Krishnan wrote:
>> Suresh Krishnan has entered the following ballot position for
>> draft-ietf-netmod-rfc6020bis-12: 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-rfc6020bis/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Meta comment:
>>
>> Shouldn't this document obsolete RFC6060. There is no Obsoletes: tag in
>> the draft
> I guess this is because there are a couple of RFCs that depend on
> RFC6020 and so we can't retire RFC6020 right now.
Right.
This is also covered in the writeup.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

   No. YANG 1.0 [RFC6020] is not expected to change its status since
   there are data models on the standards-track that conform to YANG
   1.0. YANG 1.0 may be considered for retirement once all data models
   have naturally been updated to a future version of YANG.

Regards, Benoit

>
>> Section 4.2.4:
>>
>> s/A reference a data tree node/A reference to a data tree node
>>
>> Section 9.4.7:
>>
>> It is not clear why the following refinement is illegal. Can you
>> clarify?
>>
>>       type my-base-str-type {
>>         // illegal length refinement
>>         length "1..999";
>>       }
>>
> Because my-base-str-type is restricted to length "1..255" and you
> can't enlarge the length restriction in a refinement.
>
>> IANA considerations:
>>
>> Not sure what is the correct method for doing this in -bis documents, but
>> I would have expected a note that instructs IANA to switch references to
>> RFC6020 in IANA registries over to this one.
> This is what the WG originally thought but then we got advice that the
> original IANA allocation should stay in force...
Yes, we checked that with Michelle Cotton.

Regards, Benoit
>
> /js
>


From nobody Wed May 18 07:39:34 2016
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 805A612D535; Wed, 18 May 2016 07:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 YyBnMToQDIVv; Wed, 18 May 2016 07:39:22 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 65EAB12D516; Wed, 18 May 2016 07:39:22 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 3A3E31AE018B; Wed, 18 May 2016 16:39:20 +0200 (CEST)
Date: Wed, 18 May 2016 16:39:39 +0200 (CEST)
Message-Id: <20160518.163939.2035498436304576381.mbj@tail-f.com>
To: stephen.farrell@cs.tcd.ie
From: Martin Bjorklund 
In-Reply-To: <20160518105137.14689.96067.idtracker@ietfa.amsl.com>
References: <20160518105137.14689.96067.idtracker@ietfa.amsl.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod-chairs@ietf.org, iesg@ietf.org, netmod@ietf.org, draft-ietf-netmod-rfc6020bis@ietf.org
Subject: Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 14:39:28 -0000

"Stephen Farrell"  wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-netmod-rfc6020bis-12: 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-rfc6020bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - I'm not sure I properly understand what the rpc and action
> statements really do, but can an action statement result in
> sensitive information being in a place in the model that
> previously only contained non-sensitive information? If so,
> does that warrant a mention in the security considerations,
> like the existing one about RPCs? (I mean the 3rd para of
> section 17.) 

I think you are right, and we should do:

OLD:

  Data modeled in YANG might contain sensitive information. RPCs
  or notifications defined in YANG might transfer sensitive information.

NEW:

  Data modeled in YANG might contain sensitive information. RPCs, actions,
  and notifications defined in YANG might transfer sensitive information.



/martin


From nobody Wed May 18 15:01:02 2016
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 DCFDC12D73A; Wed, 18 May 2016 13:44:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Liaison Statement Management Tool 
To: "Benoit Claise" , =?utf-8?b?IkrDvHJnZW4gU2Now7Zud8OkbGRlciI=?= , "Joel Jaeggli" , "Tom Nadeau" , "Mahesh Jethanandani" , "Mehmet Ersue" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160518204443.14700.50752.idtracker@ietfa.amsl.com>
Date: Wed, 18 May 2016 13:44:43 -0700
Archived-At: 
X-Mailman-Approved-At: Wed, 18 May 2016 15:01:02 -0700
Cc: =?utf-8?q?hanandani=40gmail=2Ecom=3E=2C_=22Mehmet_Ersue=22_=3Cmehmet=2Eersu?=@ietfa.amsl.com, =?utf-8?b?PGpvZWxqYUBib2d1cy5jb20+LCAiS2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlw?=@ietfa.amsl.com, =?utf-8?q?choenwaelder=40jacobs-university=2Ede=3E=2C_=22Joel_Jaeggli=22_?=@ietfa.amsl.com, =?utf-8?q?rope=22_=3Cdavid=2Esinicrope=40ericsson=2Ecom=3E=2C_=22The_IETF_C?=@ietfa.amsl.com, =?utf-8?b?IiA8bmV0bW9kQGlldGYub3JnPiwgIk1haGVzaCBKZXRoYW5hbmRhbmkiIDxtamV0?=@ietfa.amsl.com, =?utf-8?b?aGFpciIgPGNoYWlyQGlldGYub3JnPiwgIkJlbm9pdCBDbGFpc2UiIDxiY2xhaXNl?=@ietfa.amsl.com, =?utf-8?b?IkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0PiwgIkRhdmlkIFNpbmlj?=@ietfa.amsl.com, =?utf-8?b?PG5ldGNvbmZAaWV0Zi5vcmc+LCAiSsO8cmdlbiBTY2jDtm53w6RsZGVyIiA8ai5z?=@ietfa.amsl.com, =?utf-8?q?=40cisco=2Ecom=3E=2C_=22Network_Configuration_Discussion_List=22_?=@ietfa.amsl.com, =?utf-8?q?er=2Enet=3E=2C_=22NETCONF_Data_Modeling_Language_Discussion_List?=@ietfa.amsl.com, =?utf-8?b?ZUBub2tpYS5jb20+?=@ietfa.amsl.com
Subject: [netmod] New Liaison Statement, "Liaison to IETF on YANG Models to enable G.fast deployments"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 20:44:44 -0000

Title: Liaison to IETF on YANG Models to enable G.fast deployments
Submission Date: 2016-05-18
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1476/

From: "Michael Fargano" 
To: Benoit Claise ,Joel Jaeggli ,Mahesh Jethanandani ,Mehmet Ersue ,Jürgen Schönwälder , Tom Nadeau 
Cc: Joel Jaeggli ,Mahesh Jethanandani ,David Sinicrope ,Jürgen Schönwälder ,Kent Watsen ,Mehmet Ersue ,NETCONF Data Modeling Language Discussion List ,The IETF Chair ,Lou Berger ,Benoit Claise ,Network Configuration Discussion List ,
Response Contacts: 
Technical Contacts: 
Purpose: For information

Body: The Broadband Forum is developing YANG models to meet the end 2016/early 2017
G.fast deployment timeline announced by several service providers. Broadband Forum
practice is to base its YANG work on existing IETF YANG models and expertise.

In the Broadband Forum meeting of 18-22 April, the Fiber to the Distribution Point (FTTdp)
Work Area agreed to work on developing YANG models based on draft-entitydt-netmodentity
& draft-wilton-netmod-intf-ext-yang for G.fast deployments meeting the above
timelines. Given our interest in these drafts, participants will work within the IETF
according to IETF processes, to help progress them. Please keep us apprised of progress
of these drafts.

Further, we would like to inform you that our FTTdp Work Area is defining YANG models
for Broadband Forum specific context and use cases for :

- forwarding/QoS and required protocols (e.g. layer 2 multicast model & DHCP)
- bulk data collection (evaluating draft-ietf-netconf-yang-push and related work),
- software image management,
- operational states (evaluating draft-ietf-netmod-opstate-reqs and related work)

Once the models reach a level of maturity we plan to share these with IETF for review and
comment. Comments from IETF may be made via a liaison or BBF members may
comment directly.

Please see below for information on our next meetings.

Sincerely,
Michael Fargano,
Broadband Forum Technical Committee Chair
Attachments:

    Liaison to IETF on YANG Models to enable G.fast deployments
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-05-18-broadband-forum-ops-netconf-netmod-liaison-to-ietf-on-yang-models-to-enable-gfast-deployments-attachment-1.pdf


From nobody Thu May 19 06:52:13 2016
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 0488612D144; Thu, 19 May 2016 06:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 23xaZ6_LD_cb; Thu, 19 May 2016 06:51:58 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC8212D166; Thu, 19 May 2016 06:51:58 -0700 (PDT)
X-AuditID: c6180641-f796f6d000000e1e-49-573dc4ca8a57
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 13.5E.03614.AC4CD375; Thu, 19 May 2016 15:51:06 +0200 (CEST)
Received: from EUSAAMB108.ericsson.se ([147.117.188.125]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Thu, 19 May 2016 09:51:56 -0400
From: Suresh Krishnan 
To: Ladislav Lhotka , Juergen Schoenwaelder 
Thread-Topic: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)
Thread-Index: AQHRsLmsxnxAlC3iOk+c7wd3rn3CHg==
Date: Thu, 19 May 2016 13:51:55 +0000
Message-ID: 
References: <20160518035920.24734.39237.idtracker@ietfa.amsl.com> <20160518065843.GB5141@elstar.local> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.12]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXRPuO6pI7bhBpvPWFrcPvGTyeLqxp+M FhdWzWWzmH+xkdWBxWPJkp9MHhsOeHpsunyHMYA5issmJTUnsyy1SN8ugSuj4cVlpoIeiYpv 3buYGhgfCHcxcnJICJhIPLhxjA3CFpO4cG89kM3FISRwlFFiast5JghnOaPEtQNv2UGq2IA6 Nuz8zARiiwgkS7QcmMYKYjML1Ei8fT+PBcQWFsiUWLGmkxmiJkti89sdbBC2nkTLhTVgNouA qkTTiV1gM3kFfCUWn/rOArGsh1Fiw/83YIMYgU76fmoNE8QCcYlbT+YzQZwqILFkz3lmCFtU 4uXjf6wQtpLEnNfXmCHqdSQW7P7EBmFrSyxb+JoZYpmgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsoqRo7S4ICc33chwEyMwWo5JsDnuYNzb63mIUYCDUYmHV0HONlyINbGsuDL3EKMEB7OS CO+qw0Ah3pTEyqrUovz4otKc1OJDjNIcLErivPovFcOFBNITS1KzU1MLUotgskwcnFINjNFN dztmlSlW68kZxx2s6thefX1vf4eqlwdL4qEbQbLLZ9vv8nu8bMfB1XmlX5I0TRrXbsjWN/Az qZY/97Lo6HHfxW4Xd5Zpl0ytl62suMh4W/B+v16uS6jsouaGPwxrVmb/VG11s57RUbrq84yL nzzZjE5eL9jxKEn5b+mLiVKMt5ezXVxxUYmlOCPRUIu5qDgRAJXbeCmSAgAA
Archived-At: 
Cc: "netmod@ietf.org" , "draft-ietf-netmod-rfc6020bis@ietf.org" 
Subject: Re: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-rfc6020bis-12: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 May 2016 13:52:12 -0000

Thanks Juergen and Lada for the explanation. I now understand the motivatio=
ns=0A=
not to obsolete.=0A=
=0A=
Regards=0A=
Suresh=0A=
=0A=
On 05/18/2016 08:49 AM, Ladislav Lhotka wrote:=0A=
> Juergen Schoenwaelder  writes:=0A=
> =0A=
>> On Tue, May 17, 2016 at 08:59:20PM -0700, Suresh Krishnan wrote:=0A=
>>> Suresh Krishnan has entered the following ballot position for=0A=
>>> draft-ietf-netmod-rfc6020bis-12: No Objection=0A=
>>>=0A=
>>> When responding, please keep the subject line intact and reply to all=
=0A=
>>> email addresses included in the To and CC lines. (Feel free to cut this=
=0A=
>>> introductory paragraph, however.)=0A=
>>>=0A=
>>>=0A=
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht=
ml=0A=
>>> for more information about IESG DISCUSS and COMMENT positions.=0A=
>>>=0A=
>>>=0A=
>>> The document, along with other ballot positions, can be found here:=0A=
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/=0A=
>>>=0A=
>>>=0A=
>>>=0A=
>>> ----------------------------------------------------------------------=
=0A=
>>> COMMENT:=0A=
>>> ----------------------------------------------------------------------=
=0A=
>>>=0A=
>>> Meta comment:=0A=
>>>=0A=
>>> Shouldn't this document obsolete RFC6060. There is no Obsoletes: tag in=
=0A=
>>> the draft=0A=
>>=0A=
>> I guess this is because there are a couple of RFCs that depend on=0A=
>> RFC6020 and so we can't retire RFC6020 right now.=0A=
>>=0A=
>>> Section 4.2.4:=0A=
>>>=0A=
>>> s/A reference a data tree node/A reference to a data tree node=0A=
>>>=0A=
>>> Section 9.4.7:=0A=
>>>=0A=
>>> It is not clear why the following refinement is illegal. Can you=0A=
>>> clarify?=0A=
>>>=0A=
>>>      type my-base-str-type {=0A=
>>>        // illegal length refinement=0A=
>>>        length "1..999";=0A=
>>>      }=0A=
>>>=0A=
>>=0A=
>> Because my-base-str-type is restricted to length "1..255" and you=0A=
>> can't enlarge the length restriction in a refinement.=0A=
>>=0A=
>>> IANA considerations:=0A=
>>>=0A=
>>> Not sure what is the correct method for doing this in -bis documents, b=
ut=0A=
>>> I would have expected a note that instructs IANA to switch references t=
o=0A=
>>> RFC6020 in IANA registries over to this one.=0A=
>>=0A=
>> This is what the WG originally thought but then we got advice that the=
=0A=
>> original IANA allocation should stay in force...=0A=
> =0A=
> Right, and this is also, I believe, a specific reason why 6020 cannot be=
=0A=
> obsoleted.=0A=
> =0A=
> Lada=0A=
> =0A=
>>=0A=
>> /js=0A=
>>=0A=
>> -- =0A=
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH=0A=
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany=
=0A=
>> Fax:   +49 421 200 3103         =0A=
>>=0A=
>> _______________________________________________=0A=
>> netmod mailing list=0A=
>> netmod@ietf.org=0A=
>> https://www.ietf.org/mailman/listinfo/netmod=0A=
> =0A=
=0A=


From nobody Mon May 23 05:31:12 2016
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 D0B6A12D808 for ; Mon, 23 May 2016 05:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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_H2=-0.001, 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 OnOO7nGqQTs0 for ; Mon, 23 May 2016 05:31:09 -0700 (PDT)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id A484112D617 for ; Mon, 23 May 2016 05:31:08 -0700 (PDT)
Received: (qmail 24003 invoked by uid 0); 23 May 2016 12:31:04 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 23 May 2016 12:31:04 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id xoWz1s00C2SSUrH01oX2rT; Mon, 23 May 2016 06:31:02 -0600
X-Authority-Analysis: v=2.1 cv=QND7GG7L c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=yrkiwgmsf1kA:10 a=FESzNVShNTJv_CLMlhEA:9 a=Ax7nxAN1x62JlpGz:21 a=cxTB7siRZhgevGeg:21 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:In-Reply-To:MIME-Version :Date:Message-ID:Cc:From:References:To:Subject; bh=n02JZZbpzRmloHeKUC9C2aCIn99X0QCPqveQtVnx5iY=; b=DGVxwt6qLAFAOcL3Y6gG5uc1D+ H2OE20nJXKOK9fIeeHTltdozvHj4oFSZuQ26/n2yNcdpZqduB0tluBY58BLo/RmldbQKVsXpP5UUn 9HHSYqS8+JCna9X1KAkazmU1I;
Received: from box313.bluehost.com ([69.89.31.113]:43762 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b4p0f-0006xX-4r; Mon, 23 May 2016 06:31:01 -0600
To: Ladislav Lhotka 
References: 
From: Lou Berger 
Message-ID: <5742F7FB.4040803@labn.net>
Date: Mon, 23 May 2016 08:30:51 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] compact versus iterative representation of the overall schema
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 12:31:11 -0000

Hi Lada,
    I looks like no one really jumped on this one -- so better late than
never ...

When looking at the question below, we should consider the uses cases. 
I'm particularity interested (as a contributor) in the use case of
nested mounts (NIs mounted within LNEs), as well as the case if  models
that will only permit mounting of specific other models vs generically
mounting any model.

On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
> Hi,
>
> with a schema mount mechanism in place, there are two different options
> for constructing the overall schema (their combinations are possible,
> too):
>
> 1. Define schema mount as an extension of YANG library so that it
> defines YANG modules, revisions, features and deviations as before but
> also the way how they are combined into a hierarchical structure of
> schemas.

I think this only makes sense if this is scoped in some way.  For
example, with LNEs, the parent/host server may not have visibility into
the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And even if
does, you have to consider the cases of mounted models contained within
mounted models.

>
> 2. Apart from YANG Library data, the server just specifies the mount
> points. A client of an NM protocol is expected to fetch a new instance
> of YANG library and/or subordinate mount points as state data from a
> well-known location under each mount point.

I think this depends on the use case.  For LNEs, I think this is right. 
For some of the other possible use cases being discussed only a specific
model can be mounted.

> I think that #1 should be available (alone or along with #2) because
> there are cases when YANG is used as a data modelling language outside
> the context of a NM protocol – Eliot Lear's MUD presentation is one
> example.

I think we (the rtg yang arch dt) had envisioned  something closer to
2.  And as you say, an approach that also includes a properly scoped 1
is possible.

Lou

> Lada
>



From nobody Mon May 23 06:42:58 2016
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 1B81F12B034 for ; Mon, 23 May 2016 06:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 HdhjPXdIYcUQ for ; Mon, 23 May 2016 06:42: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 1DF6712D199 for ; Mon, 23 May 2016 06:42:51 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 2B25B1AE0118; Mon, 23 May 2016 15:42:49 +0200 (CEST)
Date: Mon, 23 May 2016 15:43:09 +0200 (CEST)
Message-Id: <20160523.154309.848500367505009627.mbj@tail-f.com>
To: worley@ariadne.com
From: Martin Bjorklund 
In-Reply-To: <877feyrdz9.fsf@hobgoblin.ariadne.com>
References: <877feyrdz9.fsf@hobgoblin.ariadne.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 13:42:57 -0000

Hi,

Thank you for your thorough review!  Comments inline.

worley@ariadne.com (Dale R. Worley) wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-netmod-rfc6020bis-12
> Reviewer: Dale R. Worley
> Review Date: 2016-05-12
> IETF LC End Date: 2016-05-12
> IESG Telechat date: 2016-05-19
> 
> Summary: This draft is basically ready for publication, but has nits
> that should be fixed before publication.  I have a large number of
> editorial comments.  A few of these comments address technical
> uncertainties, but I strongly suspect that the technical issues have
> long since been fixed, as this is a revision of Yang 1, and the
> only needed work is clarifying the text.
> 
> - Abstract
> 
> This Abstract does not list what the document does.  E.g., define Yang
> 1.1.  Also might help to mention upward-incompatibility.  Basically,
> go through section 1 to see what should be in Abstract.  Perhaps:
> 
>    YANG is a data modeling language originally designed to model
>    configuration and state data manipulated by the Network
>    Configuration Protocol (NETCONF), NETCONF remote procedure calls,
>    and NETCONF notifications.  This document describes the syntax and
>    semantics of version 1.1 of the YANG language.  YANG version 1.1 is
>    a maintenance release of the YANG language, addressing ambiguities
>    and defects in the original specification.  There are a small
>    number of upward-incompatibilities from Yang 1.  This document also
>    describes how a data model defined in a YANG module is encoded in
>    the Extensible Markup Language (XML), and how NETCONF operations
>    are used to manipulate the data.

Ok, but note that the abstract was changed a bit in -12, so
incorporapting your proposed changes it would be:

  YANG is a data modeling language used to model configuration data,
  state data, remote procedure calls, and notifications for network
  management protocols. This document describes the syntax and
  semantics of version 1.1 of the YANG language.  YANG version 1.1 is
  a maintenance release of the YANG language, addressing ambiguities
  and defects in the original specification.  There are a small number
  of backward-incompatibilities from YANG version 1.  This document also
  specifies the YANG mappings to the Network Configuration Protocol
  (NETCONF).

> - section 1.1
> 
> The incompatibilities should be marked whether the old, incompatible
> usage always causes an error "at compile time", "at run time", or
> changed behavior.

Ok, but I'd like to avoid the term "compile-time" here.

> A number of later items seem to be upward-incompatibilities but not
> marked as such:
> 
>    o  Made the "yang-version" statement mandatory.

This is actually not backward incompatible, since if there is
yang-version it defaults to "1", which is specified in RFC 6020.
Maybe this is better:

     o  Made the "yang-version" statement mandatory in YANG version
        "1.1".

>    o  Made noncharacters illegal in the built-in type "string".

Yes this is in fact backwards incompatible in run-time.

How about:

   The following changes are not backwards compatible with YANG version
   1:

   o  Changed the rules for the interpretation of escaped characters in
      double quoted strings.  This is an backwards incompatible change
      from YANG version 1.  A module that uses a character sequence that
      is now illegal must change the string to match the new rules.  See
      Section 6.1.3 for details.

   o  An unquoted string cannot contain any single or double quote
      characters.  This is an backwards incompatible change from YANG
      version 1.  A module that uses such quote characters must change
      the string to match the new rules.  See Section 6.1.3 for details.

   o  Made noncharacters illegal in the built-in type "string".  This
      change affects the run-time behavior of YANG-based protocols.

> - section 3
> 
>    o  identifier: Used to identify different kinds of YANG items by
>       name.
> 
> This item, unlike the others, does not start with a noun phrase.
> Perhaps, "A string used to ..."?

Ok.

>    o  leaf: A data node that exists in at most one instance in the data
>       tree.  A leaf has a value but no child nodes.
> 
> I'm not sure that this is correct; a leaf schema node inside a list
> schema node can have many instances in a data tree.  The real
> criterion is that it has a value but no child nodes.

Would "one instance per parent node" work?

>    o  leaf-list: Like the leaf node but defines a set of uniquely
>       identifiable nodes rather than a single node.  Each node has a
>       value but no child nodes.
> 
> Better to say a "sequence of nodes".  Without the concept that the
> nodes are a sequence (and can be identified by location within the
> sequence), there's no assurance that the nodes are uniquely
> identifiable (since they can have duplicate values in state data).

I think we should do:

    o  leaf-list: Like the leaf node but defines a sequence of
       nodes rather than a single node.  Each node has a
       value but no child nodes.

>    o  mandatory node: A mandatory node is one of:
>       ...
>       *  A container node without a "presence" statement, which has at
>          least one mandatory node as a child.
> 
> Perhaps replace the comma with "and"?

Ok.

> It would be useful to insert a note somewhere that all data is either
> "configuration" or "state" data.  It's hard to learn that now, because
> the terms "configuration data" and "state data" are defined only by
> reference to RFC 6241.

But this is not strictly correct.  For example RPC input is neither
config nor state.  Section 3 has:

  o data tree: An instantiated tree of any data modeled with YANG,
    e.g., configuration data, state data, combined configuration and
    state data, RPC or action input, RPC or action output, or
    notification.

> There are general issues with the terms "namespace" and "prefix".
> 
> "namespace" is used to identify both the namespaces of identifiers in
> Yang source (6.2.1) as well as XML namespaces in the XML encodings of
> data trees.  It would make things clearer if all uses that refer to
> XML namespaces used the form "XML namespace".
> 
> "prefix" is used to name both identifier prefixes in Yang source code
> and XMLNS prefixes.  Worse, the prefix statement is used to declare
> one string, which is then both the prefix used within the Yang source
> code and also the preferred (but not mandatory!) XMLNS prefix used to
> refer to the associated XML namespace.  It would help if "XMLNS
> prefix" was used whenever talking specifically about prefixes used in
> XML.  See also comments on section 7.1.4.

See my answer below to the comments on 7.1.4.

> - section 3.1
> 
> There is an overall question regarding whitespace in XML in
> "non-significant" places.  Is it allowed in the XML representation of
> data trees?  And if so, precisely what whitespace is allowed?  Also,
> to what degree is the whitespace shown in examples what is allowed on
> the wire, and to what degree is it there just to make the example
> easier to read?  (It's possible that XML has implemented some sort of
> global solution for the issue of non-significant whitespace, but back
> when I was using it regularly, there was none.)

Good catch!  Interesting that noone has found this before!

I think we need to say that whitespace is insignificant between
elements.  So I propose to add a paragraph to the end of 7.5.7
(container XML encoding rules):

NEW:

  Any whitespace between the subelements to the container is
  insignificant, i.e., an implementation MAY insert whitespace
  characters between subelements.

and insert a fourth paragraph in 7.8.5 (list XML encoding rules):

NEW:

  Any whitespace between the subelements to the list entry is
  insignificant, i.e., an implementation MAY insert whitespace
  characters between subelements.

> - section 4.1
> 
>    YANG structures data models into modules and submodules.  A module
>    can import data from other external modules, and include data from
>    submodules.
> 
> "data" has other meanings.  Perhaps change to "elements of models" or
> "definitions"?

Yes; I changed to "definitions".

>    The instantiation of these groupings can refine or augment the
>    nodes, allowing it to tailor the nodes to its particular needs.
> 
> "instantiate" is used with two meanings, the more common one being
> the relationship between nodes and data tree elements, and the
> insertion of a grouping into a node tree.  E.g., see the definitions
> of "data tree" and "uses" in section 3.  It would make life easier if
> there was a different word for the second meaning -- perhaps "use"?
> In any case, this particular sentence has no context to disambiguate
> the two meanings.

Ok, I'll do s/instantiation/usage/.

>    The conversion from YANG to
>    YIN is lossless, so content in YIN can be round-tripped back into
>    YANG.
> 
> This is almost certainly not true.  But there is no loss of Yang
> semantics, or something like that, and that could be stated.

NEW:

    The conversion from YANG to YIN is semantically lossless, so
    content in YIN can be round-tripped back into YANG.


>    YANG strikes a balance between high-level data modeling and low-level
>    bits-on-the-wire encoding.  The reader of a YANG module can see the
>    high-level view of the data model while understanding how the data
>    will be encoded on-the-wire.
> 
> Is that true in cases where the NETCONF XML wire encoding is not
>    used?

No, you're right, now that people also do binary encodings of YANG
data.

I think we can remove this paragraph.

> Or is that encoding mandatory in some sense, even if the environment
> is not NETCONF?  If Yang is intended to describe data which will
> *always* be expressed in XML in a certain way, that fact should be
> introduced earlier in the document.
> 
> - section 4.2.1
> 
> Section should start with a definition of "module" and what modules
> are used for.  The current text is a list of details about "module"
> without telling what the *point* of a module is.

Ok, I agree that some additional text is needed.  Howabout:

  YANG data models are defined in modules.  A module contains a
  collection of related definitions.

>    A module may be divided into submodules, based on the needs of the
>    module owner.
> 
> There is a global problem that the reader needs to know the
> relationships between "module" and "submodule", but those are not
> stated explicitly anywhere.  (This is probably a candidate for
> inclusion in section 3.)  AFAICT:
> 
>     A module
>     - is defined by a module statement in its own file
>     - defines a group of data trees, etc. that can be used by NETCONF
>     - "includes" the submodules that "belong to" it
> 
>     A submodule
>     - is defined by a submodule statement in its own file
>     - defines things that can be used in the module statement
>     - "belongs to" a single module, which is specified in the "belongs-to"
>       substatement of the submodule statement
>     - does NOT have submodules of its own
> 
> "module owner" is not defined in section 3.  And is it the right term;
> is there an ownership relationship, or does this just mean "whoever
> wrote the module"?

The latter; I propose s/module owner/module designer/

> Or is there an understood social context in which
> a module will be written that needs to be paid attention to in this
> document?  (E.g., regarding allocation of XML namespaces.)
> 
> There is also the risk of misunderstanding between "own" and "belong
> to" -- a submodule "belongs to" its module but the module doesn't
> "own" the submodule.
> 
> Also, the module isn't "divided" into submodules, since there is
> always a module statement.
> 
> Perhaps a better version of this paragraph is:
> 
>    A module may have portions of its definition separated into
>    submodules

Ok.

> , based on the needs of the module writer.  This
>    separation is not visible outside the text of the module and
>    submodules; neither importation into other modules nor the data
>    encodings are affected.
> 
> --
> 
>    The "import" statement allows a module or submodule to reference
>    material defined in other modules.
> 
> There is no definition of "material".  Clearly, it means "things that
> can be referenced", but this points out that there is no term for
> "things that can be referenced", but it would be useful to have one.
> Then one could state, e.g., that a module can reference ???s defined
> in its submodules, or it can reference ???s defined in modules that it
> imports.

I propose s/material/definitions/  - this term is used elsewhere.

>    The "include" statement is used by a module to incorporate the
>    contents of its submodules into the module.
> 
> In a sense, "include" isn't really like "import", because it's not
> optional; it's the mandatory reverse-link of the "belongs-to"
> statement in the submodule.  (The module and all submodules
> automatically have access to definitions in all submodules due to
> their relationship.)
> 
> And that has been the cause of a lot of my confusion on this topic;
> "include" and "import" are discussed together in many places, making
> it unclear that "a module includes a submodule" is really a *static*
> relationship, not a statement that the programmer could insert or not
> according to need.  A clearer statement would be:
> 
>    The "include" statement is used in a module to identify each
>    submodule that belongs to it.

Ok.


>  The module's definitions have access
>    to the definitions in the submodule.

Although this is correct, I seems to be a bit out of place here, i.e.,
a bit too detailed for this overview chapter.


> It might be useful to define "include" and "belong to" in section 3.
> 
> - section 4.2.2.1
> 
>      leaf host-name {
>        type string;
>        description
>          "Hostname for this system";
>      }
> 
> It might be useful here to provide a forward reference to 6.3 as a
> reference for the syntax of statements.  If you don't already know the
> syntax, it can be hard to figure out that "host-name" is the node's
> identifier.  Or perhaps the forward reference could be put at the end
> of 4.2.2.

Ok, I added :
 
   The syntax of YANG
   statements is defined in Section 6.3.

to the end of 4.2.2.

> - section 4.2.2.3
> 
>    A container may contain any number of child nodes of any type
>    (leafs, lists, containers, leaf- lists, actions, and
>    notifications).
> 
> If the plural of "leaf" is "leafs" (rather than the standard English
> "leaves"), that should be noted in the entry in section 3.

Although I am not a native speaker of English I do know that the
normal plural is "leaves".  However, I also note that Merriam-Webster
lists both forms, and that the RFC Editor was ok with "leafs" when we
had this discussion for RFC 6020.

> - section 4.2.2.4
> 
>    A list defines a sequence of list entries.  Each entry is like a
>    structure or a record instance, and is uniquely identified by the
>    values of its key leafs.  A list can define multiple key leafs and
>    may contain any number of child nodes of any type (including leafs,
>    lists, containers etc.).
> 
> Each entry is like a *container*, which was just defined above, which
> might be a more intuitive way to describe it.

Ok.

> Perhaps "... is uniquely identified by the values of one or more
> specified leaf children, the key leafs."
> 
>    XML Encoding Example:
> 
>      
>        glocks
>        Goldie Locks
>        intruder
>      
>      
>        snowey
>        Snow White
>        free-loader
>      
>      
>        rzell
>        Rapun Zell
>        tower
>      
> 
> I note that this example, unlike the previous ones, is not a single
> XML element; there is no XML element that designates the list as a
> whole.

Correct.  This is just a snippet and as such it is not in itself a
well-formed XML document.

> That seems to be a general pattern in the XML encodings for
> Yang, that groups of elements can be defined in Yang, but the
> resulting set of elements is not wrapped in a single element in the
> XML.  That happens with lists (where each list element is an element
> but the list as a whole is not), leaf-list (where there is no element
> surrounding the repeated leaf element), groupings, and choices with
> their child cases.  Perhaps this is a general pattern in XML used for
> network management, but it's not quite what one would expect if one
> thinks of data structures in a programming language.  Perhaps it would
> be helpful to point out this pattern somewhere that global XML issues
> are described (e.g., whitespace issues).
> 
> - section 4.2.3
> 
>    YANG can model state data, as well as configuration data, based on
>    the "config" statement.  When a node is tagged with "config false",
>    its subhierarchy is flagged as state data.  In NETCONF, state data is
>    reported using the  operation, not the  operation.
>    Parent containers, lists, and key leafs are reported also, giving the
>    context for the state data.
> 
> Does this mean that  returns the state data and 
> returns the configuration data?  Or does  return both the state
> and configuration data?  Perhaps this is not really a question for
> this document, but if the behavior of  and  is
> mentioned, they should be described thoroughly.

I'll remove the references to  and .


> - section 4.2.4
> 
>    YANG has a set of built-in types, similar to those of many
>    programming languages, but with some differences due to special
>    requirements from the management domain.
> 
> "from the management domain" is awkward, and "domain" has no previous
> definition; better "requirements of network management".

Ok.

> 
>        | enumeration         | Enumerated strings                  |
> 
> Perhaps "one of an enumerated set of strings".

Ok.

>        | string              | Human-readable string               |
> 
> What does "human-readable" mean?  Can passwords be stored in such
> leafs?  Does this really mean "a string of Unicode characters"?
> Perhaps "character string" would be better.

Ok.

> - section 4.2.7
> 
>    YANG allows the data model to segregate incompatible nodes into
>    distinct choices using the "choice" and "case" statements.  The
>    "choice" statement contains a set of "case" statements that define
>    sets of schema nodes that cannot appear together.  Each "case" may
>    contain multiple nodes, but each node may appear in only one "case"
>    under a "choice".
> 
>    When a node from one case is created in the data tree, all nodes from
>    all other cases are implicitly deleted.  The server handles the
>    enforcement of the constraint, preventing incompatibilities from
>    existing in the configuration.
> 
>    The choice and case nodes appear only in the schema tree but not in
>    the data tree.  The additional levels of hierarchy are not needed
>    beyond the conceptual schema.
> 
> This description reads very oddly.  AFAICT, "choice" simply defines a
> union type, where each alternative is a container (usually called a
> structure or record).  Or rather, it's conceptually a container, but
> in an XML instance of data, there is no start-end tags for the
> structure as a whole (paralleling the lack of start-end tags for lists
> as a whole).  Once you state that, it's clear why there are "sets of
> schema nodes that cannot appear together".

I'm worried that if we describe "case" as a special kind of
"container" it will be pretty confusing.

> - section 4.2.8
> 
> It would help to give a general discussion of augmenting.  If one
> module augments another, is the augmented data definition part of the
> data structures defined by augmenting module or the augmented one?
> 
> If I've got it right, this module:
> 
>    module /system/login/user {
>      namespace "urn:user";
>      prefix "user";
> 
>      list user {
>        key "name";
>        leaf name {
>          type string;
>        }
>        leaf full-name {
>          type string;
>        }
>        leaf class {
>          type string;
>        }
>      }
>    }
> 
> gives this as the XML encoding of a typical data tree:
> 
>      
>        alicew
>        Alice N. Wonderland
>        drop-out
>        1024
>      

Did you mean:

      
        alicew
        Alice N. Wonderland
        drop-out
      

?

> whereas the *existence* (in some sense) of this module:
> 
>    module /system/login/user-augmenter {
>      namespace "urn:user-extension";
>      prefix "ext";
> 
>      augment /system/login/user {
>        when "class != 'wheel'";
>        leaf uid {
>          type uint16 {
>            range "1000 .. 30000";
>          }
>        }
>      }
>    }
> 
> changes the encoding of the data tree to:
> 
>      
>        alicew
>        Alice N. Wonderland
>        drop-out
>        1024
>      
> 
> What is it that triggers this action-at-a-distance?

The fact that the server implements both modules.

>    If a module augments another module, the XML encoding of the data
>    will reflect the prefix of the augmenting module.  For example, if
>    the above augmentation were in a module with prefix "other", the XML
>    would look like:
> 
> This is hard to interpret.  Better would be:
> 
>    If a module augments another module, the XML elements that are
>    added to the encoding are in the namespace of the augmenting
>    module

Yes this is better!

>    (which should preferentially be associated with the prefix of the
>    augmenting module).
> 
> The restriction is on the XML namespace of the new element, not its
> XMLNS prefix.

Right.

> - section 5.1
> 
>    The module is the base unit of definition in YANG.  A module defines
>    a single data model.  A module can define a complete, cohesive model,
>    or augment an existing data model with additional nodes.
> 
> What is the semantic content of "complete, cohesive"?  It seems like
> "defines a data model" is shorter and equally accurate.
> 
> If I understand Yang correctly, every module defines a data model
> (which may have no leafs!), but some also augment other data models.
> If that's so, the use of "or" is misleading, and it would be more
> accurate to say:
> 
>    The module is the base unit of definition in YANG.  A module
>    defines a single data model.  A module can also augment an existing
>    data model with additional nodes.
> 
> Then again, perhaps a module that defines no data nodes cannot be
> referenced as a data model.  If so, that should be stated.

I think the module still defines a "data model" even if it augments
another module, so your proposed text is fine.

>    Developers of YANG modules and submodules are RECOMMENDED to choose
>    names ...
> 
> "RECOMMENDED" is an adjective which qualifies the choice, not an
> adverb that qualifies the act of choosing.  I think you want
> "... SHOULD choose ...".  See RFC 2119.

Hmm.  Are you saying that if RECOMMENDED is used as an adverb then it
should not be used like this?  A quick grep on some RFCs gives quite a
few matches, e.g. this one from RFC 6353:

   Implementations are RECOMMENDED to support and use
   the contextEngineID discovery mechanism defined in [RFC5343].

Is this also not correct?

Can you give an example of a correct usage of RECOMMENDED?

>    A module uses the "include" statement to include all its submodules,
>    and the "import" statement to reference external modules.  Similarly,
>    a submodule uses the "import" statement to reference other modules.
> 
> This tends to confuse the nature of "include" and "import".  I would
> prefer:
> 
>    A module has an "include" statement for each of its submodules.  A
>    module, or submodule belonging to that module, can reference
>    definitions in the module and all submodules included by the
>    module.
> 
>    A module or submodule uses the "import" statement to reference
>    external modules.  Statements in the module or submodule can
>    reference definitions in the external module using the prefix
>    specified in the "import" statement.

Ok, this is better, though I prefer:

   A module uses the "include" statement to list all its submodules,
   ...

> --
> 
>    For backward compatibility with YANG version 1, a submodule is ...
> 
> It's not clear why backward compatibility is needed here, since
> yang-version marks each module explicitly with the language version
> that is used.
> 
>    References to definitions in the local module MAY use the prefix
>    notation.
> 
> I would add "... using the prefix defined for the module."
> 
> - The syntax of colon
> 
> Note there are four uses of ":" in the text:
> 
> section 5.1
> 
>    When a definition in an external module is referenced, a locally
>    defined prefix MUST be used, followed by ":", and then the external
>    identifier.
> 
> section 6.1.2
> 
>    A keyword
>    is either one of the YANG keywords defined in this document, or a
>    prefix identifier, followed by ":", followed by a language extension
>    keyword.
> 
> section 7.1.4
> 
>    When a reference to an identifier from the imported
>    module is used, the prefix string for the imported module is used in
>    combination with a colon (":") and the identifier, e.g.,
>    "if:ifIndex".
> 
> section 7.19
> 
>    The
>    statement's name is created by combining the prefix of the module in
>    which the extension was defined, a colon (":"), and the extension's
>    keyword, with no interleaving whitespace.
> 
> The BNF shows that in all cases, no whitespace is allowed around the
> ":".  I think that consistent wording should be used in all four
> locations

Ok, I changed this to:

  colon (":")

in order to match the rest of the text.

> to make it clear that whitespace/comments/newlines are not
> allowed.  Also "combined with" is unnecessarily inexact, "concatenated
> with" or "followed by" is much better.

Ok, I used "followed by", since it is used in the other places.

> - section 5.1.1
> 
> The beginning of this section should be a discussion of the nature of
> revisions abstractly.  AFAICT, an (abstract) module has one or more
> revisions, each of which is identified by a distinct revision date.
> Each of these is described by one module statement, each of which is
> in a separate file.  It seems to be preferred (but seemingly not
> required) that a revision of a module will have revision statements
> that specify the revision dates of itself and all older revisions in
> reverse chronological order -- the actual specification of the
> revision date of a module seems to be done externally to the module
> statement.
> 
> In regard to submodules, it seems that a revision of the module
> specifies the revisions of all of its submodules, but a revision of a
> submodule only specifies the module's identifier, not its revision.
> 
>    When a module is written, it can import the current revisions of
>    other modules, based on what is available at the time.
> 
> "current" is a dangerous word to use, because it means the narrative
> present moment.  You want to say:
> 
>    When a module is written, it can import the revisions of other
>    modules that are current when the module is written.

I see your point, but the original text tried to specify this by
saying "current [...] base on what is available at the time".  I can't
see how you would interpret this to mean "the time when I read this"
or anything else.  But ok, if it is unclear let's make it clear.

Your proposed text seems a bit awkward since it uses "when the module
is written" twice.  How about:

   Initially, a module imports the revisions of other modules that are
   current when the module is written.  As future revisions of the
   imported modules are published, ...


>    When the author of the
>    module is prepared to move to the most recently published revision of
>    an imported module, the module is republished with an updated
> s/the module is republished/the author's module is republished/
>    "import" statement.  By republishing with the new revision, the
>    authors explicitly indicate their acceptance of any changes in the
> s/their acceptance of any changes in/the use of the newer revision of/
>    imported module.
> 
> Why is "acceptance" being used here?  It has political connotations.
> It seems like "use of" carries less baggage.

"acceptance" is used to indicate that the authors found that the
changes are acceptable for their usage of the module.

>    For submodules, the issue is related but simpler.  A module or
>    submodule that includes submodules needs to specify the revision of
>    the included submodules.  If a submodule changes, any module or
>    submodule that includes it needs to be updated.
> 
> The second sentence is unclear.  I think you mean "In order for a
> module or submodule to use definitions in a new revision of a
> submodule, the module must be updated to include the new revision of
> the referenced submodule."

I think the text should simply be:

    For submodules, the issue is related but simpler.  A module or
    submodule that includes submodules may specify the revision of
    the included submodules.  If a submodule changes, any module or
    submodule that includes it by revision needs to be updated to
    reference the new revision.

>    If a module is not imported with a specific revision, it is undefined
>    which exact revision is used.
> 
> Delete "exact" here; it isn't needed and is too informal.  Perhaps
> replace with "specific".  (There are other instances of "exact" with
> the same issue.)

Ok.  I removed "exact" here, and changed other "exact" to "specific".

> - section 5.1.2
> 
>    YANG allows modeling of data in multiple hierarchies, where data may
>    have more than one top-level node.  Models that have multiple top-
>    level nodes are sometimes convenient, and are supported by YANG.
> 
> Any single module seems to define only one data structure, the one
> whose elements are the items listed in the module, and Yang doesn't
> seem to provide for any sort of "model" definition other than a
> module.  Or are the nodes at the top level within the module all
> usable as independent data structures?

The term "data structure" isn't used in the document.  YANG allows
a module to define more than one subtree.

> I.e., given a module
> statement, what is the set of allowed root XML elements for data trees
> in its XML namespace?

I don't understand this question.  Can you clarify?

> - section 5.1.2.1
> 
>    For example:
> 
>      module example-config {
>        yang-version 1.1;
>        namespace "urn:example:config";
>        prefix "co";
> 
>        container system { ... }
>        container routing { ... }
>      }
> 
>    could be encoded in NETCONF as:
> 
> s/For example/For example, an instance of/

Ok.

>    NETCONF is capable of carrying any XML content as the payload in the
>     and  elements.  The top-level nodes of YANG modules
>    are encoded as child elements, in any order, within these elements.
> 
> This isn't very clear.  AFAICT from the example:
> 
>    NETCONF  and  elements each contain sequences of
>    instances of top-level nodes of the appropriate YANG module.

I am not sure that this proposed text is more clear, maybe b/c I don't
see what in the original text is unclear.

> Given that this example is about a particular module, it would help if
> the module namespace and prefix was used correctly in the XML example.

I think the example uses the XML namespace correctly.

> - section 5.2
> 
>    YANG modules and submodules are typically stored in files, one module
>    or submodule per file.
> 
> This might be clearer as "... one module or submodule statement per
> file."

How is "one module per file" interpreted differently than "one module
statement per file"?

>    The name of the file SHOULD be of the form:
> 
>      module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
> 
> Does the extension ('.yang' or '.yin') correspond to whether the
> contents of the file are in Yang or Yin syntax?

You guessed right.

NEW:

   The file extension ".yang" denotes that the contents of the file is
   written with YANG syntax (Section 6), and ".yin" denotes that it is
   written with YIN syntax (Section 13).


> - section 5.3
> 
>    All YANG definitions are specified within a module that is bound to a
>    particular XML namespace [XML-NAMES], which is a globally unique URI
>    [RFC3986].
> 
> This doesn't clearly specify the range of "particular" and "unique".
> A better phrasing is
> 
>    All YANG definitions are specified within a module.  Each module is
>    bound to a distinct XML namespace [XML-NAMES], which is a globally
>    unique URI [RFC3986].

Yes this is better.


>    XML namespaces for private modules are assigned by the organization
>    owning the module without a central registry.  Namespace URIs MUST be
>    chosen so they cannot collide with standard or other enterprise
>    namespaces, for example by using the enterprise or organization name
>    in the namespace.
> 
> I don't see the use of "without a central registry"; haven't you
> already said the module is is private?  (Or is "without a central
> registry" a term of art?)

It could be that all namespaces had to be registered with IANA for
example.

> Also, the second sentence is redundant, as you've previously said that
> the URI is globally unique, which implies that whoever assigned the
> URI has some mechanism for assuring its uniqueness.
> 
> - section 5.4
> 
>    There is no worry over conflicts if both modules define the
>    type, since there is no ambiguity.
> 
> I think you mean "There is no ambiguity if both modules define types
> with the same name.".

Ok.

> - section 5.5
> 
> This section talks a great deal about why scoping is done, but isn't
> specifically clear what the rules are.  (Traditionally, the rule is
> stated as either what range of source text a particular definition is
> visible in, or given an identifier use, how the matching definition is
> found.)
> 
>    Scoped definitions MUST NOT shadow definitions at a higher scope.  A
>    type or grouping cannot be defined if a higher level in the schema
>    hierarchy has a definition with a matching identifier.
> 
> I think the second sentence is confusing, because (to me) the term
> "schema hierarchy" implies the data tree structure, whereas the
> scoping rule seems to be intended to be entirely lexical.  In either
> case, this needs to be clarified.

The first sentence says:

  Typedefs and groupings may appear nested under many YANG statements,
  allowing these to be lexically scoped by the hierarchy under which
  they appear.

Maybe it would help to move paragraph 2 and 3 to the end, so that the
motivational text is at the end of the section?


> - section 5.6
> 
>    Conformance is a measure of how accurately a server follows the
>    model.
> 
> There is no model already under discussion, so you can't use "the
> model".  Perhaps
> 
>    Conformance to a model is a measure of how accurately a server
>    follows a model.

I think it should be:

    Conformance to a model is a measure of how accurately a server
    follows the model.


> - section 5.6.5
> 
> I suspect that if a server implements module A, and A imports B, the
> server is not required to implement B.  (Even if A references
> groupings in B.)  The answer to that should probably be stated
> explicitly.

It is not so simple.  The rest of the text defines the rules for when
the server is required to implement B.

>    If a server lists a module C in the "/modules-state/module" list from
>    "ietf-yang-library", and there are other modules Ms listed that
>    import C without specifying the revision date of module C, the server
>    MUST use the definitions from the most recent revision of C listed
>    for modules Ms.
> 
> I think the end of that would be clearer as
> 
>    ... the server MUST implement Ms by importing the most recent
>    revision of C listed in the "/modules-state/module" list.

This wouldn't be correct.  For example, a module Ms1 might have
a typedef that reference C; the server is not required to implement
Ms1 in this case.

>      module b {
>        yang-version 1.1;
>        namespace "urn:example:b";
>        prefix "b";
> 
>        revision 2015-04-04;
>        revision 2015-01-01;
> 
>        typedef myenum {
>          type enumeration {
>            enum zero; // added in 2015-01-01
>            enum one;  // added in 2015-04-04
>          }
>        }
> 
>        container x {  // added in 2015-01-01
>          container y; // added in 2015-04-04
>        }
>      }
> 
> Is this the correct way to specify multiple revisions of this module?
> Or is this an informal notation for the two module definitions:
> 
>      module b {
>        yang-version 1.1;
>        namespace "urn:example:b";
>        prefix "b";
> 
>        revision 2015-04-04;
>        revision 2015-01-01;
> 
>        typedef myenum {
>          type enumeration {
>            enum zero; // added in 2015-01-01
>            enum one;  // added in 2015-04-04
>          }
>        }
> 
>        container x {  // added in 2015-01-01
>          container y; // added in 2015-04-04
>        }
>      }
> 
>      module b {
>        yang-version 1.1;
>        namespace "urn:example:b";
>        prefix "b";
> 
>        revision 2015-01-01;
> 
>        typedef myenum {
>          type enumeration {
>            enum zero; // added in 2015-01-01
>          }
>        }
> 
>        container x {  // added in 2015-01-01
>        }
>      }
> 
> If it is the latter, it would help the new reader to explain the
> convention (as no example of a multi-revision module is given in the
> document).

The comments are not required.  There is no correct (mandated) way to
specify which changes are done in a new revision.

> - section 6
> 
>    YANG modules use the UTF-8 [RFC3629] character encoding.
> 
> Better to say that YANG modules use the Unicode character set and are
> stored in files using the UTF-8 character encoding.

Do you mean:

OLD:

   YANG modules use the UTF-8 [RFC3629] character encoding.

   Legal characters in YANG modules are the Unicode and ISO/IEC 10646
   [ISO.10646] characters, including tab, carriage return, and line feed
   but excluding the other C0 control characters, the surrogate blocks,
   and the noncharacters.  The character syntax is formally defined by
   the rule "yang-char" in Section 14.

NEW:

   Legal characters in YANG modules are the Unicode and ISO/IEC 10646
   [ISO.10646] characters, including tab, carriage return, and line feed
   but excluding the other C0 control characters, the surrogate blocks,
   and the noncharacters.  The character syntax is formally defined by
   the rule "yang-char" in Section 14.

   YANG modules and submodules are stored in files using the UTF-8
   [RFC3629] character encoding.


> Verify that form-feed (0x0C) is not allowed.

Correct.

> This might be a good place to talk about line-breaks in Yang source
> files.  It looks from section 14 that line-breaks MUST be either CRLF
> or LF.
> 
> It is worth noting (either here or in 6.1.3) how line-breaks inside
> quoted strings are transcribed into the string's value.  As now
> written, it seems that the line-break is transcribed identically to
> how it is represented in the source.  That means (1) If the source is
> recoded with the other type of line break, the semantics of the Yang
> code change; and (2) if the source uses line-breaks of one type (CRLF
> or LF), only that type can be directly transcribed into string values.
> (But regardless of the source line-breaks, an LF can be transcribed
> into a double-quoted string with "\n".  But a CRLF cannot be
> transcribed into a double-quoted string with escape sequences.  Was
> that intended, or was "\r" intended to be legal?)
> 
> - section 6.1
> 
>    This section details the rules for recognizing tokens from an input
>    stream.
> 
> Generally, language definitions intersperse the narrative text with
> the relevant grammar definitions.  Yang's statement grammar is simple
> enough that one doesn't need to see the context-free part of the
> grammar to understand the narrative for statements.  But when reading
> about tokenization, not having the grammar presented at the same time
> is quite a burden.  I'd recommend duplicating the relevant productions
> from section 14 into the subsections of section 6.
> 
> There is some sort of exposition problem.  The result of
> "tokenization" is that the sequence of characters of the source is
> converted into a sequence of "tokens".  Then some subset of the tokens
> is discarded as being non-significant (e.g., whitespace and comments),
> and the remainder is parsed with a context-free grammar.  Here I can't
> figure out what the set of tokens is.  Looking at the grammar in
> section 14, it seems to be a context-free grammar on characters.  But
> that implies that there is no separate tokenization phase.
> 
> An example that shows the problems:
> 
>    mod:ext
> 
> Is this one token, which is also an extension keyword, or is it a
> sequence of three tokens?

The text says:

  A token in YANG is either a keyword, a string, a semicolon (";"), or
  braces ("{" or "}").

and:

  A keyword is [...] or a prefix identifier, followed by a colon
  (":"), followed by a language extension keyword.

So "mod:ext" is one token.

> - section 6.1.1
> 
>    A block comment is enclosed within "/*" and "*/".
> 
> Should say "starts with "/*" and ends with the nearest following
> "*/"".

Ok.

> - section 6.1.2
> 
>    A token in YANG is either a keyword, a string, a semicolon (";"), or
>    braces ("{" or "}").
> 
> What is the intention of this sentence?  One interpretation is that it
> defines "token" as the union of several other classes.  But that has
> the limitation that those classes are not well-defined in this
> section.  E.g., what is the syntax of an "unquoted string"?  The other
> interpretation is that the Yang file is already separated into
> "tokens", and that the set of tokens is further subdivided, with all
> tokens that are not keywords, quoted strings, semicolons, or braces
> being unquoted strings, whose value is the sequence of characters
> within the token.  But the separation into tokens is not described.
> 
> "string" is particularly confusing.  In most languages, "string"
> values are always quoted in source code.  But it seems that in Yang,
> any "token" that isn't a keyword or one of ;, {, }, is automatically
> an "unquoted string".  If that's so, it needs to be stated explicitly,
> since it's unusual.

It says: A string can be quoted or unquoted.

> - section 6.1.3
> 
>    If a string contains any space, tab, or newline characters, a single
>    or double quote character, a semicolon (";"), braces ("{" or "}"), or
>    comment sequences ("//", "/*", or "*/"), then it MUST be enclosed
>    within double or single quotes.
> 
> Is a string containing "*/" required to be quoted?

Yes.

> I ask because the
> character sequence "*/" is not ambiguous if it is not preceded by "/*"

Correct.

> -- it must be an unquoted string.
> 
>    If a double-quoted string contains a line break followed by space or
>    tab characters that are used to indent the text according to the
>    layout in the YANG file, this leading whitespace is stripped from the
>    string, up to and including the column of the double quote character,
>    or to the first non-whitespace character, whichever occurs first.  In
>    this process, a tab character is treated as 8 space characters.
> 
> This description isn't quite careful enough.  Better:
> 
>    If a double-quoted string contains a line break followed by space or
>    tab characters, an initial part of this whitespace is removed from the
>    string.  The amount removed is the longest prefix whose width is no
>    larger than the width of the prefix of Yang source line containing
>    the opening double quote character of the string to and including the
>    opening double quote character.  For this purpose, the width of a
>    tab character is 8 and the width of any other character is 1.
> 
> This does assume that all tabs are considered to have width 8, that
> is, tabs do not have the usual semantics of "advance to the next
> column that is divisible by 8".  That will sometimes cause unexpected
> results, e.g., if some source lines start with SPC TAB.  (Consider
> that whitespace before a line break is removed, which suggests the
> intention is that the value of the string should depend only on its
> visual appearance.)
> 
> Also, we're using the convention that "whitespace" does NOT include CR
> or LF, which is not always how the term is used.  Perhaps a definition
> of "whitespace" should be put in section 3.
> 
> There is also the special case:
> 
>    SPC " LF
>    TAB x "
> 
> Is the initial TAB of the second line to be removed or not?  There is
> no whitespace removal in the second line that will exactly reach the
> opening double quote.  As I've written it, the TAB is not removed.
> 
>    Within a double-quoted string (enclosed within " "), a backslash
>    character introduces a special character, which depends on the
>    character that immediately follows the backslash:
> 
> s/introduces a special character/introduces a representation of a
> special character/

Hmm.  I think the original text is correct.  In the string "x\ny", the
backslash introduces the LF character into the string.  What is the
representation of LF that it would introduce?


> Verify that CR cannot be specified by an escape.

This is correct.  I can see that it would make sense to allow it, but
I am not sure it is necessary.

>    If a quoted string is followed by a plus character ("+"), followed by
>    another quoted string, the two strings are concatenated into one
>    string, allowing multiple concatenations to build one string.
> 
> Are whitespace, line endings, or comments allowed between the quoted
> strings and the "+"?

Yes.  The normal usage of "+" is of course to split a long string to
several lines.

Maybe we can add a new sentence after the one above:

   Whitespace, line breaks, and comments are allowed between the
   quoted strings and the plus character.


> (This description is in the lexical section, so
> non-significant lexemes can't be assumed to have been removed.)  (See
> also comments on section 14.)
> 
>    If a quoted string is followed by a plus character ("+"), followed by
>    another quoted string, the two strings are concatenated into one
>    string, allowing multiple concatenations to build one string.
>    Whitespace trimming is done before substitution of backslash-escaped
>    characters in double-quoted strings.  Concatenation is performed as
>    the last step.
> 
> I think you want to reverse the phrase order in the second sentence:
> "In double-quoted strings, whitespace trimming is done before
> substitution of backslash-escaped characters."

Ok.

> However, it's not
> clear that that matters; only a backslash followed by whitespace would
> be affected by whitespace trimming, and whitespace trimming would
> leave the backslash followed by CR or LF -- all of those cases are
> invalid.
> 
> Also, if you keep that second sentence, it should be moved earlier --
> the first and third sentences of the paragraph apply to all quoted
> strings, but the second sentence only applies to double-quoted
> strings, and should be in a paragraph that deals with only
> double-quoted strings.
>
> - section 6.1.3.1
> 
>    The following examples show some illegal strings:
> 
>      ''''  - a single-quoted string cannot contain single quotes
>      """   - a double quote must be escaped in a double-quoted string
> 
> These shouldn't be described as "illegal" strings; they aren't
> strings, truly, but the lexing process doesn't isolate them as tokens,
> after which they are decreed to be improper.  The first example is two
> single-quoted strings (''), one after the other.  The second is a
> double-quoted string (""), followed by the double-quote that starts
> another double-quoted string.  Better to say "The following examples
> are not string tokens:".

Your proposed text is also not strictly correct - as you point out the
first example is in fact two legal string tokens.  I think the
original text is ok.


> - section 6.2
> 
>    Identifiers can be specified as quoted or unquoted strings.
> 
> If there is no lexical difference between how identifiers may be
> represented and how strings may be represented, and what is an
> identifier is distinguished only by the syntactic context, it would be
> helpful if that was stated explicitly in section 6.1.  (Though the
> characters allowed in identifiers are restricted.)

6.2 is the section that introduces identifiers; thus this section
describes how they are specified.

> - section 6.3.1
> 
>    The processing of extensions depends on whether support for those
>    extensions is claimed for a given YANG parser or the tool set in
>    which it is embedded.  An unsupported extension, appearing in a YANG
>    module as an unknown-statement (see Section 14) MAY be ignored in its
>    entirety.  Any supported extension MUST be processed in accordance
>    with the specification governing that extension.
> 
> This allows a loophole, where an implementation can not claim support,
> but then not ignore the extension.  I think you want to say "An
> unsupported extension ... MUST be ignored in its entirety."

No; this would be up to the implementation.

> (See also
> 7.20.1, which implies that an unsupported *feature* must be
> ignored.) If you really mean "MAY", what are the limits regarding what the
> server can do?

Up to the implementation.

> - section 6.5
> 
>    In an absolute
>    schema node identifier, the first identifier after the leading slash
>    is any top-level schema node in the local module or in all imported
>    modules.
> 
> I think "in all imported modules" should be "in an imported module".
> (The prefix of the identifier will tell which module.)

Yes, better.

> - section 7.1
> 
>    The module
>    name follows the rules for identifiers in Section 6.2.
> 
> Why not say "The module name is an identifier."?  Similarly for all
> other occurrences of "follows the rules for identifiers".  (I don't
> think we hang any semantics on the term "identifier", only syntax.)

Yes, better.

> - section 7.1.4
> 
> See discussion of "prefix" in comments for section 1.1.  I think all
> that is needed is to update the second paragraph to:
> 
>    When used inside the "module" statement, the "prefix" statement
>    defines the prefix suggested to be used when this module is imported.
> 
>    To improve readability of the NETCONF XML, a NETCONF client or server
>    that generates XML or XPath that use prefixes SHOULD use the prefix
>    defined by the module as the XMLNS prefix to associate with the
>    module's namespace (which may be impossible if there is a conflict
>    with another XMLNS prefix).
> 
> The important thing is that the discussion of using the prefix value
> as an XMLNS prefix is split into a separate paragraph, so it's clear
> that it is a different subject.

Ok.  In the second paragraph I wrote:

  To improve readability of the NETCONF XML, a NETCONF client or
  server that generates XML or XPath that use prefixes SHOULD use the
  prefix defined by the module as the XML namespace prefix , unless
  there is a conflict.


>    The
>    prefix string MAY be used to refer to definitions contained in the
>    module, e.g., "if:ifName".
> 
> I think this should be qualified "MAY be used within the module to
> refer to the definitions contained";

Yes, fixed.

> the following paragraph suggests
> that a module that imports this module can specify a different prefix
> for its references to use, and this prefix will not work in that
> module.
> 
> - section 7.1.5
> 
>    Multiple
>    "import" statements may be specified to import from different
>    modules.
> 
> Is this a requirement that two "import" statements in the same module
> MUST import different modules?  If not, the sentence should be shorted
> to "Multiple "import" statements may be specified.", or omitted
> entirely.

I think it can be omitted.  The last sentence in the section says:

  Multiple revisions of the same module can be imported, provided that
  different prefixes are used.

> But if a module can't be imported twice, that should
> probably be made clearer
> 
>    Multiple "import" statements may be specified, but they must import
>    from different modules.
> 
> - section 7.1.6
> 
>    When a module includes a submodule, it incorporates the contents of
>    the submodule into the node hierarchy of the module.
> 
> What does this mean?  The "include" statement is a top-level statement
> within its module, so how is its contents part of the node hierarchy
> -- what node is the parent of its nodes?  Perhaps the meaning is that
> top-level nodes of the submodule are implicitly top-level nodes of the
> module.

All contents work as if defined in the module itself (semantically).

> - section 7.2
> 
>    While the primary unit in YANG is a module, a YANG module can itself
>    be constructed out of several submodules.
> 
> This doesn't really capture the essence.  What you want to say is
> 
>    While the primary unit in YANG is a module, a YANG module can
>    include submodules, whose definitions are incorporated into it.

Hmm.  I don't really see the difference.  Why is the original text
wrong?

> - section 7.5.1
> 
>    In the first style, the container has no meaning of its own, existing
>    only to contain child nodes.
> 
> I think it would be good to add here "In particular, the presence of
> the container element with no child elements is semantically
> equivalent to the absence of the container element."

Ok, but I did s/element/node/g.

> - section 7.5.4.3
> 
>        must "ifType != 'ethernet' or " +
>             "(ifType = 'ethernet' and ifMTU = 1500)" {
> 	    ...
>        }
>        must "ifType != 'atm' or " +
>             "(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
> 	    ...
> 
> Are these a preferred style?  I ask because it would be shorter to say
> 
>        must "ifType != 'ethernet' or ifMTU = 1500" {
> 
>        must "ifType != 'atm' or " +
>             "(ifMTU <= 17966 and ifMTU >= 64)" {
> 
> (Perhaps the ifMTU element is optional, but even then, "and" must
> short-circuit for the given expressions to always be valid, so it
> seems that "or" must short-circuit.)

You're right, I'll change to the shorter style.

> - section 7.5.7
> 
> I suspect that child elements can be omitted if they're not mandatory,
> but their order need not match the order in the schema.

Not all payloads must contain mandatory nodes; e.g. if you do an
edit-config to remove a single optional leaf in a list entry, you
don't have to repeat all mandatory nodes.

> - section 7.6.1
> 
>    Note that if the leaf or any of its ancestors has a "when" condition
>    or "if-feature" expression that evaluates to "false", then the
>    default value is not in use.
> 
> ISTM that this is not a "Note that" but rather a precondition of the
> analysis of the preceding paragraphs, so it should be moved above
> "Otherwise, the usage of the default value...".  (See also the similar
> condition in 7.7.2.)

I always try to be careful with "Note that"... But in this case I
think it is correct.  The entire paragraph could actually be omitted,
and the semantics would be the same, since it is the semantics of
"when" and "if-feature" that defines the behavior.

> - section 7.6.4
> 
>    The default value MUST NOT be marked with an "if-feature" statement.
> 
> I think you want "The definition of the default value..." rather than
> "The default value...".

Yes.

> But it's not clear what the whole set of situations is that should be
> forbidden.  For instance, this should work:
> 
>      typedef xyz {
>        type enumeration {
> 	 enum blue { if-feature blue; }
> 	 ...
>        }
>      }
> 
>      leaf color {
>        if-feature blue;
>        type xyz;
>        default blue;
>      }
> 
> Whereas this won't:
> 
>      typedef xyz {
>        type enumeration {
> 	 enum blue { if-feature blue; }
> 	 ...
>        }
>      }
> 
>      leaf color {
>        // No if-feature here.
>        type xyz;
>        default blue;
>      }
> 
> Is this rule only meant to cover the situation where the leaf's type
> is an "in-line" enum and the particular enum value has an if-feature?

Good point.  Yes, the first example should be valid.  Another valid
example would be:

    container colors {
      if-feature blue;
      leaf color {
        type xyz;
        default blue;
      }
    }

Maybe:

OLD:

  The definition of the default value MUST NOT be marked with an
  "if-feature" statement.

NEW:

  If the definition of the default value is conditional based on one or
  more features (see ^if-feature^), then the leaf node MUST
  also be conditional based on at least the same set of features.

(modelled after the text in 9.9)

I'll start a separate thread for this issue on the ML.

> - section 7.7.1
> 
> It might be worth mentioning that duplicated values are allowed and
> are significant, since that has changed since Yang 1.  I.e., even in a
> system ordered list, the number of list elements with any particular
> value must be preserved.

This only works for config false leaf-lists.

> - section 7.7.2
> 
> It appears to be assumed that the server's behavior is the same if (1)
> a leaf-list node is specified with zero values, and (2) if the
> leaf-list node is absent and has no default values.
> 
>    Otherwise, if the leaf-list's type has
>    a default value, and the leaf-list does not have a "min-elements"
>    statement with a value greater than or equal to one, then the leaf-
>    list's default value is the type's default value.  In all other
>    cases, the leaf-list does not have any default values.
> 
> I think it would help to s/the type's default value/one instance of
> the type's default value/.

I don't understand why this is better?

> Is the final condition correct?  E.g., if the leaf-list's type has a
> default value, and it has a min-elements with value 2, then the
> leaf-list has no default values

Correct.

> -- which is invalid.

I don't understand what you mean?  An exmaple is this:

  typedef foo {
    type int32;
    default 42;
  }

  leaf-list bar {
    type foo;
    min-elements 1;
  }

In this example, "bar" doesn't have a default value - since
min-elements means that the user MUST provide at least one value, and
the default value is only used if no value has been provided.

> - section 7.7.7.1
> 
>    The entries in the list are sorted according to an order determined
>    by the system.  The "description" string for the list may suggest an
>    order to the server implementor.  If not, an implementation is free
>    to sort the entries in the most appropriate order.
> 
> This is mealy-mouthed about what is required and what is recommended.
> Better would be to omit "If not, an implementation is free to sort the
> entries in the most appropriate order."

I think the last sentence makes it clear that there you cannot assume
anything about the order, e.g., that a list that has an int32 as the
key is sorted in numerical order.

> - section 7.7.7.2
> 
>    The entries in the list are sorted according to an order defined by
>    the user.  This order is controlled by using special XML attributes
>    in the  request.
> 
> Actually, the entries aren't "sorted", as there is no requirement that
> any particular set of values always has a particular order; the user
> can insert 1, 2, 3 at one time, and 3, 2, 1 at another.  The correct
> meaning is splicing these two sentences:
> 
>    The user orders entries in the list by using special XML attributes
>    in the  request.

I prefer to keep the second sentence, and actually modify it to be:

  In NETCONF, this order is controlled by using special XML attributes
  in the  request.

Would it help to s/sorted/ordered/ in the first sentence?

> - section 7.7.8
> 
>    The XML elements
>    representing leaf-list entries MAY be interleaved with other sibling
>    elements, ...
> 
> I think it would be more accurate to say "interleaved with elements
> for siblings of the leaf-list node".  (See also section 7.8.5.)

Ok, fixed.

> - section 7.8
> 
>    A list entry is uniquely identified by the values of the list's keys,
>    if defined.
> 
> What does "if defined" apply to?  Is the point that if keys are not
> defined, then list entries have no such uniqueness requirement?

Yes.

> If
> the latter, then the text "Each entry ... is uniquely identified by
> the values of its key leafs." in section 4.2.2.4 needs to be changed.

Ok.

> - section 7.8.2
> 
>    The "key" statement, which MUST be present if the list represents
>    configuration, and MAY be present otherwise, takes as an argument a
>    string that specifies a space-separated list of leaf identifiers of
>    this list.
> 
> It would help to change to "list of one or more leaf identifiers"

Ok.

> - section 7.8.3
> 
>    The "unique" constraint specifies that the combined values of all the
>    leaf instances specified in the argument string, including leafs with
>    default values, MUST be unique within all list entry instances in
>    which all referenced leafs exist.
> 
> Should that sentence end "... within all list entry instances in which
> all referenced leafs exist or have default values"?

Yes, fixed.

> - section 7.9
> 
>    The "choice" statement defines a set of alternatives, only one of
>    which may exist at any one time.
> 
> Better, "only one of which may be present in any one data tree".

Ok.

>    A choice node does not exist in the data tree.
> 
> This is a good phrase and should be applied to list nodes (in that
> there is no node for the list, only for each list element).
> 
>    A choice consists of a number of branches, defined with the "case"
>    substatement.
> 
> Better, "each defined with a "case" substatement".

Ok.

>    As a shorthand, the "case" statement can be omitted if the branch
>    contains a single "anydata", "anyxml", "choice", "container", "leaf",
>    "list", or "leaf-list" statement.  In this case, the case node still
>    exists in the schema tree, and its identifier is the same as the
>    identifier in the branch statement.
> 
> There is no "branch" statement...  How about:
> 
>    As a shorthand, the "case" statement can be replaced by just the
>    statement for the child node if the branch contains a single
>    "anydata", "anyxml", "choice", "container", "leaf", "list", or
>    "leaf-list" statement.  In this case, the case node still exists in
>    the schema tree, and its identifier is the same as the identifier
>    of the child node.

Yes, better.

> - section 7.9.3
> 
>    The argument is the identifier of the "case" statement.
> 
> Better, "The argument is the identifier of the default "case"
> statement."

Ok.

> - section 7.9.5.  XML Encoding Rules
> 
>    The choice and case nodes are not visible in XML.
> 
> Use this sort of statement for lists and leaf-lists, which have no
> visible XML for the lists as a whole.

The current text says:

  A list is encoded as a series of XML elements, one for each entry in
  the list.

I think this text is clear.  I think it might be a bit confusing to
say that a list node is not visible in the XML - it is visible, per
entry.

> - section 7.10
> 
>    The "anydata" statement is used to represent an unknown set of nodes
>    that can be modelled with YANG, except anyxml, ...
> 
> What is the practical consequence of this restriction?  It's not at
> all clear to me which chunks of XML could be modelled with Yang and
> which could not.

In practice, this means that if you see an instance of anydata, there
is a YANG model behind that chunk somewhere, although you might not
know what it is.  In an implementation it means you can use your
normal parser (which maybe doesn't handle mixed content and processing
instructions etc).

> - section 7.12
> 
>    A grouping is like a "structure" or a "record" in conventional
>    programming languages.
> 
> Add, "... though no grouping node exists in the XML."

Since we try to decouple the defintion of the language from the
encodings, I'd prefer to not add this.

> - section 7.15
> 
>    The "action" statement is used to define an operation connected to a
>    specific container or list data node.
> 
> Might it be better to say "list element data node"?

No, since a "data node" is a node in the schema tree.  Note that the
text also says: "... an action is tied to a node in the datastore ...".


> What isn't being
> said explicitly is that an action that appears in a list statement is
> an action on a single element of the list, rather than an action on
> the list as a whole.  Similarly for notifications, section 7.16.
> 
> - section 7.15.2
> 
>    The last container or list contains an XML element that ...
> 
> Would "innermost" be better than "last"?

Yes (same for 7.16.2).

> - section 7.17
> 
>    The "augment" statement allows a module or submodule to add to >a<
>    schema tree defined in an external module, or >in< the current module and
>    its submodules, and to add to the nodes from a grouping in a "uses"
>    statement.
> 
> I think adding "in" where indicated makes the sentence clearer.

Ok.

> I've changed a "the" is changed to an "a" where indicated.  The
> question is whether the module defines a schema tree or a schema
> forest, a set of trees.  That depends on whether each top-level node
> can be used independently as the root of a data tree or whether they
> have to be used together.  See comments on section 5.1.2.

No they don't have to be used together, so "a" seems correct.

> - section 7.18
> 
> It would help to insert a discussion of the global purpose and use of
> identities.  In particular, what things can refer to them?  It looks
> like only identityref leafs can do so, but I could easily be wrong.
> Also, more discussion in the example (7.18.3) would be helpful.
> 
>    The "identity" statement is used to define a new globally unique,
>    abstract, and untyped identity.  Its only purpose is to denote its
>    name, semantics, and existence.
> 
> The two uses of "its" in the second sentence are ambiguous.  I think
> you mean "The statement's only purpose is to denote the identity's
> name, semantics, and existence."

No, rather "The identity's only purpose...".  The point is that this
just an abstract concept.

[These two sentences are shamelessly copied from the spec of one of
YANG's predecessors - SMIng (RFC 3780)].

> Though I'm not sure that an identity
> has any semantics beyond its existence and base identities.

The semantics of an identity is defined in the description statement.

> - section 7.19
> 
>    The statement's argument is an identifier that is the new keyword for
>    the extension and must be followed by a block of substatements that
>    holds detailed extension information.
> 
> s/The statement's/The "extension" statement's/

Ok.

> -- this talks about the
> "extension" statement that defines the extension statement [sic!].
> 
> - section 7.20.2.1
> 
>    In this example, the container "target" is implemented if any of the
>    features "outbound-tls" or "outbound-ssh" are supported by the
>    server.
> 
> "either" is better than "any" if there are only two choices.

Ok.

> - section 7.21.4
> 
>    The "reference" statement takes as an argument a string ...
> 
> Perhaps s/a string/a human-readable string/.

"string" refers to the YANG token "string".  The same wording is used
across the document for all arguments.

> - section 7.21.5
> 
> Note that if a data definition has both an "if-feature" and a "when",
> then the "if-feature" is tested first.
> 
>    If the XPath expression references any node that also has associated
>    "when" statements, these "when" expressions MUST be evaluated first.
>    There MUST NOT be any circular dependencies in these "when"
>    expressions.
> 
> I think this could be better phrased:
> 
>    If the XPath expression references any node that also has
>    associated "when" statements, then the "when" expressions of the
>    referenced nodes MUST be evaluated first.  There MUST NOT be any
>    circular dependencies among "when" expressions.

Ok to the last sentence.  Do you think that the word "these" in the
first sentence is ambigious?

> - section 9.3.4
> 
> Can one apply a fraction-digits restriction to a derived type that
> already has a fraction-digits restriction?

No, since "fraction-digits" is not listed as a valid restriction to
"decimal64".

> ISTM that this is sensible
> if the fraction-digits numbers of the two restrictions are the same.
> Then again, that would be pointless, and we might want to forbid
> fraction-digits re-restrictions.
> 
> The fraction-digits statement doesn't seem to have any of the
> substatements (e.g., description, error-app-tag) that other
> restrictions (e.g., length, pattern, range) do.  (The grammar in
> section 14. agrees.)  Is this OK?  It seems like a value could fail to
> conform to fraction-digits.

Note that "fraction-digits" is not a restriction, like the other you
mentioned.  The "description" would be on the type itself.

> - section 9.6.3
> 
>    An enumeration can be restricted with the "enum" (Section 9.6.4)
>    statement.
> 
> This should be fleshed out:  "... can be restricted with one or more
> "enum" (Section 9.6.4) statements, which enumerate a subset of the
> values of the base type."

Yes, better.

> - section 9.7.2
> 
>    The lexical representation of the bits type is a space-separated list
>    of the individual bit values that are set.
> 
> I think that should be "... list of the names of the bits that are
> set."  I tend to think of a "bit value" as 0 or 1.

Ok.

> - section 9.8.3
> 
>    The canonical form of a binary value follows the rules in [RFC4648].
> 
> Best specify "the rules of 'Base 64 Encoding' in [RFC4648]."

Ok.

> - section 9.9
> 
>    The leafref type is used to declare a constraint on the value space
>    of a leaf, based on a reference to a set of leaf instances in the
>    data tree.  The "path" substatement (Section 9.9.2) selects a set of
>    leaf instances, and the leafref value space is the set of values of
>    these leaf instances.
> 
> The first sentence isn't quite right.  Perhaps:
> 
>    The value space of a leaf with leafref type is one of the values of
>    a set of leaf instances in the data tree.  The "path" substatement
>    (Section 9.9.2) selects the set of leaf instances, and the leafref
>    value space is the set of values of these leaf instances.

The point is that "leafref" introduces a constraint on valid data.
In for example the candidate configuration of NETCONF, it is ok if a
leafref leaf points to something that doesn't exist.  However it must
exist at commit-time.  See below.

> - section 9.9.3
> 
>    If "require-instance" is "true", it means that the instance being
>    referred MUST exist for the data to be valid.  This constraint is
>    enforced according to the rules in Section 8.
> 
>    If "require-instance" is "false", it means that the instance being
>    referred MAY exist in valid data.
> 
> What does "the instance being referred" mean?  Perhaps you meant "the
> instance being referred to"?

Yes.

> Also, I think the second paragraph means that if require-instance is
> false, the referred-to instance need not exist.  But it's not clear to
> me what that would mean -- if there are no instances referenced by the
> XPath expression, then the set of value values of the leafref would be
> empty and the leafref would necessarily be invalid. ...  I think these
> paragraphs need to be expanded in some way.

Right; so what we want to say is:

  - the value space is the same as the value space of the referred
    leaf

  - there is an additional constraint if require-instance is true that
    the referred to leaf instance must exist

How about

OLD:

   The leafref type is used to declare a constraint on the value space
   of a leaf, based on a reference to a set of leaf instances in the
   data tree.  The "path" substatement (Section 9.9.2) selects a set of
   leaf instances, and the leafref value space is the set of values of
   these leaf instances.

   If the leaf with the leafref type represents configuration data, and
   the "require-instance" property (Section 9.9.3) is "true", the leaf
   it refers to MUST also represent configuration.  Such a leaf puts a
   constraint on valid data.  All such nodes MUST reference existing
   leaf instances or leafs with default values in use (see Section 7.6.1
   and Section 7.7.2) for the data to be valid.  This constraint is
   enforced according to the rules in Section 8.

NEW:

   The leafref type is used to declare a constraint on the value space
   of a leaf, based on a reference to a set of leaf instances in the
   data tree.  The "path" substatement (Section 9.9.2) is used to refer
   to another leaf node.  The leafref value space is the value space of
   this leaf node.

   If the "require-instance" property is "true", there MUST exist an
   instance, or a leaf with a default value in use (see Section 7.6.1
   and Section 7.7.2), of the leaf being referred to with the same value
   as the leafref value in a valid data tree.

   If the leaf with the leafref type represents configuration data, and
   the "require-instance" property (Section 9.9.3) is "true", the leaf
   it refers to MUST also represent configuration.


This needs to be verified on the ML (I'll start a separate thread for
this).

> (require-instance is also used in instance-identifier, which may have
> subtly different semantics than when it is used in leafref.)
> 
> - section 9.9.4.  Lexical Representation
> 
>    A leafref value is lexically represented the same way as the leaf it
>    references.
> 
> Probably better as "... the same way as the leaf it references
> represents its value."

Ok.

> - section 9.12
> 
>    It is used to repeatedly specify each member type of the
>    union.
> 
> I think you want "It is used repeatedly to specify ..." --
> "repeatedly" modifies "used", not "specify".

Yes, or even "repeatedly used to" (like in enum/bit).

>    In the XML encoding, a value representing a union data type is
>    validated consecutively against each member type, in the order they
>    are specified in the "type" statement, until a match is found.  The
>    type that matched will be the type of the value for the node that was
>    validated.
> 
> I think a distinction needs to be made here between generating XML and
> interpreting XML:
> 
>    When generating an XML encoding, a value is encoded according to
>    the rules of the member type to which the value belongs.  When
>    interpreting an XML encoding, a value is validated consecutively
>    against each member type, in the order they are specified in the
>    "type" statement, until a match is found.  The type that matched
>    will be the type of the value for the node that was validated, and
>    the encoding is interpreted according to the rules for that type.

Yes, better, but I don't understand what value the last part of the
last sentence adds?

> - section 10.3.1
> 
>    If the first argument node is of type leafref, the function returns a
>    node set that contains the nodes that the leafref refers to.
> 
> I *think* that this means the set of nodes that the leafref's XPath
> selects, but a plausible alternative is the subset of those nodes
> which have the same value as the leafref does.  This hinges on the
> meaning of "the leafref refers to a node", which isn't defined
> unambiguously in section 9.9.

It is the latter.  Howabout:

NEW:

   If the first argument node is of type leafref, the function returns
   a node set that contains the nodes that the leafref refers to.
   Specifically, this set contains the nodes selected by the leafref's
   "path" statement (Section 9.9.2) that has the same value as the
   first argument node.

> - section 11
> 
>    o  A "description" statement may be added or clarified without
>       changing the semantics of the definition.
> 
> Probably better to change "clarified" to "changed".  (What is the
> specificational content of "clarified"?)

Ok.

>    o  A "type" statement may be replaced with another "type" statement
>       that does not change the syntax or semantics of the type.  For
>       example, an inline type definition may be replaced with a typedef,
>       but an int8 type cannot be replaced by an int16, since the syntax
>       would change.
> 
> Is the last sentence correct?  Any value that was previously valid
> would remain valid.  This is similar to changing "range '-128..127'"
> to "range '-32768..32767'".

This is the rules the WG agreed on - I agree they could be less
restrictive, but the current rules reflect the consensus.

> - section 13
> 
>    The translated module is called a YIN module.  This
>    section describes symmetric mapping rules between the two formats.
> 
> I don't think "symmetric" is the right word; perhaps "bidirectional".

Yes, better.

> - section 14
> 
>    This grammar assumes that the scanner replaces YANG comments with a
>    single space character.
> 
> It would probably be better to explicitly include comments in the
> separator nonterminals:

This would be a pretty drastic change.

>    ;; 'comment' is specified in Section 6.1.1
> 
>    sep                 = 1*(WSP / line-break / comment)
>                          ; unconditional separator
> 
>    optsep              = *(WSP / line-break / comment)
> 
>    stmtsep             = *(WSP / line-break / comment / unknown-statement)
> 
> --
> 
>    module-stmt         = optsep module-keyword sep identifier-arg-str
>    		       	 ...
> 
> This has the consequence that 'module"name"{...' is invalid, because
> there is no separator after 'module', even though traditional
> tokenizers would handle it.  Verify that this is intended.  (This
> pattern is consistent for all statement types.)

Yes this is intended.

>    linkage-stmts       = ;; these stmts can appear in any order
>                          *import-stmt
>                          *include-stmt
> 
> This could easily be handled like body-stmts:
> 
>    linkage-stmts       = *(import-stmt /
>                            include-stmt)

This would the change the canonical order.  With the current rule this
is not in canonical order:

   import a;
   include b;
   import c;


> 
>    if-feature-expr     = "(" if-feature-expr ")" /
>                          if-feature-expr sep boolean-operator sep
>                            if-feature-expr /
>                          not-keyword sep if-feature-expr /
>                          identifier-ref-arg
> 
> This should probably be marked ";; precedence rules specified in
> Section 7.20.2", as the grammar is ambiguous and does not specify the
> precedence, whereas typical programming language grammars encode the
> precedence rules.

Or we change it to:

if-feature-expr     = if-feature-term [sep or-keyword sep if-feature-expr]

if-feature-term     = if-feature-factor [sep and-keyword sep if-feature-term]

if-feature-factor   = not-keyword sep if-feature-factor /
                      "(" sep if-feature-expr sep ")" /
                      identifier-ref-arg


[FWIW, that's how I have implemented this - it's trivial to write a
recursive descent parser from that spec]


>    instance-identifier-specification =
>                          [require-instance-stmt]
> 
> Why is require-instance-stmt in [...]?  The only use of
> instance-identifier-specification is in type-body-stmts, and the only
> use of type-body-stmts is in type-stmt, where it is in [...].  Compare
> with numerical-restrictions:
> 
>    numerical-restrictions = range-stmt
> 
> --
> 
>    binary-specification = [length-stmt]

You're right that it isn't necessary.  However, imo it is more clear;
in an instance-identifier spec require-instance is optional, but the
only numerical-restriction is range.

> Similarly.
> 
>    quoted-string       = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)
> 
>    string              = < an unquoted string as returned by >
>                          < the scanner, that matches the rule >
>                          < yang-string >
> 
> The handling of "string" is hard to follow and/or inexact.  First, we
> need a term for the "value" of a string written in Yang source, so we
> can say
> 
>    prefix-arg-str      = < a string whose ??? matches the rule >
>                          < prefix-arg >
> 
> The text that is now used is not too difficult to understand, but it's
> inexact and makes it hard to write specifications about how the value
> is determined.

It's not clear to me which problem you want to solve, and also it's
not clear exactly what you propose.

> (Also, there seem to be too many <...>, dividing the narrative text
> into two parts.  The natural way to write it would be:
> 
>    prefix-arg-str      = < a string whose ??? matches the rule
>                            prefix-arg >

Agreed, but LF isn't allowed in prose-val in ABNF (see RFC 5234).


> But it might not be worth the effort to change the use of <...>
> throughout section 14.)
> 
> We need a production that tells exactly the syntax of "an unquoted
> string as return by the scanner".
> 
> We also need productions for quoted strings.  I can reconstruct these:
> 
>    quoted-string       = (single-quoted-string / double-quoted-string)
>    		         *(optsep "+" optsep
>                              (single-quoted-string / double-quoted-string))
> 
>    single-quoted-string = SQUOTE *(yang-char excluding "'") SQUOTE
> 
> (I don't know a good way to exclude one character from a character set
> in ABNF.)
> 
>    double-quoted-string = DQUOTE *dq-char DQUOTE
> 
>    dq-char = yang-char excluding BACKSLASH and DQUOTE /
>              BACKSLASH ( "n" / "t" / DQUOTE / BACKSLASH )
> 
> Verify that "optsep" is what is allowed to appear around "+".
> 
> Needs a comment pointing to Section 6.1.3 as telling how to interpret
> quoted-strings.
> 
> [END]



/martin


From nobody Mon May 23 06:43:40 2016
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 857AB12D199 for ; Mon, 23 May 2016 06:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 hZRtGtJQT6mH for ; Mon, 23 May 2016 06:43:36 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B0E12B034 for ; Mon, 23 May 2016 06:43:36 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:19c4:f68e:489c:53ba] (unknown [IPv6:2001:718:1a02:1:19c4:f68e:489c:53ba]) by mail.nic.cz (Postfix) with ESMTPSA id 21EF5612C9; Mon, 23 May 2016 15:43:35 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464011015; bh=Cblof6gRYf+DfxhL5wUS/E5wQ35SDBk7aG3iwJCI7d0=; h=From:Date:To; b=l5orYaXurKYCyNl5JBnZBmwQZacgvnQ83bHl7kS/HpceB+yJlYihGiU6nd3GuXHE7 L8YyeBJlkND8yeilmyWLfSyzrEks1vAFwhlD0eixhfDjsQ9kEegR/hpXwHfLmx3yXC kJ191rTIsF0C8H47ZKG1a39liUFVzgwie5MSlN4A=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <5742F7FB.4040803@labn.net>
Date: Mon, 23 May 2016 15:43:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <22C4E267-E883-4909-A824-DB742B9F63A4@nic.cz>
References:  <5742F7FB.4040803@labn.net>
To: Lou Berger 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] compact versus iterative representation of the overall schema
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 13:43:38 -0000

> On 23 May 2016, at 14:30, Lou Berger  wrote:
>=20
> Hi Lada,
>    I looks like no one really jumped on this one -- so better late =
than
> never ...
>=20
> When looking at the question below, we should consider the uses cases.=20=

> I'm particularity interested (as a contributor) in the use case of
> nested mounts (NIs mounted within LNEs), as well as the case if  =
models
> that will only permit mounting of specific other models vs generically
> mounting any model.
>=20
> On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
>> Hi,
>>=20
>> with a schema mount mechanism in place, there are two different =
options
>> for constructing the overall schema (their combinations are possible,
>> too):
>>=20
>> 1. Define schema mount as an extension of YANG library so that it
>> defines YANG modules, revisions, features and deviations as before =
but
>> also the way how they are combined into a hierarchical structure of
>> schemas.
>=20
> I think this only makes sense if this is scoped in some way.  For
> example, with LNEs, the parent/host server may not have visibility =
into
> the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And even =
if

As I understand it, schema-mount is about accessing the LNE models from =
the parent/host management interface. I believe the real question is =
whether we want to allow the schema to dynamically change at run time =
and possibly throw in new modules that the client never heard of. #2 can =
do it while #1 can't. I am not sure though whether the LNE model really =
requires something like this.

> does, you have to consider the cases of mounted models contained =
within
> mounted models.

This is possible either way, provided that the complete schema is known =
upfront.

>=20
>>=20
>> 2. Apart from YANG Library data, the server just specifies the mount
>> points. A client of an NM protocol is expected to fetch a new =
instance
>> of YANG library and/or subordinate mount points as state data from a
>> well-known location under each mount point.
>=20
> I think this depends on the use case.  For LNEs, I think this is =
right.=20
> For some of the other possible use cases being discussed only a =
specific
> model can be mounted.

I guess I need some example scenarios demonstrating that #1 cannot be =
used for LNE.

Lada=20

>=20
>> I think that #1 should be available (alone or along with #2) because
>> there are cases when YANG is used as a data modelling language =
outside
>> the context of a NM protocol =E2=80=93 Eliot Lear's MUD presentation =
is one
>> example.
>=20
> I think we (the rtg yang arch dt) had envisioned  something closer to
> 2.  And as you say, an approach that also includes a properly scoped 1
> is possible.
>=20
> Lou
>=20
>> Lada
>>=20
>=20
>=20

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





From nobody Mon May 23 06:59:07 2016
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 21A6E12D8F9 for ; Mon, 23 May 2016 06:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 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_H2=-0.001, 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 7nn1oNxxHlpq for ; Mon, 23 May 2016 06:59:04 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 85BCE12D198 for ; Mon, 23 May 2016 06:59:04 -0700 (PDT)
Received: (qmail 11376 invoked by uid 0); 23 May 2016 13:59:02 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 23 May 2016 13:59:02 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id xpyw1s00D2SSUrH01pyzse; Mon, 23 May 2016 07:59:00 -0600
X-Authority-Analysis: v=2.1 cv=QND7GG7L c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=yrkiwgmsf1kA:10 a=wU2YTnxGAAAA:8 a=PKXN5bc5wmwGyTaQxZIA:9 a=u-U2OPmVY9e_8NW8:21 a=P-gktLqHjNH6SAND:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv: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:Cc:References:To:Subject; bh=gMydN43nOOhhRpYnhJ3ooo+WVPrn4ZWQmieGLBydXGI=; b=F9BPaFLrZ9PCnJzjQtCwPLG2qF 1lMqJ+ES0fJVc+HGATTZLueN31b/2irO2ZASIUfHrmplL/fUtm9qLeAVEyhvzDuhkDd+wlSRyboyh Z1Eorzs8YF/jV/ZxJzexDs+nl;
Received: from box313.bluehost.com ([69.89.31.113]:39348 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b4qNm-0003hj-8Q; Mon, 23 May 2016 07:58:58 -0600
To: Ladislav Lhotka 
References:  <5742F7FB.4040803@labn.net> <22C4E267-E883-4909-A824-DB742B9F63A4@nic.cz>
From: Lou Berger 
Message-ID: <57430C99.1000804@labn.net>
Date: Mon, 23 May 2016 09:58:49 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <22C4E267-E883-4909-A824-DB742B9F63A4@nic.cz>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] compact versus iterative representation of the overall schema
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 13:59:06 -0000

Lada

See below

On 5/23/2016 9:43 AM, Ladislav Lhotka wrote:
>> On 23 May 2016, at 14:30, Lou Berger  wrote:
>>
>> Hi Lada,
>>    I looks like no one really jumped on this one -- so better late than
>> never ...
>>
>> When looking at the question below, we should consider the uses cases. 
>> I'm particularity interested (as a contributor) in the use case of
>> nested mounts (NIs mounted within LNEs), as well as the case if  models
>> that will only permit mounting of specific other models vs generically
>> mounting any model.
>>
>> On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
>>> Hi,
>>>
>>> with a schema mount mechanism in place, there are two different options
>>> for constructing the overall schema (their combinations are possible,
>>> too):
>>>
>>> 1. Define schema mount as an extension of YANG library so that it
>>> defines YANG modules, revisions, features and deviations as before but
>>> also the way how they are combined into a hierarchical structure of
>>> schemas.
>> I think this only makes sense if this is scoped in some way.  For
>> example, with LNEs, the parent/host server may not have visibility into
>> the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And even if
> As I understand it, schema-mount is about accessing the LNE models from the parent/host management interface. I believe the real question is whether we want to allow the schema to dynamically change at run time and possibly throw in new modules that the client never heard of. #2 can do it while #1 can't. I am not sure though whether the LNE model really requires something like this.

Again there are different use cases.  In the fixed-mount case (where a
module containing the mount specifies what model is being mounted) a
client will always know what to expect.  In the LNE and probably even NI
cases, a single client may talk to multiple servers, each of which may
have different mounted models.  I'm less sure about a single server with
different models mounted under different NIs, but this is certainly
possible in the LNE case.

>> does, you have to consider the cases of mounted models contained within
>> mounted models.
> This is possible either way, provided that the complete schema is known upfront.

I think the complete schema is likely to be known by there server
upfront in all cases, but not the client.

Lou
>>> 2. Apart from YANG Library data, the server just specifies the mount
>>> points. A client of an NM protocol is expected to fetch a new instance
>>> of YANG library and/or subordinate mount points as state data from a
>>> well-known location under each mount point.
>> I think this depends on the use case.  For LNEs, I think this is right. 
>> For some of the other possible use cases being discussed only a specific
>> model can be mounted.
> I guess I need some example scenarios demonstrating that #1 cannot be used for LNE.
>
> Lada 
>
>>> I think that #1 should be available (alone or along with #2) because
>>> there are cases when YANG is used as a data modelling language outside
>>> the context of a NM protocol – Eliot Lear's MUD presentation is one
>>> example.
>> I think we (the rtg yang arch dt) had envisioned  something closer to
>> 2.  And as you say, an approach that also includes a properly scoped 1
>> is possible.
>>
>> Lou
>>
>>> Lada
>>>
>>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>



From nobody Mon May 23 07:08:28 2016
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 0564A12D911 for ; Mon, 23 May 2016 07:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 B16qobftYjTg for ; Mon, 23 May 2016 07:08: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 D3B5312D90E for ; Mon, 23 May 2016 07:08:25 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id EAC111AE0386 for ; Mon, 23 May 2016 16:08:24 +0200 (CEST)
Date: Mon, 23 May 2016 16:08:45 +0200 (CEST)
Message-Id: <20160523.160845.386020102124289824.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] if-feature in default value
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 14:08:27 -0000

Hi,

This comment from the Gen-ART review deserves it's own thread.


gen-art> - section 7.6.4
gen-art> 
gen-art>    The default value MUST NOT be marked with an "if-feature" statement.
gen-art>
[...] 
gen-art> But it's not clear what the whole set of situations is that should be
gen-art> forbidden.  For instance, this should work:
gen-art> 
gen-art>      typedef xyz {
gen-art>        type enumeration {
gen-art> 	 enum blue { if-feature blue; }
gen-art> 	 ...
gen-art>        }
gen-art>      }
gen-art> 
gen-art>      leaf color {
gen-art>        if-feature blue;
gen-art>        type xyz;
gen-art>        default blue;
gen-art>      }
gen-art> 
gen-art> Whereas this won't:
gen-art> 
gen-art>      typedef xyz {
gen-art>        type enumeration {
gen-art> 	 enum blue { if-feature blue; }
gen-art> 	 ...
gen-art>        }
gen-art>      }
gen-art> 
gen-art>      leaf color {
gen-art>        // No if-feature here.
gen-art>        type xyz;
gen-art>        default blue;
gen-art>      }
gen-art> 
gen-art> Is this rule only meant to cover the situation where the leaf's type
gen-art> is an "in-line" enum and the particular enum value has an if-feature?

mbj> Good point.  Yes, the first example should be valid.  Another valid
mbj> example would be:
mbj> 
mbj>     container colors {
mbj>       if-feature blue;
mbj>       leaf color {
mbj>         type xyz;
mbj>         default blue;
mbj>       }
mbj>     }
mbj> 
mbj> Maybe:
mbj> 
mbj> OLD:
mbj> 
mbj>   The definition of the default value MUST NOT be marked with an
mbj>   "if-feature" statement.
mbj> 
mbj> NEW:
mbj> 
mbj>   If the definition of the default value is conditional based on one or
mbj>   more features (see ^if-feature^), then the leaf node MUST
mbj>   also be conditional based on at least the same set of features.
mbj> 
mbj> (modelled after the text in 9.9)

Does anyone have comments on this proposal?


/martin


From nobody Mon May 23 07:10:26 2016
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 DCB2A12D8F5 for ; Mon, 23 May 2016 07:10:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 g6ICnn3dlVxj for ; Mon, 23 May 2016 07:10:20 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B23B612D90E for ; Mon, 23 May 2016 07:10:18 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id D3D1D1AE0386 for ; Mon, 23 May 2016 16:10:17 +0200 (CEST)
Date: Mon, 23 May 2016 16:10:38 +0200 (CEST)
Message-Id: <20160523.161038.800274078120441332.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 14:10:26 -0000

Hi,

This comment from the Gen-ART review deserves it's own thread.

gen-art> - section 9.9
gen-art> 
gen-art>    The leafref type is used to declare a constraint on the value space
gen-art>    of a leaf, based on a reference to a set of leaf instances in the
gen-art>    data tree.  The "path" substatement (Section 9.9.2) selects a set of
gen-art>    leaf instances, and the leafref value space is the set of values of
gen-art>    these leaf instances.
gen-art> 
gen-art> The first sentence isn't quite right.  Perhaps:
gen-art> 
gen-art>    The value space of a leaf with leafref type is one of the values of
gen-art>    a set of leaf instances in the data tree.  The "path" substatement
gen-art>    (Section 9.9.2) selects the set of leaf instances, and the leafref
gen-art>    value space is the set of values of these leaf instances.
gen-art>
gen-art> - section 9.9.3
gen-art> 
gen-art>    If "require-instance" is "true", it means that the instance being
gen-art>    referred MUST exist for the data to be valid.  This constraint is
gen-art>    enforced according to the rules in Section 8.
gen-art> 
gen-art>    If "require-instance" is "false", it means that the instance being
gen-art>    referred MAY exist in valid data.
gen-art> 
[...]
gen-art> Also, I think the second paragraph means that if require-instance is
gen-art> false, the referred-to instance need not exist.  But it's not clear to
gen-art> me what that would mean -- if there are no instances referenced by the
gen-art> XPath expression, then the set of value values of the leafref would be
gen-art> empty and the leafref would necessarily be invalid. ...  I think these
gen-art> paragraphs need to be expanded in some way.

mbj> Right; so what we want to say is:
mbj> 
mbj>   - the value space is the same as the value space of the referred
mbj>     leaf
mbj> 
mbj>   - there is an additional constraint if require-instance is true that
mbj>     the referred to leaf instance must exist
mbj> 
mbj> How about
mbj> 
mbj> OLD:
mbj> 
mbj>    The leafref type is used to declare a constraint on the value space
mbj>    of a leaf, based on a reference to a set of leaf instances in the
mbj>    data tree.  The "path" substatement (Section 9.9.2) selects a set of
mbj>    leaf instances, and the leafref value space is the set of values of
mbj>    these leaf instances.
mbj> 
mbj>    If the leaf with the leafref type represents configuration data, and
mbj>    the "require-instance" property (Section 9.9.3) is "true", the leaf
mbj>    it refers to MUST also represent configuration.  Such a leaf puts a
mbj>    constraint on valid data.  All such nodes MUST reference existing
mbj>    leaf instances or leafs with default values in use (see Section 7.6.1
mbj>    and Section 7.7.2) for the data to be valid.  This constraint is
mbj>    enforced according to the rules in Section 8.
mbj> 
mbj> NEW:
mbj> 
mbj>    The leafref type is used to declare a constraint on the value space
mbj>    of a leaf, based on a reference to a set of leaf instances in the
mbj>    data tree.  The "path" substatement (Section 9.9.2) is used to refer
mbj>    to another leaf node.  The leafref value space is the value space of
mbj>    this leaf node.
mbj> 
mbj>    If the "require-instance" property is "true", there MUST exist an
mbj>    instance, or a leaf with a default value in use (see Section 7.6.1
mbj>    and Section 7.7.2), of the leaf being referred to with the same value
mbj>    as the leafref value in a valid data tree.
mbj> 
mbj>    If the leaf with the leafref type represents configuration data, and
mbj>    the "require-instance" property (Section 9.9.3) is "true", the leaf
mbj>    it refers to MUST also represent configuration.


Does anyone have comments on this proposal?


/martin


From nobody Mon May 23 07:21:38 2016
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 BD6F412B043 for ; Mon, 23 May 2016 07:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 TalwvJHc_u3Y for ; Mon, 23 May 2016 07:21:33 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F2912D61A for ; Mon, 23 May 2016 07:21:33 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:19c4:f68e:489c:53ba] (unknown [IPv6:2001:718:1a02:1:19c4:f68e:489c:53ba]) by mail.nic.cz (Postfix) with ESMTPSA id 775F46099D; Mon, 23 May 2016 16:21:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464013291; bh=6HtPfzAl+7/dmh+7ztDL89UWDmBJEItnRbbe6Ik76p8=; h=From:Date:To; b=Cb8pzgxO6zT9ZO/pYetxc7yxwb03TVWO6LROgMdu/4xHTsKYtWFAgfSEJ+/OKkRrW PvssPKA9jG7l6aOxjGUeiT/jMijg4U1FZxkifvClUv6DtvobM5nWI4XVCo3ED2WmHi uq044FT30OkUUjsZelldte8gVbMO7p2BvMa4PHdM=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <57430C99.1000804@labn.net>
Date: Mon, 23 May 2016 16:21:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <5742F7FB.4040803@labn.net> <22C4E267-E883-4909-A824-DB742B9F63A4@nic.cz> <57430C99.1000804@labn.net>
To: Lou Berger 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] compact versus iterative representation of the overall schema
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 14:21:36 -0000

> On 23 May 2016, at 15:58, Lou Berger  wrote:
>=20
> Lada
>=20
> See below
>=20
> On 5/23/2016 9:43 AM, Ladislav Lhotka wrote:
>>> On 23 May 2016, at 14:30, Lou Berger  wrote:
>>>=20
>>> Hi Lada,
>>>   I looks like no one really jumped on this one -- so better late =
than
>>> never ...
>>>=20
>>> When looking at the question below, we should consider the uses =
cases.=20
>>> I'm particularity interested (as a contributor) in the use case of
>>> nested mounts (NIs mounted within LNEs), as well as the case if  =
models
>>> that will only permit mounting of specific other models vs =
generically
>>> mounting any model.
>>>=20
>>> On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
>>>> Hi,
>>>>=20
>>>> with a schema mount mechanism in place, there are two different =
options
>>>> for constructing the overall schema (their combinations are =
possible,
>>>> too):
>>>>=20
>>>> 1. Define schema mount as an extension of YANG library so that it
>>>> defines YANG modules, revisions, features and deviations as before =
but
>>>> also the way how they are combined into a hierarchical structure of
>>>> schemas.
>>> I think this only makes sense if this is scoped in some way.  For
>>> example, with LNEs, the parent/host server may not have visibility =
into
>>> the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And even =
if
>> As I understand it, schema-mount is about accessing the LNE models =
from the parent/host management interface. I believe the real question =
is whether we want to allow the schema to dynamically change at run time =
and possibly throw in new modules that the client never heard of. #2 can =
do it while #1 can't. I am not sure though whether the LNE model really =
requires something like this.
>=20
> Again there are different use cases.  In the fixed-mount case (where a
> module containing the mount specifies what model is being mounted) a
> client will always know what to expect.  In the LNE and probably even =
NI
> cases, a single client may talk to multiple servers, each of which may
> have different mounted models.  I'm less sure about a single server =
with
> different models mounted under different NIs, but this is certainly
> possible in the LNE case.

OK, so it seems to be related to the use cases for peer mount, which IMO =
has a lot of other issues to solve.

>=20
>>> does, you have to consider the cases of mounted models contained =
within
>>> mounted models.
>> This is possible either way, provided that the complete schema is =
known upfront.
>=20
> I think the complete schema is likely to be known by there server
> upfront in all cases, but not the client.

Well, if the server knows everything upfront, it can also publish the =
schema in the compact form. A client may not support everything but at =
least it is able to tell whether it is the case or not.

Lada

>=20
> Lou
>>>> 2. Apart from YANG Library data, the server just specifies the =
mount
>>>> points. A client of an NM protocol is expected to fetch a new =
instance
>>>> of YANG library and/or subordinate mount points as state data from =
a
>>>> well-known location under each mount point.
>>> I think this depends on the use case.  For LNEs, I think this is =
right.=20
>>> For some of the other possible use cases being discussed only a =
specific
>>> model can be mounted.
>> I guess I need some example scenarios demonstrating that #1 cannot be =
used for LNE.
>>=20
>> Lada=20
>>=20
>>>> I think that #1 should be available (alone or along with #2) =
because
>>>> there are cases when YANG is used as a data modelling language =
outside
>>>> the context of a NM protocol =E2=80=93 Eliot Lear's MUD =
presentation is one
>>>> example.
>>> I think we (the rtg yang arch dt) had envisioned  something closer =
to
>>> 2.  And as you say, an approach that also includes a properly scoped =
1
>>> is possible.
>>>=20
>>> Lou
>>>=20
>>>> Lada
>>>>=20
>>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Mon May 23 07:56:14 2016
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 CCD4312D907 for ; Mon, 23 May 2016 07:56:11 -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 dGOJH8MF_dUW for ; Mon, 23 May 2016 07:56:08 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98FA12D905 for ; Mon, 23 May 2016 07:56:06 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id o16so55261354ywd.2 for ; Mon, 23 May 2016 07:56:06 -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:date:message-id:subject:from:to :cc; bh=QR3WcsOs8khTcy0umc8JjE83gTeAs74VcsmLOXuPfh4=; b=fEtDDazyT1ODQ2bq0/yNlUsKlKA0/VzMckc5mdUULIzP8XL6Up9YbGKjl0T4z8ntZB nk6OTmokvwmyTiOch0fdBuuG0tfLEegSCYn/Lk3db2MottPEUIDa/ncZBzeADAhh3Sn2 A1Q0+plRE73K1eZRvjsSgma1SjmZH22sZt6/p6Xlwo2v+EFM+ff5ycJ47oTacs3Hdy8O CapqUYqZvP0mm1K9kgKuuwsUGOV7DTTWuHvrpYlhWhFdTrY6I3RG4POWUUwvbM996nmg yjK/1DEnQ633zuu9rrB/0lXf5SuyN7nqzQ3xKLv7Vk8NOO3b90Yq0osUDp+nVHYbSrc+ yOqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=QR3WcsOs8khTcy0umc8JjE83gTeAs74VcsmLOXuPfh4=; b=EuQyGjVl/jyGeF1twSy4JvrYjzTx+8/uOBxrg5NYQOvzaufwgb46iDujWb7tgsaKXo 6jttoL3VBwSHFlrQD5OK4T7fYlWzTxNSBuV1y74Mlo8tTGmD0Tz0YGjAdax1BFirAa3C l0Xix0VlT32IyOYoxM5twfEdi0gKFU0D49W14wO41ooG9PQYxp3+V5s7bIgeZxiDmCly M5NUxRuz/PZfSjI6DkcUoYShegVrVinWzzUd4LTWlwcLkA9Xt8iHZNnwft/dtEUyWakl dD7nPmQNW6plgLQMZuEFsinnqD5+PI81uQOrdDIkluwSkroh/Vd1FecSxSf2F0yQVvAo /1xQ==
X-Gm-Message-State: AOPr4FVsFAW9B0TzGI/VjQBfwGXWLDBmPIYXPWSl1vP+m7gk1VxjuE173ECCq4Y8cTAmp+WukmTI0PQ+HYq2dA==
MIME-Version: 1.0
X-Received: by 10.129.101.137 with SMTP id z131mr10556765ywb.88.1464015365850;  Mon, 23 May 2016 07:56:05 -0700 (PDT)
Received: by 10.37.44.130 with HTTP; Mon, 23 May 2016 07:56:05 -0700 (PDT)
In-Reply-To: <20160523.160845.386020102124289824.mbj@tail-f.com>
References: <20160523.160845.386020102124289824.mbj@tail-f.com>
Date: Mon, 23 May 2016 07:56:05 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a114c6d8cd41b38053383a3c0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] if-feature in default value
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 14:56:12 -0000

--001a114c6d8cd41b38053383a3c0
Content-Type: text/plain; charset=UTF-8

On Mon, May 23, 2016 at 7:08 AM, Martin Bjorklund  wrote:

> Hi,
>
> This comment from the Gen-ART review deserves it's own thread.
>
>
> gen-art> - section 7.6.4
> gen-art>
> gen-art>    The default value MUST NOT be marked with an "if-feature"
> statement.
> gen-art>
> [...]
> gen-art> But it's not clear what the whole set of situations is that
> should be
> gen-art> forbidden.  For instance, this should work:
> gen-art>
> gen-art>      typedef xyz {
> gen-art>        type enumeration {
> gen-art>         enum blue { if-feature blue; }
> gen-art>         ...
> gen-art>        }
> gen-art>      }
> gen-art>
> gen-art>      leaf color {
> gen-art>        if-feature blue;
> gen-art>        type xyz;
> gen-art>        default blue;
> gen-art>      }
> gen-art>
> gen-art> Whereas this won't:
> gen-art>
> gen-art>      typedef xyz {
> gen-art>        type enumeration {
> gen-art>         enum blue { if-feature blue; }
> gen-art>         ...
> gen-art>        }
> gen-art>      }
> gen-art>
> gen-art>      leaf color {
> gen-art>        // No if-feature here.
> gen-art>        type xyz;
> gen-art>        default blue;
> gen-art>      }
> gen-art>
> gen-art> Is this rule only meant to cover the situation where the leaf's
> type
> gen-art> is an "in-line" enum and the particular enum value has an
> if-feature?
>
> mbj> Good point.  Yes, the first example should be valid.  Another valid
> mbj> example would be:
> mbj>
> mbj>     container colors {
> mbj>       if-feature blue;
> mbj>       leaf color {
> mbj>         type xyz;
> mbj>         default blue;
> mbj>       }
> mbj>     }
> mbj>
> mbj> Maybe:
> mbj>
> mbj> OLD:
> mbj>
> mbj>   The definition of the default value MUST NOT be marked with an
> mbj>   "if-feature" statement.
> mbj>
> mbj> NEW:
> mbj>
> mbj>   If the definition of the default value is conditional based on one
> or
> mbj>   more features (see ^if-feature^), then the leaf node MUST
> mbj>   also be conditional based on at least the same set of features.
> mbj>
> mbj> (modelled after the text in 9.9)
>
> Does anyone have comments on this proposal?
>
>

What problem is this supposed to solve?
If the server does not advertise feature "blue", then the default-stmt
is still invalid.   Are you suggesting that defining defaults that depend on
features is a conformance mechanism for declaring a feature to be mandatory?



>
> /martin
>
>
Andy


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

--001a114c6d8cd41b38053383a3c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, May 23, 2016 at 7:08 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Hi,



This comment from the Gen-ART review deserves it's own thread.





gen-art> - section 7.6.4

gen-art>

gen-art>=C2=A0 =C2=A0 The default value MUST NOT be marked with an "=
;if-feature" statement.

gen-art>

[...]

gen-art> But it's not clear what the whole set of situations is that=
 should be

gen-art> forbidden.=C2=A0 For instance, this should work:

gen-art>

gen-art>=C2=A0 =C2=A0 =C2=A0 typedef xyz {

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum blue { if-feature blue; }=


gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

gen-art>=C2=A0 =C2=A0 =C2=A0 }

gen-art>

gen-art>=C2=A0 =C2=A0 =C2=A0 leaf color {

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if-feature blue;

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type xyz;

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 default blue;

gen-art>=C2=A0 =C2=A0 =C2=A0 }

gen-art>

gen-art> Whereas this won't:

gen-art>

gen-art>=C2=A0 =C2=A0 =C2=A0 typedef xyz {

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum blue { if-feature blue; }=


gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

gen-art>=C2=A0 =C2=A0 =C2=A0 }

gen-art>

gen-art>=C2=A0 =C2=A0 =C2=A0 leaf color {

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // No if-feature here.

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type xyz;

gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 default blue;

gen-art>=C2=A0 =C2=A0 =C2=A0 }

gen-art>

gen-art> Is this rule only meant to cover the situation where the leaf&#=
39;s type

gen-art> is an "in-line" enum and the particular enum value ha=
s an if-feature?



mbj> Good point.=C2=A0 Yes, the first example should be valid.=C2=A0 Ano=
ther valid

mbj> example would be:

mbj>

mbj>=C2=A0 =C2=A0 =C2=A0container colors {

mbj>=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature blue;

mbj>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf color {

mbj>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type xyz;

mbj>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default blue;

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

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

mbj>

mbj> Maybe:

mbj>

mbj> OLD:

mbj>

mbj>=C2=A0 =C2=A0The definition of the default value MUST NOT be marked =
with an

mbj>=C2=A0 =C2=A0"if-feature" statement.

mbj>

mbj> NEW:

mbj>

mbj>=C2=A0 =C2=A0If the definition of the default value is conditional b=
ased on one or

mbj>=C2=A0 =C2=A0more features (see ^if-feature^), then the leaf node MU=
ST

mbj>=C2=A0 =C2=A0also be conditional based on at least the same set of f=
eatures.

mbj>

mbj> (modelled after the text in 9.9)



Does anyone have comments on this proposal?




What problem is this su=
pposed to solve?
If the server does not advertise feature "b=
lue", then the default-stmt
is still invalid. =C2=A0 Are you=
 suggesting that defining defaults that depend on
features is a c=
onformance mechanism for declaring a feature to be mandatory?
=C2=A0



/martin



Andy
=C2=A0

_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a114c6d8cd41b38053383a3c0--


From nobody Mon May 23 08:29:50 2016
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 3049F12D991 for ; Mon, 23 May 2016 08:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 c92CpWZ-C-si for ; Mon, 23 May 2016 08:29:45 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA5B12D98E for ; Mon, 23 May 2016 08:29:42 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:19c4:f68e:489c:53ba] (unknown [IPv6:2001:718:1a02:1:19c4:f68e:489c:53ba]) by mail.nic.cz (Postfix) with ESMTPSA id CDADB6099B; Mon, 23 May 2016 17:29:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464017380; bh=y9qPESD7WygmgveHob4ZGhgpqO1aEO4KmQLiG4aRSV8=; h=From:Date:To; b=cFPIEIbsaF261FfevzLTl0FRwhzkABwWq5QBiaBMSRozc4dWMRE3FvmMlM/fyZVN7 3ayF9urWHzuDqIitXc7l0J5byLvbthC1RIahKcOElgpZ2hdRpjDVRZpUTH+JF0YSBY ocNW6j719HCvoPrsXUxy0dlifA3XrNbW2uJjpDBQ=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160523.161038.800274078120441332.mbj@tail-f.com>
Date: Mon, 23 May 2016 17:29:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160523.161038.800274078120441332.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 15:29:48 -0000

> On 23 May 2016, at 16:10, Martin Bjorklund  wrote:
>=20
> Hi,
>=20
> This comment from the Gen-ART review deserves it's own thread.
>=20
> gen-art> - section 9.9
> gen-art>=20
> gen-art>    The leafref type is used to declare a constraint on the =
value space
> gen-art>    of a leaf, based on a reference to a set of leaf instances =
in the
> gen-art>    data tree.  The "path" substatement (Section 9.9.2) =
selects a set of
> gen-art>    leaf instances, and the leafref value space is the set of =
values of
> gen-art>    these leaf instances.
> gen-art>=20
> gen-art> The first sentence isn't quite right.  Perhaps:
> gen-art>=20
> gen-art>    The value space of a leaf with leafref type is one of the =
values of
> gen-art>    a set of leaf instances in the data tree.  The "path" =
substatement
> gen-art>    (Section 9.9.2) selects the set of leaf instances, and the =
leafref
> gen-art>    value space is the set of values of these leaf instances.
> gen-art>
> gen-art> - section 9.9.3
> gen-art>=20
> gen-art>    If "require-instance" is "true", it means that the =
instance being
> gen-art>    referred MUST exist for the data to be valid.  This =
constraint is
> gen-art>    enforced according to the rules in Section 8.
> gen-art>=20
> gen-art>    If "require-instance" is "false", it means that the =
instance being
> gen-art>    referred MAY exist in valid data.
> gen-art>=20
> [...]
> gen-art> Also, I think the second paragraph means that if =
require-instance is
> gen-art> false, the referred-to instance need not exist.  But it's not =
clear to
> gen-art> me what that would mean -- if there are no instances =
referenced by the
> gen-art> XPath expression, then the set of value values of the leafref =
would be
> gen-art> empty and the leafref would necessarily be invalid. ...  I =
think these
> gen-art> paragraphs need to be expanded in some way.
>=20
> mbj> Right; so what we want to say is:
> mbj>=20
> mbj>   - the value space is the same as the value space of the =
referred
> mbj>     leaf
> mbj>=20
> mbj>   - there is an additional constraint if require-instance is true =
that
> mbj>     the referred to leaf instance must exist
> mbj>=20
> mbj> How about
> mbj>=20
> mbj> OLD:
> mbj>=20
> mbj>    The leafref type is used to declare a constraint on the value =
space
> mbj>    of a leaf, based on a reference to a set of leaf instances in =
the
> mbj>    data tree.  The "path" substatement (Section 9.9.2) selects a =
set of
> mbj>    leaf instances, and the leafref value space is the set of =
values of
> mbj>    these leaf instances.
> mbj>=20
> mbj>    If the leaf with the leafref type represents configuration =
data, and
> mbj>    the "require-instance" property (Section 9.9.3) is "true", the =
leaf
> mbj>    it refers to MUST also represent configuration.  Such a leaf =
puts a
> mbj>    constraint on valid data.  All such nodes MUST reference =
existing
> mbj>    leaf instances or leafs with default values in use (see =
Section 7.6.1
> mbj>    and Section 7.7.2) for the data to be valid.  This constraint =
is
> mbj>    enforced according to the rules in Section 8.
> mbj>=20
> mbj> NEW:
> mbj>=20
> mbj>    The leafref type is used to declare a constraint on the value =
space
> mbj>    of a leaf, based on a reference to a set of leaf instances in =
the
> mbj>    data tree.  The "path" substatement (Section 9.9.2) is used to =
refer
> mbj>    to another leaf node.  The leafref value space is the value =
space of
> mbj>    this leaf node.

This mixes up paths in the data tree with those in the schema tree. The =
XPath expression in the "path" statement is evaluated in the context of =
a data tree, but if the result is an empty node set, then "this leaf =
node" makes no sense.

A specific example:

leaf fooref {
  type leafref {
    path "../foo";
    require-instance false;
  }
}

leaf foo {
  type uint8;
  when "../bar < 42";
}

leaf bar {  =20
  type uint8;
  default 100;
}

If there is neither "foo" nor "bar" in the data tree, what is the value =
space of "fooref"?

Lada

> mbj>=20
> mbj>    If the "require-instance" property is "true", there MUST exist =
an
> mbj>    instance, or a leaf with a default value in use (see Section =
7.6.1
> mbj>    and Section 7.7.2), of the leaf being referred to with the =
same value
> mbj>    as the leafref value in a valid data tree.
> mbj>=20
> mbj>    If the leaf with the leafref type represents configuration =
data, and
> mbj>    the "require-instance" property (Section 9.9.3) is "true", the =
leaf
> mbj>    it refers to MUST also represent configuration.
>=20
>=20
> Does anyone have comments on this proposal?
>=20
>=20
> /martin
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Mon May 23 09:07:31 2016
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 4F5F212D19E for ; Mon, 23 May 2016 09:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 w9fxIHcHQcyS for ; Mon, 23 May 2016 09:07:23 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500DD12D9B4 for ; Mon, 23 May 2016 09:07:23 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:19c4:f68e:489c:53ba] (unknown [IPv6:2001:718:1a02:1:19c4:f68e:489c:53ba]) by mail.nic.cz (Postfix) with ESMTPSA id CBCD7607DC; Mon, 23 May 2016 18:07:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464019641; bh=kRKeg4I+jUhMaUfNaQ+xkkpPbL6clfdq6gkaihHQ8gM=; h=From:Date:To; b=BTjlFVKPIEzmGq59EgQdiwaR9KxHmbXfc3fKyKK1xgcBVDzie4J51J/k8iLCeGcmj rN7tXY1yq5B3sbE/1sU0gYdcKmJ4uFBGW31zS2aupRDJKSRbjP0ITiMHnAg44i3xCN 5uq5BN4Y/M0tbbXx1RLbau4p0GwdO9GPpaho+u80=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160523.154309.848500367505009627.mbj@tail-f.com>
Date: Mon, 23 May 2016 18:07:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <054FFDF1-9D06-4B61-8C8F-AAA9ACFAD3F5@nic.cz>
References: <877feyrdz9.fsf@hobgoblin.ariadne.com> <20160523.154309.848500367505009627.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: worley@ariadne.com, netmod@ietf.org
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 16:07:30 -0000

> On 23 May 2016, at 15:43, Martin Bjorklund  wrote:
>=20
>=20
>> - section 3.1
>>=20
>> There is an overall question regarding whitespace in XML in
>> "non-significant" places.  Is it allowed in the XML representation of
>> data trees?  And if so, precisely what whitespace is allowed?  Also,
>> to what degree is the whitespace shown in examples what is allowed on
>> the wire, and to what degree is it there just to make the example
>> easier to read?  (It's possible that XML has implemented some sort of
>> global solution for the issue of non-significant whitespace, but back
>> when I was using it regularly, there was none.)
>=20
> Good catch!  Interesting that noone has found this before!

This follows from the fact that YANG doesn't support mixed content: =
there is no way how this whitespace can be made significant.

>=20
> I think we need to say that whitespace is insignificant between
> elements.  So I propose to add a paragraph to the end of 7.5.7
> (container XML encoding rules):
>=20
> NEW:
>=20
>  Any whitespace between the subelements to the container is
>  insignificant, i.e., an implementation MAY insert whitespace
>  characters between subelements.
>=20
> and insert a fourth paragraph in 7.8.5 (list XML encoding rules):
>=20
> NEW:
>=20
>  Any whitespace between the subelements to the list entry is
>  insignificant, i.e., an implementation MAY insert whitespace
>  characters between subelements.

I think this clarification would be useful, but maybe it should be =
stated separately (not in container/list sections) because it also =
applies to whitespace at the top level of a document. It could also say =
that other character data or CDATA sections are not permitted. What =
about comments and processing instructions?

Lada

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





From nobody Mon May 23 10:59:00 2016
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 9525D12DA26 for ; Mon, 23 May 2016 10:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 vnT40KYj1sPY for ; Mon, 23 May 2016 10:58:57 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0A23B12D8D8 for ; Mon, 23 May 2016 10:58:56 -0700 (PDT)
Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 0B42A1AE0386; Mon, 23 May 2016 19:58:55 +0200 (CEST)
Date: Mon, 23 May 2016 19:58:54 +0200 (CEST)
Message-Id: <20160523.195854.939392582596188168.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <20160523.160845.386020102124289824.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] if-feature in default value
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 17:58:58 -0000

Andy Bierman  wrote:
> On Mon, May 23, 2016 at 7:08 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > This comment from the Gen-ART review deserves it's own thread.
> >
> >
> > gen-art> - section 7.6.4
> > gen-art>
> > gen-art>    The default value MUST NOT be marked with an "if-feature"
> > statement.
> > gen-art>
> > [...]
> > gen-art> But it's not clear what the whole set of situations is that
> > should be
> > gen-art> forbidden.  For instance, this should work:
> > gen-art>
> > gen-art>      typedef xyz {
> > gen-art>        type enumeration {
> > gen-art>         enum blue { if-feature blue; }
> > gen-art>         ...
> > gen-art>        }
> > gen-art>      }
> > gen-art>
> > gen-art>      leaf color {
> > gen-art>        if-feature blue;
> > gen-art>        type xyz;
> > gen-art>        default blue;
> > gen-art>      }
> > gen-art>
> > gen-art> Whereas this won't:
> > gen-art>
> > gen-art>      typedef xyz {
> > gen-art>        type enumeration {
> > gen-art>         enum blue { if-feature blue; }
> > gen-art>         ...
> > gen-art>        }
> > gen-art>      }
> > gen-art>
> > gen-art>      leaf color {
> > gen-art>        // No if-feature here.
> > gen-art>        type xyz;
> > gen-art>        default blue;
> > gen-art>      }
> > gen-art>
> > gen-art> Is this rule only meant to cover the situation where the leaf's
> > type
> > gen-art> is an "in-line" enum and the particular enum value has an
> > if-feature?
> >
> > mbj> Good point.  Yes, the first example should be valid.  Another valid
> > mbj> example would be:
> > mbj>
> > mbj>     container colors {
> > mbj>       if-feature blue;
> > mbj>       leaf color {
> > mbj>         type xyz;
> > mbj>         default blue;
> > mbj>       }
> > mbj>     }
> > mbj>
> > mbj> Maybe:
> > mbj>
> > mbj> OLD:
> > mbj>
> > mbj>   The definition of the default value MUST NOT be marked with an
> > mbj>   "if-feature" statement.
> > mbj>
> > mbj> NEW:
> > mbj>
> > mbj>   If the definition of the default value is conditional based on one
> > or
> > mbj>   more features (see ^if-feature^), then the leaf node MUST
> > mbj>   also be conditional based on at least the same set of features.
> > mbj>
> > mbj> (modelled after the text in 9.9)
> >
> > Does anyone have comments on this proposal?
> >
> >
> 
> What problem is this supposed to solve?

See the first of the examples above.

> If the server does not advertise feature "blue", then the default-stmt
> is still invalid.

Correct.

> Are you suggesting that defining defaults that depend on
> features is a conformance mechanism for declaring a feature to be mandatory?

No.  Just that if the if-feature expression on the leaf matches (or is
more restrictive than) then if-feature on the default value, it should
work.


/martin


From nobody Mon May 23 11:05:48 2016
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 31BF512DA1E for ; Mon, 23 May 2016 11:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 b9IAqJS5Ol8P for ; Mon, 23 May 2016 11:05:45 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 42D7E12DA19 for ; Mon, 23 May 2016 11:05:45 -0700 (PDT)
Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 7CA171AE0386; Mon, 23 May 2016 20:05:44 +0200 (CEST)
Date: Mon, 23 May 2016 20:05:44 +0200 (CEST)
Message-Id: <20160523.200544.822321137503322397.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20160523.161038.800274078120441332.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 18:05:47 -0000

Ladislav Lhotka  wrote:
> 
> > On 23 May 2016, at 16:10, Martin Bjorklund  wrote:
> > 
> > Hi,
> > 
> > This comment from the Gen-ART review deserves it's own thread.
> > 
> > gen-art> - section 9.9
> > gen-art> 
> > gen-art>    The leafref type is used to declare a constraint on the value space
> > gen-art>    of a leaf, based on a reference to a set of leaf instances in the
> > gen-art>    data tree.  The "path" substatement (Section 9.9.2) selects a set of
> > gen-art>    leaf instances, and the leafref value space is the set of values of
> > gen-art>    these leaf instances.
> > gen-art> 
> > gen-art> The first sentence isn't quite right.  Perhaps:
> > gen-art> 
> > gen-art>    The value space of a leaf with leafref type is one of the values of
> > gen-art>    a set of leaf instances in the data tree.  The "path" substatement
> > gen-art>    (Section 9.9.2) selects the set of leaf instances, and the leafref
> > gen-art>    value space is the set of values of these leaf instances.
> > gen-art>
> > gen-art> - section 9.9.3
> > gen-art> 
> > gen-art>    If "require-instance" is "true", it means that the instance being
> > gen-art>    referred MUST exist for the data to be valid.  This constraint is
> > gen-art>    enforced according to the rules in Section 8.
> > gen-art> 
> > gen-art>    If "require-instance" is "false", it means that the instance being
> > gen-art>    referred MAY exist in valid data.
> > gen-art> 
> > [...]
> > gen-art> Also, I think the second paragraph means that if require-instance is
> > gen-art> false, the referred-to instance need not exist.  But it's not clear to
> > gen-art> me what that would mean -- if there are no instances referenced by the
> > gen-art> XPath expression, then the set of value values of the leafref would be
> > gen-art> empty and the leafref would necessarily be invalid. ...  I think these
> > gen-art> paragraphs need to be expanded in some way.
> > 
> > mbj> Right; so what we want to say is:
> > mbj> 
> > mbj>   - the value space is the same as the value space of the referred
> > mbj>     leaf
> > mbj> 
> > mbj>   - there is an additional constraint if require-instance is true that
> > mbj>     the referred to leaf instance must exist
> > mbj> 
> > mbj> How about
> > mbj> 
> > mbj> OLD:
> > mbj> 
> > mbj>    The leafref type is used to declare a constraint on the value space
> > mbj>    of a leaf, based on a reference to a set of leaf instances in the
> > mbj>    data tree.  The "path" substatement (Section 9.9.2) selects a set of
> > mbj>    leaf instances, and the leafref value space is the set of values of
> > mbj>    these leaf instances.
> > mbj> 
> > mbj>    If the leaf with the leafref type represents configuration data, and
> > mbj>    the "require-instance" property (Section 9.9.3) is "true", the leaf
> > mbj>    it refers to MUST also represent configuration.  Such a leaf puts a
> > mbj>    constraint on valid data.  All such nodes MUST reference existing
> > mbj>    leaf instances or leafs with default values in use (see Section 7.6.1
> > mbj>    and Section 7.7.2) for the data to be valid.  This constraint is
> > mbj>    enforced according to the rules in Section 8.
> > mbj> 
> > mbj> NEW:
> > mbj> 
> > mbj>    The leafref type is used to declare a constraint on the value space
> > mbj>    of a leaf, based on a reference to a set of leaf instances in the
> > mbj>    data tree.  The "path" substatement (Section 9.9.2) is used to refer
> > mbj>    to another leaf node.  The leafref value space is the value space of
> > mbj>    this leaf node.
> 
> This mixes up paths in the data tree with those in the schema
> tree. The XPath expression in the "path" statement is evaluated in
> the context of a data tree, but if the result is an empty node set,
> then "this leaf node" makes no sense.

The fact is that the path statement refers to instances of one leaf
node which exists in the schema tree.  The current text doesn't really
work with "require-instance false".  For example:

   list interface
     leaf name {
       type string;
     }
   }

   leaf if-ref {
     type leafref {
       path /interface/name;
       require-instance false;
     }
   }

The idea is that this would be valid:

  
    eth0
  

  eth2

The current text says that the value space of "if-ref" is { "eth0" },
but the intention is to be able to refer to "non-existing values".

The current text also doesn't allow non-existing references in
the candidate.

> A specific example:
> 
> leaf fooref {
>   type leafref {
>     path "../foo";
>     require-instance false;
>   }
> }
> 
> leaf foo {
>   type uint8;
>   when "../bar < 42";
> }
> 
> leaf bar {   
>   type uint8;
>   default 100;
> }
> 
> If there is neither "foo" nor "bar" in the data tree, what is the
> value space of "fooref"?

With the new text it would be uint8.


/martin


> 
> Lada
> 
> > mbj> 
> > mbj>    If the "require-instance" property is "true", there MUST exist an
> > mbj>    instance, or a leaf with a default value in use (see Section 7.6.1
> > mbj>    and Section 7.7.2), of the leaf being referred to with the same value
> > mbj>    as the leafref value in a valid data tree.
> > mbj> 
> > mbj>    If the leaf with the leafref type represents configuration data, and
> > mbj>    the "require-instance" property (Section 9.9.3) is "true", the leaf
> > mbj>    it refers to MUST also represent configuration.
> > 
> > 
> > Does anyone have comments on this proposal?
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 


From nobody Mon May 23 11:07:01 2016
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 548E412DA45 for ; Mon, 23 May 2016 11:06: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, 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 piZxBvd4CVaU for ; Mon, 23 May 2016 11:06:57 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8BB12DA1E for ; Mon, 23 May 2016 11:06:57 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id c127so61686132ywb.1 for ; Mon, 23 May 2016 11:06:57 -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:date:message-id:subject:from:to :cc; bh=38v3Q0pb3yfrPN2RB3N4YTl4qKPfJsCUS/+ihkSTUto=; b=Q9orAgWFUbMHkWq0ZYt1xKH68EVsjyOSFS7gL9o6oX9LJSZiTDOYgBq12wctbEWTdw w9J13Id5A0E2cGTSuwQXJjmtVU6iI5prqGShIUGCwKQGIiEeGmabYPEI5DcWg0dnSWnd FO5KeJ1E4kWI4CSEGHJczPcoCDn4/YtDHQGkGHwfFyYU+7RqK7wQ9fBuUkSm8Qp8nO1U mjuzu6Vv2fcD0frQY4FoQZm8S3rV72GO1aYGbGxRHUCJTrJQu7yR+Tg63N22iJX60Bsm K8BhkT5VUsnDIvIlogipRHWS/KH+dTkCQTRKRNx1ke4FDkGNHS1AUa8iy5mpdjyZFLXe RrOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=38v3Q0pb3yfrPN2RB3N4YTl4qKPfJsCUS/+ihkSTUto=; b=l/ODnJbaCvVlg0ZIgrIsuvQQNk4TJpTbZzRkRaJgf/f9CsmiFH+TQa9EJViHoXukgR w6MP8pxkWifeSFpdkyalONjckDAmeE2esizx0LPCedX4rLxQy91b3vrfTlK5gNw3DDKb Pnv4WBoEmKZ6wnFe8ES/qwPGWtwTINYXV+6mE03y0km3k0SPnaDzjCHdTmaJK0ioUppe wiwsmXSt+NbkDjIF1s/PHF7Iu8l5xwe7VnhZEtacz71eIf4J4J7Wz8GwxZXp2UVZZF4b U5rgCKSH4PrVl748SI0ixR35+B0avYHtnNH2h8d3f5LqGyBW43sf9sbrvASbvuxS6Ier /uWQ==
X-Gm-Message-State: ALyK8tKtMWdpBSdMYL8PkPiKiS+rpqcjADHH/qjWnYyHEjyRv+4ptp52ZvheRAroxl3wJB+6GS9tthe75N6liQ==
MIME-Version: 1.0
X-Received: by 10.13.202.207 with SMTP id m198mr114219ywd.140.1464026816609; Mon, 23 May 2016 11:06:56 -0700 (PDT)
Received: by 10.37.44.130 with HTTP; Mon, 23 May 2016 11:06:56 -0700 (PDT)
In-Reply-To: <20160523.195854.939392582596188168.mbj@tail-f.com>
References: <20160523.160845.386020102124289824.mbj@tail-f.com>  <20160523.195854.939392582596188168.mbj@tail-f.com>
Date: Mon, 23 May 2016 11:06:56 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11482d6a58dccd0533864e7b
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] if-feature in default value
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 18:06:59 -0000

--001a11482d6a58dccd0533864e7b
Content-Type: text/plain; charset=UTF-8

On Mon, May 23, 2016 at 10:58 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Mon, May 23, 2016 at 7:08 AM, Martin Bjorklund 
> wrote:
> >
> > > Hi,
> > >
> > > This comment from the Gen-ART review deserves it's own thread.
> > >
> > >
> > > gen-art> - section 7.6.4
> > > gen-art>
> > > gen-art>    The default value MUST NOT be marked with an "if-feature"
> > > statement.
> > > gen-art>
> > > [...]
> > > gen-art> But it's not clear what the whole set of situations is that
> > > should be
> > > gen-art> forbidden.  For instance, this should work:
> > > gen-art>
> > > gen-art>      typedef xyz {
> > > gen-art>        type enumeration {
> > > gen-art>         enum blue { if-feature blue; }
> > > gen-art>         ...
> > > gen-art>        }
> > > gen-art>      }
> > > gen-art>
> > > gen-art>      leaf color {
> > > gen-art>        if-feature blue;
> > > gen-art>        type xyz;
> > > gen-art>        default blue;
> > > gen-art>      }
> > > gen-art>
> > > gen-art> Whereas this won't:
> > > gen-art>
> > > gen-art>      typedef xyz {
> > > gen-art>        type enumeration {
> > > gen-art>         enum blue { if-feature blue; }
> > > gen-art>         ...
> > > gen-art>        }
> > > gen-art>      }
> > > gen-art>
> > > gen-art>      leaf color {
> > > gen-art>        // No if-feature here.
> > > gen-art>        type xyz;
> > > gen-art>        default blue;
> > > gen-art>      }
> > > gen-art>
> > > gen-art> Is this rule only meant to cover the situation where the
> leaf's
> > > type
> > > gen-art> is an "in-line" enum and the particular enum value has an
> > > if-feature?
> > >
> > > mbj> Good point.  Yes, the first example should be valid.  Another
> valid
> > > mbj> example would be:
> > > mbj>
> > > mbj>     container colors {
> > > mbj>       if-feature blue;
> > > mbj>       leaf color {
> > > mbj>         type xyz;
> > > mbj>         default blue;
> > > mbj>       }
> > > mbj>     }
> > > mbj>
> > > mbj> Maybe:
> > > mbj>
> > > mbj> OLD:
> > > mbj>
> > > mbj>   The definition of the default value MUST NOT be marked with an
> > > mbj>   "if-feature" statement.
> > > mbj>
> > > mbj> NEW:
> > > mbj>
> > > mbj>   If the definition of the default value is conditional based on
> one
> > > or
> > > mbj>   more features (see ^if-feature^), then the leaf node MUST
> > > mbj>   also be conditional based on at least the same set of features.
> > > mbj>
> > > mbj> (modelled after the text in 9.9)
> > >
> > > Does anyone have comments on this proposal?
> > >
> > >
> >
> > What problem is this supposed to solve?
>
> See the first of the examples above.
>
> > If the server does not advertise feature "blue", then the default-stmt
> > is still invalid.
>
> Correct.
>
> > Are you suggesting that defining defaults that depend on
> > features is a conformance mechanism for declaring a feature to be
> mandatory?
>
> No.  Just that if the if-feature expression on the leaf matches (or is
> more restrictive than) then if-feature on the default value, it should
> work.
>
>

OK -- conditional values don't matter if the leaf is not enabled.
This is non-trivial to check but I know that doesn't matter.
Most of YANG 1.1 is that way.



>
> /martin
>


Andy

--001a11482d6a58dccd0533864e7b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, May 23, 2016 at 10:58 AM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> On Mon, May 23, 2016 at 7:08 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

>

> > Hi,

> >

> > This comment from the Gen-ART review deserves it's own thread=
.

> >

> >

> > gen-art> - section 7.6.4

> > gen-art>

> > gen-art>=C2=A0 =C2=A0 The default value MUST NOT be marked wit=
h an "if-feature"

> > statement.

> > gen-art>

> > [...]

> > gen-art> But it's not clear what the whole set of situatio=
ns is that

> > should be

> > gen-art> forbidden.=C2=A0 For instance, this should work:

> > gen-art>

> > gen-art>=C2=A0 =C2=A0 =C2=A0 typedef xyz {

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum blue { if-featu=
re blue; }

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> > gen-art>=C2=A0 =C2=A0 =C2=A0 }

> > gen-art>

> > gen-art>=C2=A0 =C2=A0 =C2=A0 leaf color {

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if-feature blue;

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type xyz;

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 default blue;

> > gen-art>=C2=A0 =C2=A0 =C2=A0 }

> > gen-art>

> > gen-art> Whereas this won't:

> > gen-art>

> > gen-art>=C2=A0 =C2=A0 =C2=A0 typedef xyz {

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum blue { if-featu=
re blue; }

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> > gen-art>=C2=A0 =C2=A0 =C2=A0 }

> > gen-art>

> > gen-art>=C2=A0 =C2=A0 =C2=A0 leaf color {

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // No if-feature here.

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type xyz;

> > gen-art>=C2=A0 =C2=A0 =C2=A0 =C2=A0 default blue;

> > gen-art>=C2=A0 =C2=A0 =C2=A0 }

> > gen-art>

> > gen-art> Is this rule only meant to cover the situation where =
the leaf's

> > type

> > gen-art> is an "in-line" enum and the particular enu=
m value has an

> > if-feature?

> >

> > mbj> Good point.=C2=A0 Yes, the first example should be valid.=
=C2=A0 Another valid

> > mbj> example would be:

> > mbj>

> > mbj>=C2=A0 =C2=A0 =C2=A0container colors {

> > mbj>=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature blue;

> > mbj>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf color {

> > mbj>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type xyz;

> > mbj>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default blue;

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

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

> > mbj>

> > mbj> Maybe:

> > mbj>

> > mbj> OLD:

> > mbj>

> > mbj>=C2=A0 =C2=A0The definition of the default value MUST NOT =
be marked with an

> > mbj>=C2=A0 =C2=A0"if-feature" statement.

> > mbj>

> > mbj> NEW:

> > mbj>

> > mbj>=C2=A0 =C2=A0If the definition of the default value is con=
ditional based on one

> > or

> > mbj>=C2=A0 =C2=A0more features (see ^if-feature^), then the le=
af node MUST

> > mbj>=C2=A0 =C2=A0also be conditional based on at least the sam=
e set of features.

> > mbj>

> > mbj> (modelled after the text in 9.9)

> >

> > Does anyone have comments on this proposal?

> >

> >

>

> What problem is this supposed to solve?



See the first of the examples above.



> If the server does not advertise feature "blue", then the de=
fault-stmt

> is still invalid.



Correct.



> Are you suggesting that defining defaults that depend on

> features is a conformance mechanism for declaring a feature to be mand=
atory?



No.=C2=A0 Just that if the if-feature expression on the leaf matches (or is=


more restrictive than) then if-feature on the default value, it should

work.




OK -- conditional values don't ma=
tter if the leaf is not enabled.
This is non-trivial to check but=
 I know that doesn't matter.
Most of YANG 1.1 is that way.

=C2=A0



/martin




<=
/div>
Andy



--001a11482d6a58dccd0533864e7b--


From nobody Mon May 23 11:10:42 2016
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 83E7212DA50 for ; Mon, 23 May 2016 11:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 GpX9SBCOqsvK for ; Mon, 23 May 2016 11:10:38 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB1212DA35 for ; Mon, 23 May 2016 11:10:37 -0700 (PDT)
Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 9DD6A1AE0386; Mon, 23 May 2016 20:10:36 +0200 (CEST)
Date: Mon, 23 May 2016 20:10:36 +0200 (CEST)
Message-Id: <20160523.201036.1911774298216325604.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <054FFDF1-9D06-4B61-8C8F-AAA9ACFAD3F5@nic.cz>
References: <877feyrdz9.fsf@hobgoblin.ariadne.com> <20160523.154309.848500367505009627.mbj@tail-f.com> <054FFDF1-9D06-4B61-8C8F-AAA9ACFAD3F5@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: worley@ariadne.com, netmod@ietf.org
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 18:10:40 -0000

Ladislav Lhotka  wrote:
> 
> > On 23 May 2016, at 15:43, Martin Bjorklund  wrote:
> > 
> > 
> >> - section 3.1
> >> 
> >> There is an overall question regarding whitespace in XML in
> >> "non-significant" places.  Is it allowed in the XML representation of
> >> data trees?  And if so, precisely what whitespace is allowed?  Also,
> >> to what degree is the whitespace shown in examples what is allowed on
> >> the wire, and to what degree is it there just to make the example
> >> easier to read?  (It's possible that XML has implemented some sort of
> >> global solution for the issue of non-significant whitespace, but back
> >> when I was using it regularly, there was none.)
> > 
> > Good catch!  Interesting that noone has found this before!
> 
> This follows from the fact that YANG doesn't support mixed content:

No; we could have said that the encoding doesn't allow any data
between elements.

> there is no way how this whitespace can be made significant.
> 
> > 
> > I think we need to say that whitespace is insignificant between
> > elements.  So I propose to add a paragraph to the end of 7.5.7
> > (container XML encoding rules):
> > 
> > NEW:
> > 
> >  Any whitespace between the subelements to the container is
> >  insignificant, i.e., an implementation MAY insert whitespace
> >  characters between subelements.
> > 
> > and insert a fourth paragraph in 7.8.5 (list XML encoding rules):
> > 
> > NEW:
> > 
> >  Any whitespace between the subelements to the list entry is
> >  insignificant, i.e., an implementation MAY insert whitespace
> >  characters between subelements.
> 
> I think this clarification would be useful, but maybe it should be
> stated separately (not in container/list sections) because it also
> applies to whitespace at the top level of a document.

But that should be stated in the protocol spec.  YANG doesn't control
the top-level of those documents.

> It could also
> say that other character data or CDATA sections are not
> permitted. What about comments and processing instructions?

I don't think we have to say anything about them; they are handled
generically by the XML spec.  For example:

  Comments may appear anywhere in a document outside other markup; in
  addition, they may appear within the document type declaration at
  places allowed by the grammar. They are not part of the document's
  character data


/martin


From nobody Mon May 23 11:12:04 2016
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 0815512D0DE for ; Mon, 23 May 2016 11:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 sgI_p805dHkX for ; Mon, 23 May 2016 11:12:01 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3B112DA19 for ; Mon, 23 May 2016 11:12:01 -0700 (PDT)
Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id C65E61AE0478; Mon, 23 May 2016 20:12:00 +0200 (CEST)
Date: Mon, 23 May 2016 20:12:00 +0200 (CEST)
Message-Id: <20160523.201200.1577389167215259286.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <20160523.195854.939392582596188168.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] if-feature in default value
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 18:12:03 -0000

Andy Bierman  wrote:
> On Mon, May 23, 2016 at 10:58 AM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > On Mon, May 23, 2016 at 7:08 AM, Martin Bjorklund 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > This comment from the Gen-ART review deserves it's own thread.
> > > >
> > > >
> > > > gen-art> - section 7.6.4
> > > > gen-art>
> > > > gen-art>    The default value MUST NOT be marked with an "if-feature"
> > > > statement.
> > > > gen-art>
> > > > [...]
> > > > gen-art> But it's not clear what the whole set of situations is that
> > > > should be
> > > > gen-art> forbidden.  For instance, this should work:
> > > > gen-art>
> > > > gen-art>      typedef xyz {
> > > > gen-art>        type enumeration {
> > > > gen-art>         enum blue { if-feature blue; }
> > > > gen-art>         ...
> > > > gen-art>        }
> > > > gen-art>      }
> > > > gen-art>
> > > > gen-art>      leaf color {
> > > > gen-art>        if-feature blue;
> > > > gen-art>        type xyz;
> > > > gen-art>        default blue;
> > > > gen-art>      }
> > > > gen-art>
> > > > gen-art> Whereas this won't:
> > > > gen-art>
> > > > gen-art>      typedef xyz {
> > > > gen-art>        type enumeration {
> > > > gen-art>         enum blue { if-feature blue; }
> > > > gen-art>         ...
> > > > gen-art>        }
> > > > gen-art>      }
> > > > gen-art>
> > > > gen-art>      leaf color {
> > > > gen-art>        // No if-feature here.
> > > > gen-art>        type xyz;
> > > > gen-art>        default blue;
> > > > gen-art>      }
> > > > gen-art>
> > > > gen-art> Is this rule only meant to cover the situation where the
> > leaf's
> > > > type
> > > > gen-art> is an "in-line" enum and the particular enum value has an
> > > > if-feature?
> > > >
> > > > mbj> Good point.  Yes, the first example should be valid.  Another
> > valid
> > > > mbj> example would be:
> > > > mbj>
> > > > mbj>     container colors {
> > > > mbj>       if-feature blue;
> > > > mbj>       leaf color {
> > > > mbj>         type xyz;
> > > > mbj>         default blue;
> > > > mbj>       }
> > > > mbj>     }
> > > > mbj>
> > > > mbj> Maybe:
> > > > mbj>
> > > > mbj> OLD:
> > > > mbj>
> > > > mbj>   The definition of the default value MUST NOT be marked with an
> > > > mbj>   "if-feature" statement.
> > > > mbj>
> > > > mbj> NEW:
> > > > mbj>
> > > > mbj>   If the definition of the default value is conditional based on
> > one
> > > > or
> > > > mbj>   more features (see ^if-feature^), then the leaf node MUST
> > > > mbj>   also be conditional based on at least the same set of features.
> > > > mbj>
> > > > mbj> (modelled after the text in 9.9)
> > > >
> > > > Does anyone have comments on this proposal?
> > > >
> > > >
> > >
> > > What problem is this supposed to solve?
> >
> > See the first of the examples above.
> >
> > > If the server does not advertise feature "blue", then the default-stmt
> > > is still invalid.
> >
> > Correct.
> >
> > > Are you suggesting that defining defaults that depend on
> > > features is a conformance mechanism for declaring a feature to be
> > mandatory?
> >
> > No.  Just that if the if-feature expression on the leaf matches (or is
> > more restrictive than) then if-feature on the default value, it should
> > work.
> >
> >
> 
> OK -- conditional values don't matter if the leaf is not enabled.
> This is non-trivial to check but I know that doesn't matter.
> Most of YANG 1.1 is that way.

I was careful to use the same wording as is used in section 9.9 on
leafrefs:

   If the leaf that the leafref refers to is conditional based on one or
   more features (see Section 7.20.2), then the leaf with the leafref
   type MUST also be conditional based on at least the same set of
   features.

So we already have the complexity.


/martin


From nobody Tue May 24 01:15:17 2016
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 7C29B12DC9B for ; Tue, 24 May 2016 01:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 yGYYQsjNdudh for ; Tue, 24 May 2016 01:15:14 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A73512DB69 for ; Tue, 24 May 2016 01:15:14 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BE8D58EF; Tue, 24 May 2016 10:15:12 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nueQSXtmm2mW; Tue, 24 May 2016 10:15:05 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 May 2016 10:15:12 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 040752005E; Tue, 24 May 2016 10:15:12 +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 N82EzuTUX-Nb; Tue, 24 May 2016 10:15:11 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75EB420051; Tue, 24 May 2016 10:15:10 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 341ED3AEFE09; Tue, 24 May 2016 10:15:08 +0200 (CEST)
Date: Tue, 24 May 2016 10:15:08 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20160524081508.GA9434@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org
References: <20160523.161038.800274078120441332.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: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 08:15:16 -0000

On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:

[...]
 
> This mixes up paths in the data tree with those in the schema tree. The XPath expression in the "path" statement is evaluated in the context of a data tree, but if the result is an empty node set, then "this leaf node" makes no sense.
> 
> A specific example:
> 
> leaf fooref {
>   type leafref {
>     path "../foo";
>     require-instance false;
>   }
> }
> 
> leaf foo {
>   type uint8;
>   when "../bar < 42";
> }
> 
> leaf bar {   
>   type uint8;
>   default 100;
> }
> 
> If there is neither "foo" nor "bar" in the data tree, what is the value space of "fooref"?
>

Hm. Is it not both? The path refers to a schema node in order to
determine the base type (which is the base value set if
require-instance is false). If require-instance is true, then there is
an additional constraint that refers to a set of data nodes that
essentially determine a (possibly empty) subset of the value space.

If you agree with this, then we essentially have to phrase this
clearly.

/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 May 24 01:33:13 2016
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 F097212D50E for ; Tue, 24 May 2016 01:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 1e1qpgC_Kale for ; Tue, 24 May 2016 01:33:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AAE6B12D0EE for ; Tue, 24 May 2016 01:33:10 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id A96D91AE018A; Tue, 24 May 2016 10:33:08 +0200 (CEST)
Date: Tue, 24 May 2016 10:33:29 +0200 (CEST)
Message-Id: <20160524.103329.1771107175898375865.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20160524081508.GA9434@elstar.local>
References: <20160523.161038.800274078120441332.mbj@tail-f.com>  <20160524081508.GA9434@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 08:33:12 -0000

Juergen Schoenwaelder  wrote:
> On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
> 
> [...]
>  
> > This mixes up paths in the data tree with those in the schema tree. The XPath expression in the "path" statement is evaluated in the context of a data tree, but if the result is an empty node set, then "this leaf node" makes no sense.
> > 
> > A specific example:
> > 
> > leaf fooref {
> >   type leafref {
> >     path "../foo";
> >     require-instance false;
> >   }
> > }
> > 
> > leaf foo {
> >   type uint8;
> >   when "../bar < 42";
> > }
> > 
> > leaf bar {   
> >   type uint8;
> >   default 100;
> > }
> > 
> > If there is neither "foo" nor "bar" in the data tree, what is the value space of "fooref"?
> >
> 
> Hm. Is it not both? The path refers to a schema node in order to
> determine the base type (which is the base value set if
> require-instance is false). If require-instance is true, then there is
> an additional constraint that refers to a set of data nodes that
> essentially determine a (possibly empty) subset of the value space.
> 
> If you agree with this, then we essentially have to phrase this
> clearly.

Exactly.  My proposal was:

OLD:

   The leafref type is used to declare a constraint on the value space
   of a leaf, based on a reference to a set of leaf instances in the
   data tree.  The "path" substatement (Section 9.9.2) selects a set of
   leaf instances, and the leafref value space is the set of values of
   these leaf instances.

   If the leaf with the leafref type represents configuration data, and
   the "require-instance" property (Section 9.9.3) is "true", the leaf
   it refers to MUST also represent configuration.  Such a leaf puts a
   constraint on valid data.  All such nodes MUST reference existing
   leaf instances or leafs with default values in use (see Section 7.6.1
   and Section 7.7.2) for the data to be valid.  This constraint is
   enforced according to the rules in Section 8.

NEW:

   The leafref type is used to declare a constraint on the value space
   of a leaf, based on a reference to a set of leaf instances in the
   data tree.  The "path" substatement (Section 9.9.2) is used to refer
   to another leaf node.  The leafref value space is the value space of
   this leaf node.

   If the "require-instance" property is "true", there MUST exist an
   instance, or a leaf with a default value in use (see Section 7.6.1
   and Section 7.7.2), of the leaf being referred to with the same value
   as the leafref value in a valid data tree.

   If the leaf with the leafref type represents configuration data, and
   the "require-instance" property (Section 9.9.3) is "true", the leaf
   it refers to MUST also represent configuration.


Please comment and/or suggest improvements to this proposal.



/martin


From nobody Tue May 24 02:56:02 2016
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 7F25612D09E for ; Tue, 24 May 2016 02:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 P-8RZv5PRLsi for ; Tue, 24 May 2016 02:55:59 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EAC12D15F for ; Tue, 24 May 2016 02:55:58 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:19a:9961:8dbe:3869] (unknown [IPv6:2001:718:1a02:1:19a:9961:8dbe:3869]) by mail.nic.cz (Postfix) with ESMTPSA id 4B904600BE; Tue, 24 May 2016 11:55:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464083756; bh=JJ0KQTTD1eB2OQEOGtLnFI18JlVUoskKMJLNWle8N90=; h=From:Date:To; b=FvtEhwWjHh/buMQBRkbIrneaIur38jxCuA95GVhGhacGRV+fLpLh7RLe59VJ/7BZ+ ROXguySC2nZZGMXfkCzXdof3P/sBGQrqffbDO9yN15U64GKUKgBtt3H6UBZ7vEFhsO v0zKlw7HMtVesaYKdvPtdZxNJDXxedg6ysEfw8pE=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160524.103329.1771107175898375865.mbj@tail-f.com>
Date: Tue, 24 May 2016 11:56:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D444A29-9067-4945-90E9-8491E3B2B5D5@nic.cz>
References: <20160523.161038.800274078120441332.mbj@tail-f.com>  <20160524081508.GA9434@elstar.local> <20160524.103329.1771107175898375865.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 09:56:00 -0000

> On 24 May 2016, at 10:33, Martin Bjorklund  wrote:
>=20
> Juergen Schoenwaelder  wrote:
>> On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
>>=20
>> [...]
>>=20
>>> This mixes up paths in the data tree with those in the schema tree. =
The XPath expression in the "path" statement is evaluated in the context =
of a data tree, but if the result is an empty node set, then "this leaf =
node" makes no sense.
>>>=20
>>> A specific example:
>>>=20
>>> leaf fooref {
>>>  type leafref {
>>>    path "../foo";
>>>    require-instance false;
>>>  }
>>> }
>>>=20
>>> leaf foo {
>>>  type uint8;
>>>  when "../bar < 42";
>>> }
>>>=20
>>> leaf bar {  =20
>>>  type uint8;
>>>  default 100;
>>> }
>>>=20
>>> If there is neither "foo" nor "bar" in the data tree, what is the =
value space of "fooref"?
>>>=20
>>=20
>> Hm. Is it not both? The path refers to a schema node in order to

The path argument is XPath (in particular, it can contain key value =
predicates that can be interpreted only in an instance data tree), so it =
doesn't refer to a schema node.

>> determine the base type (which is the base value set if
>> require-instance is false). If require-instance is true, then there =
is
>> an additional constraint that refers to a set of data nodes that
>> essentially determine a (possibly empty) subset of the value space.
>>=20
>> If you agree with this, then we essentially have to phrase this
>> clearly.
>=20
> Exactly.  My proposal was:
>=20
> OLD:
>=20
>   The leafref type is used to declare a constraint on the value space
>   of a leaf, based on a reference to a set of leaf instances in the
>   data tree.  The "path" substatement (Section 9.9.2) selects a set of
>   leaf instances, and the leafref value space is the set of values of
>   these leaf instances.
>=20
>   If the leaf with the leafref type represents configuration data, and
>   the "require-instance" property (Section 9.9.3) is "true", the leaf
>   it refers to MUST also represent configuration.  Such a leaf puts a
>   constraint on valid data.  All such nodes MUST reference existing
>   leaf instances or leafs with default values in use (see Section =
7.6.1
>   and Section 7.7.2) for the data to be valid.  This constraint is
>   enforced according to the rules in Section 8.
>=20
> NEW:
>=20
>   The leafref type is used to declare a constraint on the value space
>   of a leaf, based on a reference to a set of leaf instances in the
>   data tree.  The "path" substatement (Section 9.9.2) is used to refer
>   to another leaf node.  The leafref value space is the value space of
>   this leaf node.

The "path" expression is evaluated in some context that's defined in the =
text. The result is a node set in the *instance* data tree, and in my =
example this node set is empty.

Yes, I understand that *usually* there is some leaf node in the schema =
that defines the type of the leafs selected by the XPath expression (if =
they existed), but I think it is problematic to simply say that an XPath =
expression refers to a schema node.

Consider the example in Appendix A of RFC 7223. If I have a leafref path =
like

"/if:interfaces/if:interface[name=3D'at-0/0/0']/eth:duplex"

then if 'at-0/0/0' isn't an Ethernet interface, it doesn't refer to any =
leaf node because "eth:duplex" is not valid for that particular path =
expression.

Lada

>=20
>   If the "require-instance" property is "true", there MUST exist an
>   instance, or a leaf with a default value in use (see Section 7.6.1
>   and Section 7.7.2), of the leaf being referred to with the same =
value
>   as the leafref value in a valid data tree.
>=20
>   If the leaf with the leafref type represents configuration data, and
>   the "require-instance" property (Section 9.9.3) is "true", the leaf
>   it refers to MUST also represent configuration.
>=20
>=20
> Please comment and/or suggest improvements to this proposal.
>=20
>=20
>=20
> /martin

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





From nobody Tue May 24 02:56:21 2016
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 DBB1B12D15F for ; Tue, 24 May 2016 02:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 b46gRNCwpAAg for ; Tue, 24 May 2016 02:56:17 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779B312D09E for ; Tue, 24 May 2016 02:56:17 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0188EFE9; Tue, 24 May 2016 11:56:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id LIqarCAjcxLP; Tue, 24 May 2016 11:56:08 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 May 2016 11:56:14 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF0022005E; Tue, 24 May 2016 11:56:14 +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 5E-8ur2fg3wR; Tue, 24 May 2016 11:56:11 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 908532005C; Tue, 24 May 2016 11:56:12 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0A95E3AF012F; Tue, 24 May 2016 11:56:10 +0200 (CEST)
Date: Tue, 24 May 2016 11:56:09 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20160524095609.GA9643@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org
References: <20160523.161038.800274078120441332.mbj@tail-f.com>  <20160524081508.GA9434@elstar.local> <20160524.103329.1771107175898375865.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160524.103329.1771107175898375865.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 09:56:20 -0000

On Tue, May 24, 2016 at 10:33:29AM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
> > 
> > [...]
> >  
> > > This mixes up paths in the data tree with those in the schema tree. The XPath expression in the "path" statement is evaluated in the context of a data tree, but if the result is an empty node set, then "this leaf node" makes no sense.
> > > 
> > > A specific example:
> > > 
> > > leaf fooref {
> > >   type leafref {
> > >     path "../foo";
> > >     require-instance false;
> > >   }
> > > }
> > > 
> > > leaf foo {
> > >   type uint8;
> > >   when "../bar < 42";
> > > }
> > > 
> > > leaf bar {   
> > >   type uint8;
> > >   default 100;
> > > }
> > > 
> > > If there is neither "foo" nor "bar" in the data tree, what is the value space of "fooref"?
> > >
> > 
> > Hm. Is it not both? The path refers to a schema node in order to
> > determine the base type (which is the base value set if
> > require-instance is false). If require-instance is true, then there is
> > an additional constraint that refers to a set of data nodes that
> > essentially determine a (possibly empty) subset of the value space.
> > 
> > If you agree with this, then we essentially have to phrase this
> > clearly.
> 
> Exactly.  My proposal was:
> 
> OLD:
> 
>    The leafref type is used to declare a constraint on the value space
>    of a leaf, based on a reference to a set of leaf instances in the
>    data tree.  The "path" substatement (Section 9.9.2) selects a set of
>    leaf instances, and the leafref value space is the set of values of
>    these leaf instances.
> 
>    If the leaf with the leafref type represents configuration data, and
>    the "require-instance" property (Section 9.9.3) is "true", the leaf
>    it refers to MUST also represent configuration.  Such a leaf puts a
>    constraint on valid data.  All such nodes MUST reference existing
>    leaf instances or leafs with default values in use (see Section 7.6.1
>    and Section 7.7.2) for the data to be valid.  This constraint is
>    enforced according to the rules in Section 8.
> 
> NEW:
> 
>    The leafref type is used to declare a constraint on the value space
>    of a leaf, based on a reference to a set of leaf instances in the
>    data tree.  The "path" substatement (Section 9.9.2) is used to refer
>    to another leaf node.  The leafref value space is the value space of
>    this leaf node.
> 
>    If the "require-instance" property is "true", there MUST exist an
>    instance, or a leaf with a default value in use (see Section 7.6.1
>    and Section 7.7.2), of the leaf being referred to with the same value
>    as the leafref value in a valid data tree.
> 
>    If the leaf with the leafref type represents configuration data, and
>    the "require-instance" property (Section 9.9.3) is "true", the leaf
>    it refers to MUST also represent configuration.
> 
> 
> Please comment and/or suggest improvements to this proposal.
>

I will give it a try. I think it is helpful to define referring node
and referred node and I think it is useful to first state the purpose
of the leafref type.

  The leafref type is restricted to the value set of some leaf node in
  the schema tree and optionally further restricted by corresponding
  instance nodes in the data tree. More precisely, the leafref type
  declares a constraint on the value space of a leaf node (the
  referring leaf node), based on a reference to a another leaf node in
  the schema tree (the referred leaf node). The "path" substatement
  (Section 9.9.2) is used to identify the referred leaf node in the
  schema tree. The value set of the referring leaf node is the value
  set of the referred leaf node if the "require-instance" property is
  "false".

  If the "require-instance" property is "true", there MUST exist an node
  in the data tree, or a node with a default value in use (see Section
  7.6.1 and Section 7.7.2), of the referred schema tree leaf node with
  the same value as the leafref value in a valid data tree.

  If the referring leaf node represents configuration data, and the
  "require-instance" property (Section 9.9.3) is "true", the referred
  leaf node MUST also represent configuration.

/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 May 24 03:04:40 2016
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 E466F12D669 for ; Tue, 24 May 2016 03:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 XjPALt9Y-rq2 for ; Tue, 24 May 2016 03:04:35 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5118312D65F for ; Tue, 24 May 2016 03:04:35 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 68A931AE018A; Tue, 24 May 2016 12:04:33 +0200 (CEST)
Date: Tue, 24 May 2016 12:04:54 +0200 (CEST)
Message-Id: <20160524.120454.1136783148031657015.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <0D444A29-9067-4945-90E9-8491E3B2B5D5@nic.cz>
References: <20160524081508.GA9434@elstar.local> <20160524.103329.1771107175898375865.mbj@tail-f.com> <0D444A29-9067-4945-90E9-8491E3B2B5D5@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 10:04:37 -0000

Ladislav Lhotka  wrote:
> 
> > On 24 May 2016, at 10:33, Martin Bjorklund  wrote:
> > 
> > Juergen Schoenwaelder  wrote:
> >> On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
> >> 
> >> [...]
> >> 
> >>> This mixes up paths in the data tree with those in the schema
> >>> tree. The XPath expression in the "path" statement is evaluated in the
> >>> context of a data tree, but if the result is an empty node set, then
> >>> "this leaf node" makes no sense.
> >>> 
> >>> A specific example:
> >>> 
> >>> leaf fooref {
> >>>  type leafref {
> >>>    path "../foo";
> >>>    require-instance false;
> >>>  }
> >>> }
> >>> 
> >>> leaf foo {
> >>>  type uint8;
> >>>  when "../bar < 42";
> >>> }
> >>> 
> >>> leaf bar {   
> >>>  type uint8;
> >>>  default 100;
> >>> }
> >>> 
> >>> If there is neither "foo" nor "bar" in the data tree, what is the
> >>> value space of "fooref"?
> >>> 
> >> 
> >> Hm. Is it not both? The path refers to a schema node in order to
> 
> The path argument is XPath (in particular, it can contain key value
> predicates that can be interpreted only in an instance data tree), so
> it doesn't refer to a schema node.

Note that is a very restricted XPath expression.  The key values are
only used in predicates, and the predicates don't affect the location
path.

> >> determine the base type (which is the base value set if
> >> require-instance is false). If require-instance is true, then there is
> >> an additional constraint that refers to a set of data nodes that
> >> essentially determine a (possibly empty) subset of the value space.
> >> 
> >> If you agree with this, then we essentially have to phrase this
> >> clearly.
> > 
> > Exactly.  My proposal was:
> > 
> > OLD:
> > 
> >   The leafref type is used to declare a constraint on the value space
> >   of a leaf, based on a reference to a set of leaf instances in the
> >   data tree.  The "path" substatement (Section 9.9.2) selects a set of
> >   leaf instances, and the leafref value space is the set of values of
> >   these leaf instances.
> > 
> >   If the leaf with the leafref type represents configuration data, and
> >   the "require-instance" property (Section 9.9.3) is "true", the leaf
> >   it refers to MUST also represent configuration.  Such a leaf puts a
> >   constraint on valid data.  All such nodes MUST reference existing
> >   leaf instances or leafs with default values in use (see Section 7.6.1
> >   and Section 7.7.2) for the data to be valid.  This constraint is
> >   enforced according to the rules in Section 8.
> > 
> > NEW:
> > 
> >   The leafref type is used to declare a constraint on the value space
> >   of a leaf, based on a reference to a set of leaf instances in the
> >   data tree.  The "path" substatement (Section 9.9.2) is used to refer
> >   to another leaf node.  The leafref value space is the value space of
> >   this leaf node.
> 
> The "path" expression is evaluated in some context that's defined in
> the text. The result is a node set in the *instance* data tree, and in
> my example this node set is empty.
> 
> Yes, I understand that *usually* there is some leaf node in the schema
> that defines the type of the leafs selected by the XPath expression
> (if they existed), but I think it is problematic to simply say that an
> XPath expression refers to a schema node.
> 
> Consider the example in Appendix A of RFC 7223. If I have a leafref
> path like
> 
> "/if:interfaces/if:interface[name='at-0/0/0']/eth:duplex"
> 
> then if 'at-0/0/0' isn't an Ethernet interface, it doesn't refer to
> any leaf node because "eth:duplex" is not valid for that particular
> path expression.

Correct, so the value space would be the value space of eth:duplex.
The additional constraint would always evaluate to false if there is
never an interface 'at-0/0/0'.


/martin



> 
> Lada
> 
> > 
> >   If the "require-instance" property is "true", there MUST exist an
> >   instance, or a leaf with a default value in use (see Section 7.6.1
> >   and Section 7.7.2), of the leaf being referred to with the same value
> >   as the leafref value in a valid data tree.
> > 
> >   If the leaf with the leafref type represents configuration data, and
> >   the "require-instance" property (Section 9.9.3) is "true", the leaf
> >   it refers to MUST also represent configuration.
> > 
> > 
> > Please comment and/or suggest improvements to this proposal.
> > 
> > 
> > 
> > /martin
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 


From nobody Tue May 24 03:13:15 2016
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 B4AE412D9B4 for ; Tue, 24 May 2016 03:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 Wfl-oSkyDNfB for ; Tue, 24 May 2016 03:13:13 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8B912D65D for ; Tue, 24 May 2016 03:13:13 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 90D891AE018A; Tue, 24 May 2016 12:12:43 +0200 (CEST)
Date: Tue, 24 May 2016 12:13:04 +0200 (CEST)
Message-Id: <20160524.121304.799281134866976977.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20160524095609.GA9643@elstar.local>
References: <20160524081508.GA9434@elstar.local> <20160524.103329.1771107175898375865.mbj@tail-f.com> <20160524095609.GA9643@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 10:13:15 -0000

Juergen Schoenwaelder  wrote:
> On Tue, May 24, 2016 at 10:33:29AM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
> > > 
> > > [...]
> > >  
> > > > This mixes up paths in the data tree with those in the schema tree. The XPath expression in the "path" statement is evaluated in the context of a data tree, but if the result is an empty node set, then "this leaf node" makes no sense.
> > > > 
> > > > A specific example:
> > > > 
> > > > leaf fooref {
> > > >   type leafref {
> > > >     path "../foo";
> > > >     require-instance false;
> > > >   }
> > > > }
> > > > 
> > > > leaf foo {
> > > >   type uint8;
> > > >   when "../bar < 42";
> > > > }
> > > > 
> > > > leaf bar {   
> > > >   type uint8;
> > > >   default 100;
> > > > }
> > > > 
> > > > If there is neither "foo" nor "bar" in the data tree, what is the value space of "fooref"?
> > > >
> > > 
> > > Hm. Is it not both? The path refers to a schema node in order to
> > > determine the base type (which is the base value set if
> > > require-instance is false). If require-instance is true, then there is
> > > an additional constraint that refers to a set of data nodes that
> > > essentially determine a (possibly empty) subset of the value space.
> > > 
> > > If you agree with this, then we essentially have to phrase this
> > > clearly.
> > 
> > Exactly.  My proposal was:
> > 
> > OLD:
> > 
> >    The leafref type is used to declare a constraint on the value space
> >    of a leaf, based on a reference to a set of leaf instances in the
> >    data tree.  The "path" substatement (Section 9.9.2) selects a set of
> >    leaf instances, and the leafref value space is the set of values of
> >    these leaf instances.
> > 
> >    If the leaf with the leafref type represents configuration data, and
> >    the "require-instance" property (Section 9.9.3) is "true", the leaf
> >    it refers to MUST also represent configuration.  Such a leaf puts a
> >    constraint on valid data.  All such nodes MUST reference existing
> >    leaf instances or leafs with default values in use (see Section 7.6.1
> >    and Section 7.7.2) for the data to be valid.  This constraint is
> >    enforced according to the rules in Section 8.
> > 
> > NEW:
> > 
> >    The leafref type is used to declare a constraint on the value space
> >    of a leaf, based on a reference to a set of leaf instances in the
> >    data tree.  The "path" substatement (Section 9.9.2) is used to refer
> >    to another leaf node.  The leafref value space is the value space of
> >    this leaf node.
> > 
> >    If the "require-instance" property is "true", there MUST exist an
> >    instance, or a leaf with a default value in use (see Section 7.6.1
> >    and Section 7.7.2), of the leaf being referred to with the same value
> >    as the leafref value in a valid data tree.
> > 
> >    If the leaf with the leafref type represents configuration data, and
> >    the "require-instance" property (Section 9.9.3) is "true", the leaf
> >    it refers to MUST also represent configuration.
> > 
> > 
> > Please comment and/or suggest improvements to this proposal.
> >
> 
> I will give it a try. I think it is helpful to define referring node
> and referred node

Ok.

> and I think it is useful to first state the purpose
> of the leafref type.
> 
>   The leafref type is restricted to the value set of some leaf node in
>   the schema tree and optionally further restricted by corresponding
>   instance nodes in the data tree. More precisely, the leafref type
>   declares a constraint on the value space of a leaf node (the
>   referring leaf node), based on a reference to a another leaf node in
>   the schema tree (the referred leaf node). The "path" substatement
>   (Section 9.9.2) is used to identify the referred leaf node in the
>   schema tree. The value set of the referring leaf node is the value
>   set of the referred leaf node if the "require-instance" property is
>   "false".

Maybe remove the second sentence.  Also s/value set/value space/.
Also the last sentence isn't correct; the value space is always the
value space of the referred node.

>   If the "require-instance" property is "true", there MUST exist an node
>   in the data tree, or a node with a default value in use (see Section
>   7.6.1 and Section 7.7.2), of the referred schema tree leaf node with
>   the same value as the leafref value in a valid data tree.
> 
>   If the referring leaf node represents configuration data, and the
>   "require-instance" property (Section 9.9.3) is "true", the referred
>   leaf node MUST also represent configuration.

Also, the text needs to mention leaf-lists.  This gives:


  The leafref type is restricted to the value space of some leaf or
  leaf-list node in the schema tree and optionally further restricted
  by corresponding instance nodes in the data tree.  The "path"
  substatement (Section 9.9.2) is used to identify the referred leaf
  or leaf-list node in the schema tree. The value space of the
  referring node is the value space of the referred node.

  If the "require-instance" property is "true", there MUST exist an
  node in the data tree, or a node with a default value in use (see
  Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf
  or leaf-list node with the same value as the leafref value in a
  valid data tree.

  If the referring node represents configuration data, and the
  "require-instance" property (Section 9.9.3) is "true", the referred
  node MUST also represent configuration.



/martin


From nobody Tue May 24 03:18:47 2016
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 AB4C112DCC8 for ; Tue, 24 May 2016 03:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 R8shWTe9Xo_C for ; Tue, 24 May 2016 03:18:44 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC4912DCC6 for ; Tue, 24 May 2016 03:18:43 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 72D48ACD; Tue, 24 May 2016 12:18:42 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id T0wzb62UiXz6; Tue, 24 May 2016 12:18:34 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 May 2016 12:18:41 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFFC620062; Tue, 24 May 2016 12:18:40 +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 w_hArNz7jtPu; Tue, 24 May 2016 12:18:39 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7ADF820060; Tue, 24 May 2016 12:18:36 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6E4983AF02A3; Tue, 24 May 2016 12:18:36 +0200 (CEST)
Date: Tue, 24 May 2016 12:18:36 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20160524101836.GC9643@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org
References: <20160524081508.GA9434@elstar.local> <20160524.103329.1771107175898375865.mbj@tail-f.com> <20160524095609.GA9643@elstar.local> <20160524.121304.799281134866976977.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160524.121304.799281134866976977.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 10:18:46 -0000

On Tue, May 24, 2016 at 12:13:04PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Tue, May 24, 2016 at 10:33:29AM +0200, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
> > > > 
> > > > [...]
> > > >  
> > > > > This mixes up paths in the data tree with those in the schema tree. The XPath expression in the "path" statement is evaluated in the context of a data tree, but if the result is an empty node set, then "this leaf node" makes no sense.
> > > > > 
> > > > > A specific example:
> > > > > 
> > > > > leaf fooref {
> > > > >   type leafref {
> > > > >     path "../foo";
> > > > >     require-instance false;
> > > > >   }
> > > > > }
> > > > > 
> > > > > leaf foo {
> > > > >   type uint8;
> > > > >   when "../bar < 42";
> > > > > }
> > > > > 
> > > > > leaf bar {   
> > > > >   type uint8;
> > > > >   default 100;
> > > > > }
> > > > > 
> > > > > If there is neither "foo" nor "bar" in the data tree, what is the value space of "fooref"?
> > > > >
> > > > 
> > > > Hm. Is it not both? The path refers to a schema node in order to
> > > > determine the base type (which is the base value set if
> > > > require-instance is false). If require-instance is true, then there is
> > > > an additional constraint that refers to a set of data nodes that
> > > > essentially determine a (possibly empty) subset of the value space.
> > > > 
> > > > If you agree with this, then we essentially have to phrase this
> > > > clearly.
> > > 
> > > Exactly.  My proposal was:
> > > 
> > > OLD:
> > > 
> > >    The leafref type is used to declare a constraint on the value space
> > >    of a leaf, based on a reference to a set of leaf instances in the
> > >    data tree.  The "path" substatement (Section 9.9.2) selects a set of
> > >    leaf instances, and the leafref value space is the set of values of
> > >    these leaf instances.
> > > 
> > >    If the leaf with the leafref type represents configuration data, and
> > >    the "require-instance" property (Section 9.9.3) is "true", the leaf
> > >    it refers to MUST also represent configuration.  Such a leaf puts a
> > >    constraint on valid data.  All such nodes MUST reference existing
> > >    leaf instances or leafs with default values in use (see Section 7.6.1
> > >    and Section 7.7.2) for the data to be valid.  This constraint is
> > >    enforced according to the rules in Section 8.
> > > 
> > > NEW:
> > > 
> > >    The leafref type is used to declare a constraint on the value space
> > >    of a leaf, based on a reference to a set of leaf instances in the
> > >    data tree.  The "path" substatement (Section 9.9.2) is used to refer
> > >    to another leaf node.  The leafref value space is the value space of
> > >    this leaf node.
> > > 
> > >    If the "require-instance" property is "true", there MUST exist an
> > >    instance, or a leaf with a default value in use (see Section 7.6.1
> > >    and Section 7.7.2), of the leaf being referred to with the same value
> > >    as the leafref value in a valid data tree.
> > > 
> > >    If the leaf with the leafref type represents configuration data, and
> > >    the "require-instance" property (Section 9.9.3) is "true", the leaf
> > >    it refers to MUST also represent configuration.
> > > 
> > > 
> > > Please comment and/or suggest improvements to this proposal.
> > >
> > 
> > I will give it a try. I think it is helpful to define referring node
> > and referred node
> 
> Ok.
> 
> > and I think it is useful to first state the purpose
> > of the leafref type.
> > 
> >   The leafref type is restricted to the value set of some leaf node in
> >   the schema tree and optionally further restricted by corresponding
> >   instance nodes in the data tree. More precisely, the leafref type
> >   declares a constraint on the value space of a leaf node (the
> >   referring leaf node), based on a reference to a another leaf node in
> >   the schema tree (the referred leaf node). The "path" substatement
> >   (Section 9.9.2) is used to identify the referred leaf node in the
> >   schema tree. The value set of the referring leaf node is the value
> >   set of the referred leaf node if the "require-instance" property is
> >   "false".
> 
> Maybe remove the second sentence.  Also s/value set/value space/.
> Also the last sentence isn't correct; the value space is always the
> value space of the referred node.
> 
> >   If the "require-instance" property is "true", there MUST exist an node
> >   in the data tree, or a node with a default value in use (see Section
> >   7.6.1 and Section 7.7.2), of the referred schema tree leaf node with
> >   the same value as the leafref value in a valid data tree.
> > 
> >   If the referring leaf node represents configuration data, and the
> >   "require-instance" property (Section 9.9.3) is "true", the referred
> >   leaf node MUST also represent configuration.
> 
> Also, the text needs to mention leaf-lists.  This gives:
> 
> 
>   The leafref type is restricted to the value space of some leaf or
>   leaf-list node in the schema tree and optionally further restricted
>   by corresponding instance nodes in the data tree.  The "path"
>   substatement (Section 9.9.2) is used to identify the referred leaf
>   or leaf-list node in the schema tree. The value space of the
>   referring node is the value space of the referred node.
> 
>   If the "require-instance" property is "true", there MUST exist an
>   node in the data tree, or a node with a default value in use (see
>   Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf
>   or leaf-list node with the same value as the leafref value in a
>   valid data tree.
> 
>   If the referring node represents configuration data, and the
>   "require-instance" property (Section 9.9.3) is "true", the referred
>   node MUST also represent configuration.
>

Works for me.

/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 May 24 03:24:58 2016
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 46A2512DCCF for ; Tue, 24 May 2016 03:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 pZcIG-3Nojmu for ; Tue, 24 May 2016 03:24:56 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F06F12B014 for ; Tue, 24 May 2016 03:24:56 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id A27C41AE043B; Tue, 24 May 2016 12:24:30 +0200 (CEST)
Date: Tue, 24 May 2016 12:24:51 +0200 (CEST)
Message-Id: <20160524.122451.316337046466834553.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <22C4E267-E883-4909-A824-DB742B9F63A4@nic.cz>
References:  <5742F7FB.4040803@labn.net> <22C4E267-E883-4909-A824-DB742B9F63A4@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] compact versus iterative representation of the overall schema
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 10:24:58 -0000

Ladislav Lhotka  wrote:
> 
> > On 23 May 2016, at 14:30, Lou Berger  wrote:
> > 
> > Hi Lada,
> >    I looks like no one really jumped on this one -- so better late than
> > never ...
> > 
> > When looking at the question below, we should consider the uses cases.
> > I'm particularity interested (as a contributor) in the use case of
> > nested mounts (NIs mounted within LNEs), as well as the case if models
> > that will only permit mounting of specific other models vs generically
> > mounting any model.
> > 
> > On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
> >> Hi,
> >> 
> >> with a schema mount mechanism in place, there are two different
> >> options
> >> for constructing the overall schema (their combinations are possible,
> >> too):
> >> 
> >> 1. Define schema mount as an extension of YANG library so that it
> >> defines YANG modules, revisions, features and deviations as before but
> >> also the way how they are combined into a hierarchical structure of
> >> schemas.
> > 
> > I think this only makes sense if this is scoped in some way.  For
> > example, with LNEs, the parent/host server may not have visibility
> > into
> > the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And even
> > if
> 
> As I understand it, schema-mount is about accessing the LNE models
> from the parent/host management interface. I believe the real question
> is whether we want to allow the schema to dynamically change at run
> time and possibly throw in new modules that the client never heard
> of. #2 can do it while #1 can't. I am not sure though whether the LNE
> model really requires something like this.
> 
> > does, you have to consider the cases of mounted models contained
> > within
> > mounted models.
> 
> This is possible either way, provided that the complete schema is
> known upfront.

I don't think I have seen a concrete proposal for such a compact
format that can handle the case where different instances of a list
with a mount point have different modules mounted, and some of them
have mounted models within the mounted models.

As a concrete example, suppose we have the model
example-network-manager from Appendix B in
draft-ietf-netmod-schema-mount-01:

   +--rw managed-devices
      +--rw device* [name]
         +--rw name         string
         +--rw transport
         +--rw root      yangmnt:mount-point managed-device

Now, let's assume that two devices exist, A and B:

  A  implements:  ietf-interfaces, example-netowrk-manager
  B  implements:  ietf-system

In A, there is a managed-device C which implements ietf-interfaces and
ietf-ip.

What would this look like in the compact form?

BTW, in this case, it is not obvious that the top-level server knows
anything about the data models mounted by C...


/martin




> 
> > 
> >> 
> >> 2. Apart from YANG Library data, the server just specifies the mount
> >> points. A client of an NM protocol is expected to fetch a new instance
> >> of YANG library and/or subordinate mount points as state data from a
> >> well-known location under each mount point.
> > 
> > I think this depends on the use case.  For LNEs, I think this is
> > right.
> > For some of the other possible use cases being discussed only a
> > specific
> > model can be mounted.
> 
> I guess I need some example scenarios demonstrating that #1 cannot be
> used for LNE.


From nobody Tue May 24 03:25:12 2016
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 7E46812DCD6 for ; Tue, 24 May 2016 03:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level: 
X-Spam-Status: No, score=-15.947 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=-1.426, 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 1BnoKcnRo0KP for ; Tue, 24 May 2016 03:25:01 -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 3B12712DCD5 for ; Tue, 24 May 2016 03:25:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2340; q=dns/txt; s=iport; t=1464085501; x=1465295101; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=y4AkfAEebnNha3TtDu7CbG6yMT9Oh2Gd0Nm4TtJsqhs=; b=NH+4ELFPcITPWfomoFbBS1Xa6CkND7/hp6/EybmyrLYBBPgqZhs/PSou AeVIdIm5RR9g+16YdwChUjSEyYN+rL7ShqBE870Tupog9TOn6gXoacbTQ GOyKo5oO4TJw4YoteNyWgW8ywMmbXfbIjHeWHugQK18icEIiB/oladXEW A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAQBtKkRX/xbLJq1chA0rUrl+AQ2Bd?= =?us-ascii?q?hcLhSVKAoFsFAEBAQEBAQFlJ4RDAQEEAQEBNTYbCw4KLicwBgEMBgIBAYgrDsQ?= =?us-ascii?q?rAQEBAQEBAQEBAQEBAQEBAQEBARkFhieBdgiCTooZBZg3jiCJQYVbj0weAQFCg?= =?us-ascii?q?247MolRAQEB?=
X-IronPort-AV: E=Sophos;i="5.26,359,1459814400"; d="scan'208";a="634782426"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2016 10:24:27 +0000
Received: from [10.61.76.145] (ams3-vpn-dhcp3217.cisco.com [10.61.76.145]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4OAORl2014111; Tue, 24 May 2016 10:24:27 GMT
To: Martin Bjorklund , netmod@ietf.org
References: <20160523.160845.386020102124289824.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Tue, 24 May 2016 11:24:27 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160523.160845.386020102124289824.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] if-feature in default value
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 10:25:11 -0000

The proposed new text looks fine to me.

Rob


On 23/05/2016 15:08, Martin Bjorklund wrote:
> Hi,
>
> This comment from the Gen-ART review deserves it's own thread.
>
>
> gen-art> - section 7.6.4
> gen-art>
> gen-art>    The default value MUST NOT be marked with an "if-feature" statement.
> gen-art>
> [...]
> gen-art> But it's not clear what the whole set of situations is that should be
> gen-art> forbidden.  For instance, this should work:
> gen-art>
> gen-art>      typedef xyz {
> gen-art>        type enumeration {
> gen-art> 	 enum blue { if-feature blue; }
> gen-art> 	 ...
> gen-art>        }
> gen-art>      }
> gen-art>
> gen-art>      leaf color {
> gen-art>        if-feature blue;
> gen-art>        type xyz;
> gen-art>        default blue;
> gen-art>      }
> gen-art>
> gen-art> Whereas this won't:
> gen-art>
> gen-art>      typedef xyz {
> gen-art>        type enumeration {
> gen-art> 	 enum blue { if-feature blue; }
> gen-art> 	 ...
> gen-art>        }
> gen-art>      }
> gen-art>
> gen-art>      leaf color {
> gen-art>        // No if-feature here.
> gen-art>        type xyz;
> gen-art>        default blue;
> gen-art>      }
> gen-art>
> gen-art> Is this rule only meant to cover the situation where the leaf's type
> gen-art> is an "in-line" enum and the particular enum value has an if-feature?
>
> mbj> Good point.  Yes, the first example should be valid.  Another valid
> mbj> example would be:
> mbj>
> mbj>     container colors {
> mbj>       if-feature blue;
> mbj>       leaf color {
> mbj>         type xyz;
> mbj>         default blue;
> mbj>       }
> mbj>     }
> mbj>
> mbj> Maybe:
> mbj>
> mbj> OLD:
> mbj>
> mbj>   The definition of the default value MUST NOT be marked with an
> mbj>   "if-feature" statement.
> mbj>
> mbj> NEW:
> mbj>
> mbj>   If the definition of the default value is conditional based on one or
> mbj>   more features (see ^if-feature^), then the leaf node MUST
> mbj>   also be conditional based on at least the same set of features.
> mbj>
> mbj> (modelled after the text in 9.9)
>
> Does anyone have comments on this proposal?
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Tue May 24 03:42:48 2016
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 EC03F12D65F for ; Tue, 24 May 2016 03:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 uVkmetJUTLHy for ; Tue, 24 May 2016 03:42:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF83B12D58A for ; Tue, 24 May 2016 03:42:43 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:19a:9961:8dbe:3869] (unknown [IPv6:2001:718:1a02:1:19a:9961:8dbe:3869]) by mail.nic.cz (Postfix) with ESMTPSA id 1CC55611B7; Tue, 24 May 2016 12:42:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464086561; bh=7nk8doaL+BPKm0q7IRXyrbD/k7+W5PJuvvYWZxI4dKg=; h=From:Date:To; b=MluRCbo3zajsajuuHHDhbwL+rNynrEpRTuEhqiZTAyMQLAr2WOrkWNEUCBzsRArbI xizDdzNCqz/qWuU7LI/OZz3qZ2YKw4YIdP5g9CG67U3WTCukb8XzvxvcgzPbo1fN0r E5jCGTKlayCAMhY0NsyOjVPViAhT+4nmeDBUQabk=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160524.120454.1136783148031657015.mbj@tail-f.com>
Date: Tue, 24 May 2016 12:42:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160524081508.GA9434@elstar.local> <20160524.103329.1771107175898375865.mbj@tail-f.com> <0D444A29-9067-4945-90E9-8491E3B2B5D5@nic.cz> <20160524.120454.1136783148031657015.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 10:42:47 -0000

> On 24 May 2016, at 12:04, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 24 May 2016, at 10:33, Martin Bjorklund  wrote:
>>>=20
>>> Juergen Schoenwaelder  wrote:
>>>> On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
>>>>=20
>>>> [...]
>>>>=20
>>>>> This mixes up paths in the data tree with those in the schema
>>>>> tree. The XPath expression in the "path" statement is evaluated in =
the
>>>>> context of a data tree, but if the result is an empty node set, =
then
>>>>> "this leaf node" makes no sense.
>>>>>=20
>>>>> A specific example:
>>>>>=20
>>>>> leaf fooref {
>>>>> type leafref {
>>>>>   path "../foo";
>>>>>   require-instance false;
>>>>> }
>>>>> }
>>>>>=20
>>>>> leaf foo {
>>>>> type uint8;
>>>>> when "../bar < 42";
>>>>> }
>>>>>=20
>>>>> leaf bar {  =20
>>>>> type uint8;
>>>>> default 100;
>>>>> }
>>>>>=20
>>>>> If there is neither "foo" nor "bar" in the data tree, what is the
>>>>> value space of "fooref"?
>>>>>=20
>>>>=20
>>>> Hm. Is it not both? The path refers to a schema node in order to
>>=20
>> The path argument is XPath (in particular, it can contain key value
>> predicates that can be interpreted only in an instance data tree), so
>> it doesn't refer to a schema node.
>=20
> Note that is a very restricted XPath expression.  The key values are
> only used in predicates, and the predicates don't affect the location
> path.

But the one below is valid, right? You have always insisted that schema =
nodes for which "when" expression evaluates to false are not part of the =
schema, which means that different entries of the same list may have =
different schemas, and predicates then affect the location path - =
"if:interface" is an example.=20

>=20
>>>> determine the base type (which is the base value set if
>>>> require-instance is false). If require-instance is true, then there =
is
>>>> an additional constraint that refers to a set of data nodes that
>>>> essentially determine a (possibly empty) subset of the value space.
>>>>=20
>>>> If you agree with this, then we essentially have to phrase this
>>>> clearly.
>>>=20
>>> Exactly.  My proposal was:
>>>=20
>>> OLD:
>>>=20
>>>  The leafref type is used to declare a constraint on the value space
>>>  of a leaf, based on a reference to a set of leaf instances in the
>>>  data tree.  The "path" substatement (Section 9.9.2) selects a set =
of
>>>  leaf instances, and the leafref value space is the set of values of
>>>  these leaf instances.
>>>=20
>>>  If the leaf with the leafref type represents configuration data, =
and
>>>  the "require-instance" property (Section 9.9.3) is "true", the leaf
>>>  it refers to MUST also represent configuration.  Such a leaf puts a
>>>  constraint on valid data.  All such nodes MUST reference existing
>>>  leaf instances or leafs with default values in use (see Section =
7.6.1
>>>  and Section 7.7.2) for the data to be valid.  This constraint is
>>>  enforced according to the rules in Section 8.
>>>=20
>>> NEW:
>>>=20
>>>  The leafref type is used to declare a constraint on the value space
>>>  of a leaf, based on a reference to a set of leaf instances in the
>>>  data tree.  The "path" substatement (Section 9.9.2) is used to =
refer
>>>  to another leaf node.  The leafref value space is the value space =
of
>>>  this leaf node.
>>=20
>> The "path" expression is evaluated in some context that's defined in
>> the text. The result is a node set in the *instance* data tree, and =
in
>> my example this node set is empty.
>>=20
>> Yes, I understand that *usually* there is some leaf node in the =
schema
>> that defines the type of the leafs selected by the XPath expression
>> (if they existed), but I think it is problematic to simply say that =
an
>> XPath expression refers to a schema node.
>>=20
>> Consider the example in Appendix A of RFC 7223. If I have a leafref
>> path like
>>=20
>> "/if:interfaces/if:interface[name=3D'at-0/0/0']/eth:duplex"
>>=20
>> then if 'at-0/0/0' isn't an Ethernet interface, it doesn't refer to
>> any leaf node because "eth:duplex" is not valid for that particular
>> path expression.
>=20
> Correct, so the value space would be the value space of eth:duplex.
> The additional constraint would always evaluate to false if there is
> never an interface 'at-0/0/0'.

There can be one:

"interface": {
   "name": "at-0/0/0",
   "type": "ianaift:atm",
   ...
}

According to sec. 7.21.5, the leaf node "eth:duplex" is invalid in this =
entry, so it makes no sense to talk about its value space.

Lada

>=20
>=20
> /martin
>=20
>=20
>=20
>>=20
>> Lada
>>=20
>>>=20
>>>  If the "require-instance" property is "true", there MUST exist an
>>>  instance, or a leaf with a default value in use (see Section 7.6.1
>>>  and Section 7.7.2), of the leaf being referred to with the same =
value
>>>  as the leafref value in a valid data tree.
>>>=20
>>>  If the leaf with the leafref type represents configuration data, =
and
>>>  the "require-instance" property (Section 9.9.3) is "true", the leaf
>>>  it refers to MUST also represent configuration.
>>>=20
>>>=20
>>> Please comment and/or suggest improvements to this proposal.
>>>=20
>>>=20
>>>=20
>>> /martin
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Tue May 24 04:21:25 2016
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 C698F12D0D1 for ; Tue, 24 May 2016 04:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 qI0yeYCS72DZ for ; Tue, 24 May 2016 04:21:22 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 38E7812B025 for ; Tue, 24 May 2016 04:21:22 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id ADE871AE018A; Tue, 24 May 2016 13:21:19 +0200 (CEST)
Date: Tue, 24 May 2016 13:21:40 +0200 (CEST)
Message-Id: <20160524.132140.2247304138231637247.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <0D444A29-9067-4945-90E9-8491E3B2B5D5@nic.cz> <20160524.120454.1136783148031657015.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 11:21:24 -0000

Ladislav Lhotka  wrote:
> 
> > On 24 May 2016, at 12:04, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> 
> >>> On 24 May 2016, at 10:33, Martin Bjorklund  wrote:
> >>> 
> >>> Juergen Schoenwaelder  wrote:
> >>>> On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
> >>>> 
> >>>> [...]
> >>>> 
> >>>>> This mixes up paths in the data tree with those in the schema
> >>>>> tree. The XPath expression in the "path" statement is evaluated in the
> >>>>> context of a data tree, but if the result is an empty node set, then
> >>>>> "this leaf node" makes no sense.
> >>>>> 
> >>>>> A specific example:
> >>>>> 
> >>>>> leaf fooref {
> >>>>> type leafref {
> >>>>>   path "../foo";
> >>>>>   require-instance false;
> >>>>> }
> >>>>> }
> >>>>> 
> >>>>> leaf foo {
> >>>>> type uint8;
> >>>>> when "../bar < 42";
> >>>>> }
> >>>>> 
> >>>>> leaf bar {   
> >>>>> type uint8;
> >>>>> default 100;
> >>>>> }
> >>>>> 
> >>>>> If there is neither "foo" nor "bar" in the data tree, what is the
> >>>>> value space of "fooref"?
> >>>>> 
> >>>> 
> >>>> Hm. Is it not both? The path refers to a schema node in order to
> >> 
> >> The path argument is XPath (in particular, it can contain key value
> >> predicates that can be interpreted only in an instance data tree), so
> >> it doesn't refer to a schema node.
> > 
> > Note that is a very restricted XPath expression.  The key values are
> > only used in predicates, and the predicates don't affect the location
> > path.
> 
> But the one below is valid, right?

Yes.

> You have always insisted that
> schema nodes for which "when" expression evaluates to false are not
> part of the schema

I don't think I used that wording...

> which means that different entries of the same
> list may have different schemas, and predicates then affect the
> location path - "if:interface" is an example.
> 
> > 
> >>>> determine the base type (which is the base value set if
> >>>> require-instance is false). If require-instance is true, then there is
> >>>> an additional constraint that refers to a set of data nodes that
> >>>> essentially determine a (possibly empty) subset of the value space.
> >>>> 
> >>>> If you agree with this, then we essentially have to phrase this
> >>>> clearly.
> >>> 
> >>> Exactly.  My proposal was:
> >>> 
> >>> OLD:
> >>> 
> >>>  The leafref type is used to declare a constraint on the value space
> >>>  of a leaf, based on a reference to a set of leaf instances in the
> >>>  data tree.  The "path" substatement (Section 9.9.2) selects a set of
> >>>  leaf instances, and the leafref value space is the set of values of
> >>>  these leaf instances.
> >>> 
> >>>  If the leaf with the leafref type represents configuration data, and
> >>>  the "require-instance" property (Section 9.9.3) is "true", the leaf
> >>>  it refers to MUST also represent configuration.  Such a leaf puts a
> >>>  constraint on valid data.  All such nodes MUST reference existing
> >>>  leaf instances or leafs with default values in use (see Section 7.6.1
> >>>  and Section 7.7.2) for the data to be valid.  This constraint is
> >>>  enforced according to the rules in Section 8.
> >>> 
> >>> NEW:
> >>> 
> >>>  The leafref type is used to declare a constraint on the value space
> >>>  of a leaf, based on a reference to a set of leaf instances in the
> >>>  data tree.  The "path" substatement (Section 9.9.2) is used to refer
> >>>  to another leaf node.  The leafref value space is the value space of
> >>>  this leaf node.
> >> 
> >> The "path" expression is evaluated in some context that's defined in
> >> the text. The result is a node set in the *instance* data tree, and in
> >> my example this node set is empty.
> >> 
> >> Yes, I understand that *usually* there is some leaf node in the schema
> >> that defines the type of the leafs selected by the XPath expression
> >> (if they existed), but I think it is problematic to simply say that an
> >> XPath expression refers to a schema node.
> >> 
> >> Consider the example in Appendix A of RFC 7223. If I have a leafref
> >> path like
> >> 
> >> "/if:interfaces/if:interface[name='at-0/0/0']/eth:duplex"
> >> 
> >> then if 'at-0/0/0' isn't an Ethernet interface, it doesn't refer to
> >> any leaf node because "eth:duplex" is not valid for that particular
> >> path expression.
> > 
> > Correct, so the value space would be the value space of eth:duplex.
> > The additional constraint would always evaluate to false if there is
> > never an interface 'at-0/0/0'.
> 
> There can be one:
> 
> "interface": {
>    "name": "at-0/0/0",
>    "type": "ianaift:atm",
>    ...
> }
> 
> According to sec. 7.21.5, the leaf node "eth:duplex" is invalid in
> this entry, so it makes no sense to talk about its value space.

I don't agree that "when" or "if-feature" removes nodes from the
*schema*.  The text says that they make these nodes invalid (scoped to
the parent).

So, imo, eth:duplex does exist in the schema (but will be invalid in
this case).


/martin


> 
> Lada
> 
> > 
> > 
> > /martin
> > 
> > 
> > 
> >> 
> >> Lada
> >> 
> >>> 
> >>>  If the "require-instance" property is "true", there MUST exist an
> >>>  instance, or a leaf with a default value in use (see Section 7.6.1
> >>>  and Section 7.7.2), of the leaf being referred to with the same value
> >>>  as the leafref value in a valid data tree.
> >>> 
> >>>  If the leaf with the leafref type represents configuration data, and
> >>>  the "require-instance" property (Section 9.9.3) is "true", the leaf
> >>>  it refers to MUST also represent configuration.
> >>> 
> >>> 
> >>> Please comment and/or suggest improvements to this proposal.
> >>> 
> >>> 
> >>> 
> >>> /martin
> >> 
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 


From nobody Tue May 24 05:43:49 2016
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 2AEE712D6B8 for ; Tue, 24 May 2016 05:43:48 -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 6Xex0s0I-VUk for ; Tue, 24 May 2016 05:43:46 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 21D5512D6D0 for ; Tue, 24 May 2016 05:43:44 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 9160C1CC02E4; Tue, 24 May 2016 14:43:43 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund 
In-Reply-To: <20160524.122451.316337046466834553.mbj@tail-f.com>
References:  <5742F7FB.4040803@labn.net> <22C4E267-E883-4909-A824-DB742B9F63A4@nic.cz> <20160524.122451.316337046466834553.mbj@tail-f.com>
User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 24 May 2016 14:43:46 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] compact versus iterative representation of the overall schema
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 12:43:48 -0000

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> 
>> > On 23 May 2016, at 14:30, Lou Berger  wrote:
>> > 
>> > Hi Lada,
>> >    I looks like no one really jumped on this one -- so better late than
>> > never ...
>> > 
>> > When looking at the question below, we should consider the uses cases.
>> > I'm particularity interested (as a contributor) in the use case of
>> > nested mounts (NIs mounted within LNEs), as well as the case if models
>> > that will only permit mounting of specific other models vs generically
>> > mounting any model.
>> > 
>> > On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
>> >> Hi,
>> >> 
>> >> with a schema mount mechanism in place, there are two different
>> >> options
>> >> for constructing the overall schema (their combinations are possible,
>> >> too):
>> >> 
>> >> 1. Define schema mount as an extension of YANG library so that it
>> >> defines YANG modules, revisions, features and deviations as before but
>> >> also the way how they are combined into a hierarchical structure of
>> >> schemas.
>> > 
>> > I think this only makes sense if this is scoped in some way.  For
>> > example, with LNEs, the parent/host server may not have visibility
>> > into
>> > the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And even
>> > if
>> 
>> As I understand it, schema-mount is about accessing the LNE models
>> from the parent/host management interface. I believe the real question
>> is whether we want to allow the schema to dynamically change at run
>> time and possibly throw in new modules that the client never heard
>> of. #2 can do it while #1 can't. I am not sure though whether the LNE
>> model really requires something like this.
>> 
>> > does, you have to consider the cases of mounted models contained
>> > within
>> > mounted models.
>> 
>> This is possible either way, provided that the complete schema is
>> known upfront.
>
> I don't think I have seen a concrete proposal for such a compact

YSDL was such a proposal.

> format that can handle the case where different instances of a list
> with a mount point have different modules mounted, and some of them
> have mounted models within the mounted models.
>
> As a concrete example, suppose we have the model
> example-network-manager from Appendix B in
> draft-ietf-netmod-schema-mount-01:
>
>    +--rw managed-devices
>       +--rw device* [name]
>          +--rw name         string
>          +--rw transport
>          +--rw root      yangmnt:mount-point managed-device
>
> Now, let's assume that two devices exist, A and B:
>
>   A  implements:  ietf-interfaces, example-netowrk-manager
>   B  implements:  ietf-system
>
> In A, there is a managed-device C which implements ietf-interfaces and
> ietf-ip.
>
> What would this look like in the compact form?

The module "example-network-manager" would be modified as follows:

   +--rw managed-devices
      +--rw device* [name]
         +--rw name         string
         +--rw transport
         +--rw (root)
            +--:(A)
            +--:(B)
            +--:(C)

And then:

   {
     "ietf-ysdl:schemas": {
       "top-schema": "host",
       "schema": [
         {
           "name": "host",
           "yang-modules": [ "example-logical-devices" ],
           "subschema": [
             {
               "root":
                 "/example-network-manager:managed-devices/device/root/A",
               "schemas": [ "schema-A" ]
             }
             {
               "root":
                 "/example-network-manager:managed-devices/device/root/B",
               "schemas": [ "schema-B" ]
             }
           ]
         },
         {
           "name": "schema-A",
           "yang-modules": [
             "ietf-interfaces",
             "example-network-manager"
           ],
           "subschema": [
             {
               "root":
                 "/example-network-manager:managed-devices/device/root/C",
               "schemas": [ "schema-C" ]
             }
           ]
         },
         {
           "name": "schema-B",
           "yang-modules": [ "ietf-system" ]
         },
         {
           "name": "schema-C",
           "yang-modules": [
             "ietf-interfaces",
             "ietf-ip"
           ]
         }
       ]
     }
   }
         
As long as all modules comprising the schema and their possible
arrangement is known in advance, it should flexible enough. And as I
said, I'd prefer to address this case in schema-mount because the model
of trust between the server and client isn't changed in any way.

>
> BTW, in this case, it is not obvious that the top-level server knows
> anything about the data models mounted by C...

But then the top-level server cannot possibly serve data for C.

Lada

>
>
> /martin
>
>
>
>
>> 
>> > 
>> >> 
>> >> 2. Apart from YANG Library data, the server just specifies the mount
>> >> points. A client of an NM protocol is expected to fetch a new instance
>> >> of YANG library and/or subordinate mount points as state data from a
>> >> well-known location under each mount point.
>> > 
>> > I think this depends on the use case.  For LNEs, I think this is
>> > right.
>> > For some of the other possible use cases being discussed only a
>> > specific
>> > model can be mounted.
>> 
>> I guess I need some example scenarios demonstrating that #1 cannot be
>> used for LNE.
>

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


From nobody Tue May 24 05:52:15 2016
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 8C03712D6F7 for ; Tue, 24 May 2016 05:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 S2VP47m7PPS9 for ; Tue, 24 May 2016 05:52:13 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1C1E12D6FA for ; Tue, 24 May 2016 05:52:06 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id F13F41AE018A; Tue, 24 May 2016 14:52:04 +0200 (CEST)
Date: Tue, 24 May 2016 14:52:25 +0200 (CEST)
Message-Id: <20160524.145225.1049539486912684674.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <22C4E267-E883-4909-A824-DB742B9F63A4@nic.cz> <20160524.122451.316337046466834553.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] compact versus iterative representation of the overall schema
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 12:52:14 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Ladislav Lhotka  wrote:
> >> 
> >> > On 23 May 2016, at 14:30, Lou Berger  wrote:
> >> > 
> >> > Hi Lada,
> >> >    I looks like no one really jumped on this one -- so better late than
> >> > never ...
> >> > 
> >> > When looking at the question below, we should consider the uses cases.
> >> > I'm particularity interested (as a contributor) in the use case of
> >> > nested mounts (NIs mounted within LNEs), as well as the case if models
> >> > that will only permit mounting of specific other models vs generically
> >> > mounting any model.
> >> > 
> >> > On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
> >> >> Hi,
> >> >> 
> >> >> with a schema mount mechanism in place, there are two different
> >> >> options
> >> >> for constructing the overall schema (their combinations are possible,
> >> >> too):
> >> >> 
> >> >> 1. Define schema mount as an extension of YANG library so that it
> >> >> defines YANG modules, revisions, features and deviations as before but
> >> >> also the way how they are combined into a hierarchical structure of
> >> >> schemas.
> >> > 
> >> > I think this only makes sense if this is scoped in some way.  For
> >> > example, with LNEs, the parent/host server may not have visibility
> >> > into
> >> > the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And even
> >> > if
> >> 
> >> As I understand it, schema-mount is about accessing the LNE models
> >> from the parent/host management interface. I believe the real question
> >> is whether we want to allow the schema to dynamically change at run
> >> time and possibly throw in new modules that the client never heard
> >> of. #2 can do it while #1 can't. I am not sure though whether the LNE
> >> model really requires something like this.
> >> 
> >> > does, you have to consider the cases of mounted models contained
> >> > within
> >> > mounted models.
> >> 
> >> This is possible either way, provided that the complete schema is
> >> known upfront.
> >
> > I don't think I have seen a concrete proposal for such a compact
> 
> YSDL was such a proposal.
> 
> > format that can handle the case where different instances of a list
> > with a mount point have different modules mounted, and some of them
> > have mounted models within the mounted models.
> >
> > As a concrete example, suppose we have the model
> > example-network-manager from Appendix B in
> > draft-ietf-netmod-schema-mount-01:
> >
> >    +--rw managed-devices
> >       +--rw device* [name]
> >          +--rw name         string
> >          +--rw transport
> >          +--rw root      yangmnt:mount-point managed-device
> >
> > Now, let's assume that two devices exist, A and B:
> >
> >   A  implements:  ietf-interfaces, example-netowrk-manager
> >   B  implements:  ietf-system
> >
> > In A, there is a managed-device C which implements ietf-interfaces and
> > ietf-ip.
> >
> > What would this look like in the compact form?
> 
> The module "example-network-manager" would be modified as follows:
> 
>    +--rw managed-devices
>       +--rw device* [name]
>          +--rw name         string
>          +--rw transport
>          +--rw (root)
>             +--:(A)
>             +--:(B)
>             +--:(C)

But A, B and C are device names (instances).

Also, C would be:

  /managed-devices/device[name="A"]/root/managed-devices/device[name="C"]


> And then:
> 
>    {
>      "ietf-ysdl:schemas": {
>        "top-schema": "host",
>        "schema": [
>          {
>            "name": "host",
>            "yang-modules": [ "example-logical-devices" ],
>            "subschema": [
>              {
>                "root":
>                  "/example-network-manager:managed-devices/device/root/A",

Can the root contain instance information?


/martin


>                "schemas": [ "schema-A" ]
>              }
>              {
>                "root":
>                  "/example-network-manager:managed-devices/device/root/B",
>                "schemas": [ "schema-B" ]
>              }
>            ]
>          },
>          {
>            "name": "schema-A",
>            "yang-modules": [
>              "ietf-interfaces",
>              "example-network-manager"
>            ],
>            "subschema": [
>              {
>                "root":
>                  "/example-network-manager:managed-devices/device/root/C",
>                "schemas": [ "schema-C" ]
>              }
>            ]
>          },
>          {
>            "name": "schema-B",
>            "yang-modules": [ "ietf-system" ]
>          },
>          {
>            "name": "schema-C",
>            "yang-modules": [
>              "ietf-interfaces",
>              "ietf-ip"
>            ]
>          }
>        ]
>      }
>    }
>          
> As long as all modules comprising the schema and their possible
> arrangement is known in advance, it should flexible enough. And as I
> said, I'd prefer to address this case in schema-mount because the model
> of trust between the server and client isn't changed in any way.
> 
> >
> > BTW, in this case, it is not obvious that the top-level server knows
> > anything about the data models mounted by C...
> 
> But then the top-level server cannot possibly serve data for C.
> 
> Lada
> 
> >
> >
> > /martin
> >
> >
> >
> >
> >> 
> >> > 
> >> >> 
> >> >> 2. Apart from YANG Library data, the server just specifies the mount
> >> >> points. A client of an NM protocol is expected to fetch a new instance
> >> >> of YANG library and/or subordinate mount points as state data from a
> >> >> well-known location under each mount point.
> >> > 
> >> > I think this depends on the use case.  For LNEs, I think this is
> >> > right.
> >> > For some of the other possible use cases being discussed only a
> >> > specific
> >> > model can be mounted.
> >> 
> >> I guess I need some example scenarios demonstrating that #1 cannot be
> >> used for LNE.
> >
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 


From nobody Tue May 24 06:18:48 2016
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 57F3A12DD31 for ; Tue, 24 May 2016 06:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 v80Vh4mzon-X for ; Tue, 24 May 2016 06:18:43 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E124E12DD48 for ; Tue, 24 May 2016 06:14:18 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 458A161829; Tue, 24 May 2016 15:14:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464095657; bh=PCp0hyN9ycqpiOfxXFHCQXr12nMiBrDaXv0K9Fx1EHA=; h=From:Date:To; b=UXNtHUmjS8lzAm5NPTNjFUBx21Pk69vuLrzKSWmNs7ErSa6Ft8EqE3Scd7ur2Bt+0 EuFpAVPG8iy1BBDvb11BFVMU9JB7Du6TGEBjsL2LIb33A1nAdo4MVgMaRRDbyQKWfl iNTn/oMl1UaptqHP0O+yegmq9SuSc4NDV3T678+s=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160524.145225.1049539486912684674.mbj@tail-f.com>
Date: Tue, 24 May 2016 15:14:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <22C4E267-E883-4909-A824-DB742B9F63A4@nic.cz> <20160524.122451.316337046466834553.mbj@tail-f.com>  <20160524.145225.1049539486912684674.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] compact versus iterative representation of the overall schema
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 13:18:46 -0000

> On 24 May 2016, at 14:52, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>>=20
>>> Ladislav Lhotka  wrote:
>>>>=20
>>>>> On 23 May 2016, at 14:30, Lou Berger  wrote:
>>>>>=20
>>>>> Hi Lada,
>>>>>   I looks like no one really jumped on this one -- so better late =
than
>>>>> never ...
>>>>>=20
>>>>> When looking at the question below, we should consider the uses =
cases.
>>>>> I'm particularity interested (as a contributor) in the use case of
>>>>> nested mounts (NIs mounted within LNEs), as well as the case if =
models
>>>>> that will only permit mounting of specific other models vs =
generically
>>>>> mounting any model.
>>>>>=20
>>>>> On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
>>>>>> Hi,
>>>>>>=20
>>>>>> with a schema mount mechanism in place, there are two different
>>>>>> options
>>>>>> for constructing the overall schema (their combinations are =
possible,
>>>>>> too):
>>>>>>=20
>>>>>> 1. Define schema mount as an extension of YANG library so that it
>>>>>> defines YANG modules, revisions, features and deviations as =
before but
>>>>>> also the way how they are combined into a hierarchical structure =
of
>>>>>> schemas.
>>>>>=20
>>>>> I think this only makes sense if this is scoped in some way.  For
>>>>> example, with LNEs, the parent/host server may not have visibility
>>>>> into
>>>>> the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And =
even
>>>>> if
>>>>=20
>>>> As I understand it, schema-mount is about accessing the LNE models
>>>> from the parent/host management interface. I believe the real =
question
>>>> is whether we want to allow the schema to dynamically change at run
>>>> time and possibly throw in new modules that the client never heard
>>>> of. #2 can do it while #1 can't. I am not sure though whether the =
LNE
>>>> model really requires something like this.
>>>>=20
>>>>> does, you have to consider the cases of mounted models contained
>>>>> within
>>>>> mounted models.
>>>>=20
>>>> This is possible either way, provided that the complete schema is
>>>> known upfront.
>>>=20
>>> I don't think I have seen a concrete proposal for such a compact
>>=20
>> YSDL was such a proposal.
>>=20
>>> format that can handle the case where different instances of a list
>>> with a mount point have different modules mounted, and some of them
>>> have mounted models within the mounted models.
>>>=20
>>> As a concrete example, suppose we have the model
>>> example-network-manager from Appendix B in
>>> draft-ietf-netmod-schema-mount-01:
>>>=20
>>>   +--rw managed-devices
>>>      +--rw device* [name]
>>>         +--rw name         string
>>>         +--rw transport
>>>         +--rw root      yangmnt:mount-point managed-device
>>>=20
>>> Now, let's assume that two devices exist, A and B:
>>>=20
>>>  A  implements:  ietf-interfaces, example-netowrk-manager
>>>  B  implements:  ietf-system
>>>=20
>>> In A, there is a managed-device C which implements ietf-interfaces =
and
>>> ietf-ip.
>>>=20
>>> What would this look like in the compact form?
>>=20
>> The module "example-network-manager" would be modified as follows:
>>=20
>>   +--rw managed-devices
>>      +--rw device* [name]
>>         +--rw name         string
>>         +--rw transport
>>         +--rw (root)
>>            +--:(A)
>>            +--:(B)
>>            +--:(C)
>=20
> But A, B and C are device names (instances).

So what? A, B and C can be the values of the "name" key, too.

>=20
> Also, C would be:
>=20
>  =
/managed-devices/device[name=3D"A"]/root/managed-devices/device[name=3D"C"=
]

Yes.

>=20
>=20
>> And then:
>>=20
>>   {
>>     "ietf-ysdl:schemas": {
>>       "top-schema": "host",
>>       "schema": [
>>         {
>>           "name": "host",
>>           "yang-modules": [ "example-logical-devices" ],
>>           "subschema": [
>>             {
>>               "root":
>>                 =
"/example-network-manager:managed-devices/device/root/A",
>=20
> Can the root contain instance information?

No, it is a schema-node-path, that's why it can contain "choice" and =
"case" nodes. It should be possible to construct the complete schema =
without looking into any instances.

Lada

>=20
>=20
> /martin
>=20
>=20
>>               "schemas": [ "schema-A" ]
>>             }
>>             {
>>               "root":
>>                 =
"/example-network-manager:managed-devices/device/root/B",
>>               "schemas": [ "schema-B" ]
>>             }
>>           ]
>>         },
>>         {
>>           "name": "schema-A",
>>           "yang-modules": [
>>             "ietf-interfaces",
>>             "example-network-manager"
>>           ],
>>           "subschema": [
>>             {
>>               "root":
>>                 =
"/example-network-manager:managed-devices/device/root/C",
>>               "schemas": [ "schema-C" ]
>>             }
>>           ]
>>         },
>>         {
>>           "name": "schema-B",
>>           "yang-modules": [ "ietf-system" ]
>>         },
>>         {
>>           "name": "schema-C",
>>           "yang-modules": [
>>             "ietf-interfaces",
>>             "ietf-ip"
>>           ]
>>         }
>>       ]
>>     }
>>   }
>>=20
>> As long as all modules comprising the schema and their possible
>> arrangement is known in advance, it should flexible enough. And as I
>> said, I'd prefer to address this case in schema-mount because the =
model
>> of trust between the server and client isn't changed in any way.
>>=20
>>>=20
>>> BTW, in this case, it is not obvious that the top-level server knows
>>> anything about the data models mounted by C...
>>=20
>> But then the top-level server cannot possibly serve data for C.
>>=20
>> Lada
>>=20
>>>=20
>>>=20
>>> /martin
>>>=20
>>>=20
>>>=20
>>>=20
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> 2. Apart from YANG Library data, the server just specifies the =
mount
>>>>>> points. A client of an NM protocol is expected to fetch a new =
instance
>>>>>> of YANG library and/or subordinate mount points as state data =
from a
>>>>>> well-known location under each mount point.
>>>>>=20
>>>>> I think this depends on the use case.  For LNEs, I think this is
>>>>> right.
>>>>> For some of the other possible use cases being discussed only a
>>>>> specific
>>>>> model can be mounted.
>>>>=20
>>>> I guess I need some example scenarios demonstrating that #1 cannot =
be
>>>> used for LNE.
>>>=20
>>=20
>> --=20
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20

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





From nobody Tue May 24 06:25:39 2016
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 D5FB712D800 for ; Tue, 24 May 2016 06:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 OXoZk9O8IVwP for ; Tue, 24 May 2016 06:25:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C41512D760 for ; Tue, 24 May 2016 06:20:19 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 6CC181AE018A; Tue, 24 May 2016 15:20:18 +0200 (CEST)
Date: Tue, 24 May 2016 15:20:39 +0200 (CEST)
Message-Id: <20160524.152039.845759926197525067.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20160524.145225.1049539486912684674.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] compact versus iterative representation of the overall schema
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 13:25:37 -0000

Ladislav Lhotka  wrote:
> 
> > On 24 May 2016, at 14:52, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> Martin Bjorklund  writes:
> >> 
> >>> Ladislav Lhotka  wrote:
> >>>> 
> >>>>> On 23 May 2016, at 14:30, Lou Berger  wrote:
> >>>>> 
> >>>>> Hi Lada,
> >>>>>   I looks like no one really jumped on this one -- so better late than
> >>>>> never ...
> >>>>> 
> >>>>> When looking at the question below, we should consider the uses cases.
> >>>>> I'm particularity interested (as a contributor) in the use case of
> >>>>> nested mounts (NIs mounted within LNEs), as well as the case if models
> >>>>> that will only permit mounting of specific other models vs generically
> >>>>> mounting any model.
> >>>>> 
> >>>>> On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
> >>>>>> Hi,
> >>>>>> 
> >>>>>> with a schema mount mechanism in place, there are two different
> >>>>>> options
> >>>>>> for constructing the overall schema (their combinations are possible,
> >>>>>> too):
> >>>>>> 
> >>>>>> 1. Define schema mount as an extension of YANG library so that it
> >>>>>> defines YANG modules, revisions, features and deviations as before but
> >>>>>> also the way how they are combined into a hierarchical structure of
> >>>>>> schemas.
> >>>>> 
> >>>>> I think this only makes sense if this is scoped in some way.  For
> >>>>> example, with LNEs, the parent/host server may not have visibility
> >>>>> into
> >>>>> the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And even
> >>>>> if
> >>>> 
> >>>> As I understand it, schema-mount is about accessing the LNE models
> >>>> from the parent/host management interface. I believe the real question
> >>>> is whether we want to allow the schema to dynamically change at run
> >>>> time and possibly throw in new modules that the client never heard
> >>>> of. #2 can do it while #1 can't. I am not sure though whether the LNE
> >>>> model really requires something like this.
> >>>> 
> >>>>> does, you have to consider the cases of mounted models contained
> >>>>> within
> >>>>> mounted models.
> >>>> 
> >>>> This is possible either way, provided that the complete schema is
> >>>> known upfront.
> >>> 
> >>> I don't think I have seen a concrete proposal for such a compact
> >> 
> >> YSDL was such a proposal.
> >> 
> >>> format that can handle the case where different instances of a list
> >>> with a mount point have different modules mounted, and some of them
> >>> have mounted models within the mounted models.
> >>> 
> >>> As a concrete example, suppose we have the model
> >>> example-network-manager from Appendix B in
> >>> draft-ietf-netmod-schema-mount-01:
> >>> 
> >>>   +--rw managed-devices
> >>>      +--rw device* [name]
> >>>         +--rw name         string
> >>>         +--rw transport
> >>>         +--rw root      yangmnt:mount-point managed-device
> >>> 
> >>> Now, let's assume that two devices exist, A and B:
> >>> 
> >>>  A  implements:  ietf-interfaces, example-netowrk-manager
> >>>  B  implements:  ietf-system
> >>> 
> >>> In A, there is a managed-device C which implements ietf-interfaces and
> >>> ietf-ip.
> >>> 
> >>> What would this look like in the compact form?
> >> 
> >> The module "example-network-manager" would be modified as follows:
> >> 
> >>   +--rw managed-devices
> >>      +--rw device* [name]
> >>         +--rw name         string
> >>         +--rw transport
> >>         +--rw (root)
> >>            +--:(A)
> >>            +--:(B)
> >>            +--:(C)
> > 
> > But A, B and C are device names (instances).
> 
> So what? A, B and C can be the values of the "name" key, too.
> 
> > 
> > Also, C would be:
> > 
> >  /managed-devices/device[name="A"]/root/managed-devices/device[name="C"]
> 
> Yes.
> 
> > 
> > 
> >> And then:
> >> 
> >>   {
> >>     "ietf-ysdl:schemas": {
> >>       "top-schema": "host",
> >>       "schema": [
> >>         {
> >>           "name": "host",
> >>           "yang-modules": [ "example-logical-devices" ],
> >>           "subschema": [
> >>             {
> >>               "root":
> >>                 "/example-network-manager:managed-devices/device/root/A",
> > 
> > Can the root contain instance information?
> 
> No, it is a schema-node-path, that's why it can contain "choice" and
> "case" nodes. It should be possible to construct the complete schema
> without looking into any instances.

So this approach doesn't work when the instances have different
mounted models?

It is not realistic to change the data model as you did above, since
we'd have to invent a separate container per combination of modules
that possibly could be mounted!


/martin


> 
> Lada
> 
> > 
> > 
> > /martin
> > 
> > 
> >>               "schemas": [ "schema-A" ]
> >>             }
> >>             {
> >>               "root":
> >>                 "/example-network-manager:managed-devices/device/root/B",
> >>               "schemas": [ "schema-B" ]
> >>             }
> >>           ]
> >>         },
> >>         {
> >>           "name": "schema-A",
> >>           "yang-modules": [
> >>             "ietf-interfaces",
> >>             "example-network-manager"
> >>           ],
> >>           "subschema": [
> >>             {
> >>               "root":
> >>                 "/example-network-manager:managed-devices/device/root/C",
> >>               "schemas": [ "schema-C" ]
> >>             }
> >>           ]
> >>         },
> >>         {
> >>           "name": "schema-B",
> >>           "yang-modules": [ "ietf-system" ]
> >>         },
> >>         {
> >>           "name": "schema-C",
> >>           "yang-modules": [
> >>             "ietf-interfaces",
> >>             "ietf-ip"
> >>           ]
> >>         }
> >>       ]
> >>     }
> >>   }
> >> 
> >> As long as all modules comprising the schema and their possible
> >> arrangement is known in advance, it should flexible enough. And as I
> >> said, I'd prefer to address this case in schema-mount because the model
> >> of trust between the server and client isn't changed in any way.
> >> 
> >>> 
> >>> BTW, in this case, it is not obvious that the top-level server knows
> >>> anything about the data models mounted by C...
> >> 
> >> But then the top-level server cannot possibly serve data for C.
> >> 
> >> Lada
> >> 
> >>> 
> >>> 
> >>> /martin
> >>> 
> >>> 
> >>> 
> >>> 
> >>>> 
> >>>>> 
> >>>>>> 
> >>>>>> 2. Apart from YANG Library data, the server just specifies the mount
> >>>>>> points. A client of an NM protocol is expected to fetch a new instance
> >>>>>> of YANG library and/or subordinate mount points as state data from a
> >>>>>> well-known location under each mount point.
> >>>>> 
> >>>>> I think this depends on the use case.  For LNEs, I think this is
> >>>>> right.
> >>>>> For some of the other possible use cases being discussed only a
> >>>>> specific
> >>>>> model can be mounted.
> >>>> 
> >>>> I guess I need some example scenarios demonstrating that #1 cannot be
> >>>> used for LNE.
> >>> 
> >> 
> >> -- 
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >> 
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 


From nobody Tue May 24 06:31:43 2016
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 AE07612D77E for ; Tue, 24 May 2016 06:31:42 -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 VSPNufdjmZWu for ; Tue, 24 May 2016 06:31:41 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2A98D12D7DA for ; Tue, 24 May 2016 06:26:38 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id A292E1CC02E4; Tue, 24 May 2016 15:26:38 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund , worley@ariadne.com
In-Reply-To: <20160523.154309.848500367505009627.mbj@tail-f.com>
References: <877feyrdz9.fsf@hobgoblin.ariadne.com> <20160523.154309.848500367505009627.mbj@tail-f.com>
User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 24 May 2016 15:26:40 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 13:31:43 -0000

Martin Bjorklund  writes:

>> 
>>    if-feature-expr     = "(" if-feature-expr ")" /
>>                          if-feature-expr sep boolean-operator sep
>>                            if-feature-expr /
>>                          not-keyword sep if-feature-expr /
>>                          identifier-ref-arg
>> 
>> This should probably be marked ";; precedence rules specified in
>> Section 7.20.2", as the grammar is ambiguous and does not specify the
>> precedence, whereas typical programming language grammars encode the
>> precedence rules.
>
> Or we change it to:
>
> if-feature-expr     = if-feature-term [sep or-keyword sep if-feature-expr]
>
> if-feature-term     = if-feature-factor [sep and-keyword sep if-feature-term]
>
> if-feature-factor   = not-keyword sep if-feature-factor /
>                       "(" sep if-feature-expr sep ")" /
>                       identifier-ref-arg
>

I support extending the grammar as Martin suggests. In fact, I proposed
this change to the ABNF already in my review from 2014-11-26:

https://www.ietf.org/mail-archive/web/netmod/current/msg11411.html

(except that the boolean operators are left-associative in my version
and right-associative in Martin's, but that is irrelevant).

Lada

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


From nobody Tue May 24 06:57:53 2016
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 BBBEF12D7E3 for ; Tue, 24 May 2016 06:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 gOmY1aWHotZH for ; Tue, 24 May 2016 06:57:41 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6430312D7DD for ; Tue, 24 May 2016 06:57:41 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:19a:9961:8dbe:3869] (unknown [IPv6:2001:718:1a02:1:19a:9961:8dbe:3869]) by mail.nic.cz (Postfix) with ESMTPSA id 03F78600CC; Tue, 24 May 2016 15:57:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464098260; bh=7IY0vydDGDqpUPfW50cBSf0lycPhsJQm9twbNKtNITQ=; h=From:Date:To; b=guvvK0MV0J3r7q3PvVs0fISOyaZYigC+fpJ+8xobRcjhPTcmlEu5tNLh9/ri/QyCt CBkj0Bf+5ToS96fBgwCwzgI89eBVjk8eQluGTU33VHHA1wPyn/Ph9BhqD7hK/AfE/8 Gk/rg8LHD+r0lcM+h+jln53xbcjN+zKw4nPY0JUQ=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160524.152039.845759926197525067.mbj@tail-f.com>
Date: Tue, 24 May 2016 15:57:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20160524.145225.1049539486912684674.mbj@tail-f.com>  <20160524.152039.845759926197525067.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] compact versus iterative representation of the overall schema
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 13:57:48 -0000

> On 24 May 2016, at 15:20, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 24 May 2016, at 14:52, Martin Bjorklund  wrote:
>>>=20
>>> Ladislav Lhotka  wrote:
>>>> Martin Bjorklund  writes:
>>>>=20
>>>>> Ladislav Lhotka  wrote:
>>>>>>=20
>>>>>>> On 23 May 2016, at 14:30, Lou Berger  wrote:
>>>>>>>=20
>>>>>>> Hi Lada,
>>>>>>>  I looks like no one really jumped on this one -- so better late =
than
>>>>>>> never ...
>>>>>>>=20
>>>>>>> When looking at the question below, we should consider the uses =
cases.
>>>>>>> I'm particularity interested (as a contributor) in the use case =
of
>>>>>>> nested mounts (NIs mounted within LNEs), as well as the case if =
models
>>>>>>> that will only permit mounting of specific other models vs =
generically
>>>>>>> mounting any model.
>>>>>>>=20
>>>>>>> On 4/6/2016 10:07 AM, Ladislav Lhotka wrote:
>>>>>>>> Hi,
>>>>>>>>=20
>>>>>>>> with a schema mount mechanism in place, there are two different
>>>>>>>> options
>>>>>>>> for constructing the overall schema (their combinations are =
possible,
>>>>>>>> too):
>>>>>>>>=20
>>>>>>>> 1. Define schema mount as an extension of YANG library so that =
it
>>>>>>>> defines YANG modules, revisions, features and deviations as =
before but
>>>>>>>> also the way how they are combined into a hierarchical =
structure of
>>>>>>>> schemas.
>>>>>>>=20
>>>>>>> I think this only makes sense if this is scoped in some way.  =
For
>>>>>>> example, with LNEs, the parent/host server may not have =
visibility
>>>>>>> into
>>>>>>> the mounted models, (see draft-rtgyangdt-rtgwg-lne-model).  And =
even
>>>>>>> if
>>>>>>=20
>>>>>> As I understand it, schema-mount is about accessing the LNE =
models
>>>>>> from the parent/host management interface. I believe the real =
question
>>>>>> is whether we want to allow the schema to dynamically change at =
run
>>>>>> time and possibly throw in new modules that the client never =
heard
>>>>>> of. #2 can do it while #1 can't. I am not sure though whether the =
LNE
>>>>>> model really requires something like this.
>>>>>>=20
>>>>>>> does, you have to consider the cases of mounted models contained
>>>>>>> within
>>>>>>> mounted models.
>>>>>>=20
>>>>>> This is possible either way, provided that the complete schema is
>>>>>> known upfront.
>>>>>=20
>>>>> I don't think I have seen a concrete proposal for such a compact
>>>>=20
>>>> YSDL was such a proposal.
>>>>=20
>>>>> format that can handle the case where different instances of a =
list
>>>>> with a mount point have different modules mounted, and some of =
them
>>>>> have mounted models within the mounted models.
>>>>>=20
>>>>> As a concrete example, suppose we have the model
>>>>> example-network-manager from Appendix B in
>>>>> draft-ietf-netmod-schema-mount-01:
>>>>>=20
>>>>>  +--rw managed-devices
>>>>>     +--rw device* [name]
>>>>>        +--rw name         string
>>>>>        +--rw transport
>>>>>        +--rw root      yangmnt:mount-point managed-device
>>>>>=20
>>>>> Now, let's assume that two devices exist, A and B:
>>>>>=20
>>>>> A  implements:  ietf-interfaces, example-netowrk-manager
>>>>> B  implements:  ietf-system
>>>>>=20
>>>>> In A, there is a managed-device C which implements ietf-interfaces =
and
>>>>> ietf-ip.
>>>>>=20
>>>>> What would this look like in the compact form?
>>>>=20
>>>> The module "example-network-manager" would be modified as follows:
>>>>=20
>>>>  +--rw managed-devices
>>>>     +--rw device* [name]
>>>>        +--rw name         string
>>>>        +--rw transport
>>>>        +--rw (root)
>>>>           +--:(A)
>>>>           +--:(B)
>>>>           +--:(C)
>>>=20
>>> But A, B and C are device names (instances).
>>=20
>> So what? A, B and C can be the values of the "name" key, too.
>>=20
>>>=20
>>> Also, C would be:
>>>=20
>>> =
/managed-devices/device[name=3D"A"]/root/managed-devices/device[name=3D"C"=
]
>>=20
>> Yes.
>>=20
>>>=20
>>>=20
>>>> And then:
>>>>=20
>>>>  {
>>>>    "ietf-ysdl:schemas": {
>>>>      "top-schema": "host",
>>>>      "schema": [
>>>>        {
>>>>          "name": "host",
>>>>          "yang-modules": [ "example-logical-devices" ],
>>>>          "subschema": [
>>>>            {
>>>>              "root":
>>>>                =
"/example-network-manager:managed-devices/device/root/A",
>>>=20
>>> Can the root contain instance information?
>>=20
>> No, it is a schema-node-path, that's why it can contain "choice" and
>> "case" nodes. It should be possible to construct the complete schema
>> without looking into any instances.
>=20
> So this approach doesn't work when the instances have different
> mounted models?

It works in the same way as for interfaces in ietf-interfaces, or =
routing-protocols in ietf-routing, where different entries arguably have =
different models.=20

>=20
> It is not realistic to change the data model as you did above, since
> we'd have to invent a separate container per combination of modules
> that possibly could be mounted!

As a server implementor, I could augment the example-network-manager =
with as many case nodes as needed. Alternatively, we could introduce =
some kind of "dynamic choice" similar to "when". Then the =
"example-network-manager" could be:

   +--rw managed-devices
      +--rw device* [name]
         +--rw name         string
         +--rw type?        type-enums
         +--rw transport

and the subschema specification would become, e.g.:

"subschema": [
  {
    "root": "/example-network-manager:managed-devices/device",
    "when": "type =3D 'device-type-A'",
    "schemas": [ "schema-A" ]
  },
  {
    "root": "/example-network-manager:managed-devices/device/",
    "when": "type =3D 'device-type-B'",
    "schemas": [ "schema-B" ]
  }
]

Lada

>=20
>=20
> /martin
>=20
>=20
>>=20
>> Lada
>>=20
>>>=20
>>>=20
>>> /martin
>>>=20
>>>=20
>>>>              "schemas": [ "schema-A" ]
>>>>            }
>>>>            {
>>>>              "root":
>>>>                =
"/example-network-manager:managed-devices/device/root/B",
>>>>              "schemas": [ "schema-B" ]
>>>>            }
>>>>          ]
>>>>        },
>>>>        {
>>>>          "name": "schema-A",
>>>>          "yang-modules": [
>>>>            "ietf-interfaces",
>>>>            "example-network-manager"
>>>>          ],
>>>>          "subschema": [
>>>>            {
>>>>              "root":
>>>>                =
"/example-network-manager:managed-devices/device/root/C",
>>>>              "schemas": [ "schema-C" ]
>>>>            }
>>>>          ]
>>>>        },
>>>>        {
>>>>          "name": "schema-B",
>>>>          "yang-modules": [ "ietf-system" ]
>>>>        },
>>>>        {
>>>>          "name": "schema-C",
>>>>          "yang-modules": [
>>>>            "ietf-interfaces",
>>>>            "ietf-ip"
>>>>          ]
>>>>        }
>>>>      ]
>>>>    }
>>>>  }
>>>>=20
>>>> As long as all modules comprising the schema and their possible
>>>> arrangement is known in advance, it should flexible enough. And as =
I
>>>> said, I'd prefer to address this case in schema-mount because the =
model
>>>> of trust between the server and client isn't changed in any way.
>>>>=20
>>>>>=20
>>>>> BTW, in this case, it is not obvious that the top-level server =
knows
>>>>> anything about the data models mounted by C...
>>>>=20
>>>> But then the top-level server cannot possibly serve data for C.
>>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>>=20
>>>>> /martin
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> 2. Apart from YANG Library data, the server just specifies the =
mount
>>>>>>>> points. A client of an NM protocol is expected to fetch a new =
instance
>>>>>>>> of YANG library and/or subordinate mount points as state data =
from a
>>>>>>>> well-known location under each mount point.
>>>>>>>=20
>>>>>>> I think this depends on the use case.  For LNEs, I think this is
>>>>>>> right.
>>>>>>> For some of the other possible use cases being discussed only a
>>>>>>> specific
>>>>>>> model can be mounted.
>>>>>>=20
>>>>>> I guess I need some example scenarios demonstrating that #1 =
cannot be
>>>>>> used for LNE.
>>>>>=20
>>>>=20
>>>> --=20
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Tue May 24 07:33:31 2016
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 E0F8312B034 for ; Tue, 24 May 2016 07:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 dzbuKMvB-B3T for ; Tue, 24 May 2016 07:33:28 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 861BF12D803 for ; Tue, 24 May 2016 07:33:28 -0700 (PDT)
Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by comcast with SMTP id 5DIRbTwXLLCmU5DOhbkAo8; Tue, 24 May 2016 14:33:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464100407; bh=gn3pPd48Kr5IkOOEYRWrlX2IlLvU2qEJs2EUD+abO2A=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=jRbKlsiTdOaTLlIOe3iu266tvyHxY52aolOB5LGAfS7hLRdbsYkOW3mrmrLrXvFt2 i5XR8H6ZG4Cbpyy76aGJU4G1CuE3l9fB/YQQj8CyOP0QAOgdBJxivtiGCkMWtD4oYQ 8G+5gfF1kYEchPz++jYcW/ZXioVOAix+iaEC35iMU599DeMkhBKqO4jzXPbYztXBza i4d/EAE35KjD6yOwAp2Pbvhmylh9FZ+H3XfBcgQASfwMcJajD62M8byebYPHcKtLz9 TLZp3hGECcke6BQTt6ki/qZuMSzHEiJGV/7r/6m+B65+3jYkxpqv7oR2UbKc+hDObn xRWwrrdQ8qvuw==
Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-17v.sys.comcast.net with comcast id yEZS1s00e1nMCLR01EZTbR; Tue, 24 May 2016 14:33:27 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u4OEXQnd009525; Tue, 24 May 2016 10:33:26 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u4OEXPdO009522; Tue, 24 May 2016 10:33:25 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Ladislav Lhotka 
In-Reply-To: <054FFDF1-9D06-4B61-8C8F-AAA9ACFAD3F5@nic.cz> (lhotka@nic.cz)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Tue, 24 May 2016 10:33:25 -0400
Message-ID: <87a8jfh6fe.fsf@hobgoblin.ariadne.com>
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 14:33:30 -0000

(I've not received some of the discussion e-mails, so I am just now
responding.)

Ladislav Lhotka  writes:
> This follows from the fact that YANG doesn't support mixed content:
> there is no way how this whitespace can be made significant.

It seems to me that this is the restriction that should be stated:  "In
NETCONF XML, non-whitespace character content is only allowed as content
of elements that provide values.  Non-whitespace character content in
other locations is ignored."  (Maybe XML defines a better way to say
this.)

Of course, this is a general statement about the XML encoding, not about
any specific Yang element.

> What about comments and processing instructions?

My understanding is that comments are always allowed, because they're
understood to be deleted by the XML parsing process.  Processing
instructions seem to be defined to be significant.  I would assume that
by default no processing instructions are allowed unless Netconf defines
one.

Dale


From nobody Tue May 24 08:06:20 2016
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 0FFA412D86E for ; Tue, 24 May 2016 08:06:18 -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 xZSWyVjdZmNC for ; Tue, 24 May 2016 08:06:16 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 1667312D861 for ; Tue, 24 May 2016 08:06:16 -0700 (PDT)
Received: by mail-qk0-x235.google.com with SMTP id x7so13201393qkd.3 for ; Tue, 24 May 2016 08:06:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=742fQ5CQ1kw9sXwg12E20ZmUDI1FchYXZiwJFrOIh+o=; b=qRtACZSemdk2HFr2TF17Kr4Ofmpkd+XJLaamKO5axaR3LLrp1eXg0jZt7Xj3STgr27 z0oJ/FM7PPB5PeuMwsgzwsCThuw2G+3Buh50J4QxpJxdgaC7ZQfL/cQmsJYJZTsg8maK GpY5Cs8RZmkA3T0Xp2XmtrWB/1nxD/KgBORxON3maiLFUBeUIYJNJhufxa4mu/7j4nE1 mRMwLIhFRX266NcX7Vmh8rad7uGQa/eyH+16c6Ni0dijXs+ip3/l9dQLSIXXCBXrtw8I WKcNPdfJWRJfDoB1bghplTGYWEs27xqThvfOmRTP18ROHaMoIbzuCs/PzN+C7Ubvty+O 6FPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=742fQ5CQ1kw9sXwg12E20ZmUDI1FchYXZiwJFrOIh+o=; b=JcxevNtHHV2hNxiyU1JOquPGkRr3ETAnQgW6Zz9FfFs8X7yLpIz7MQ6aGu3uhvYsS/ E4imkI5zUy4pJ84nsCCNcHl3fYTectXLiuWrXHoFufz44t5xh93KjcGxB6H+ZkvXS9Qe bcg9Z5rLee+39Xbgo4h/jzODi48P0RzAqbmWBG9r4a+WSMjK03yMZ/Kvlvxr1BZHOYyM GsD7WvnEQ8hc+9BJCpvlbd7b7KuCgEwCx6c62PYChcYnaeJRCCaIgbUY8GmjKbIl9rkt GhtFArtQ2EVmzkNylrJG+DoqQLBDi2OqFivSJW6Q53KXIDi5nBIMWi8O/qRayQ+on2U/ BYkw==
X-Gm-Message-State: ALyK8tIyafPu4wkXKYoNXn5hsV46RzeBZWmLoH5cs+tgQj9hxknWlNn5U504nUnnklVhjQ==
X-Received: by 10.55.156.149 with SMTP id f143mr3996476qke.9.1464102375220; Tue, 24 May 2016 08:06:15 -0700 (PDT)
Received: from [10.0.1.3] (c-75-68-179-118.hsd1.ma.comcast.net. [75.68.179.118]) by smtp.gmail.com with ESMTPSA id g52sm15279803qgf.32.2016.05.24.08.06.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 08:06:14 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dean Bogdanovic 
In-Reply-To: <571D7380.1090205@joelhalpern.com>
Date: Tue, 24 May 2016 11:07:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com>  <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com>  <4F517FA6-936C-463C-B5EB-0256A323CAD9@cisco.com>   <571D7380.1090205@joelhalpern.com>
To: "Joel M. Halpern" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] yang model classification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 15:06:18 -0000

Joel,


> On Apr 24, 2016, at 9:31 PM, Joel M. Halpern  =
wrote:
>=20
> What is the relationship between this taxonomy and the many models =
that do not fit its cateogrization?
>=20
> Three examples:
> Models used in ODL to generate results which may be neither network =
services nor network elements.  They may be in between, or in some other =
dimension?

When you say generate results, those models generate results based on =
what? Can you give some examples?

>=20
> Also, models used to describe things in other aspects of environments, =
such as Policy models?

Policy will describe an action on device or on a network service, as in =
general policy is defined as a set of match condition(s) followed by an =
action. I would even say that most policies are for network service =
models.
>=20
> And models of things which are not conventional network elements, such =
as models of compute platforms, models of applications, even models of =
control systems.

We haven=E2=80=99t created device as generic network element, but with =
networking in mind. You can view it as generic. Device should always =
provide what it is capable of and it is a superset into which all other =
models must fit.

Dean

>=20
> Yours,
> Joel
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue May 24 08:09:33 2016
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 E505012D88A for ; Tue, 24 May 2016 08:09:32 -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 NGyfAVcm3uS4 for ; Tue, 24 May 2016 08:09:31 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 2FE3912D882 for ; Tue, 24 May 2016 08:09:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0A68824747A; Tue, 24 May 2016 08:09:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464102569; bh=CBE7GxLTRDt5/TIcyB8y+IzZqeJ5Ot0kVXM7fhxuyqE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=f6em9TqlaB/bfbM2MCd7xmqesXQce0cvuxJXZGk8d3Xr1I75frMlhDTXc8h5P+YPI Wek23SFKgZB/FUK7Y3dJeFXwUlLsMdH/Y2RMV1xwHYSqx0FQY0pAnSzDDGh+06mdHN JWZFByUbSdHm4vYrZb6p4GSPk7mPdogKcTdBwdVI=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 7F51424059F; Tue, 24 May 2016 08:09:28 -0700 (PDT)
To: Dean Bogdanovic , "Joel M. Halpern" 
References:   <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com>  <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com>  <4F517FA6-936C-463C-B5EB-0256A323CAD9@cisco.com>   <571D7380.1090205@joelhalpern.com> 
From: "Joel M. Halpern" 
Message-ID: <8d00f3c0-180c-22e3-ef35-98a5e2a09a0c@joelhalpern.com>
Date: Tue, 24 May 2016 11:09:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] yang model classification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 15:09:33 -0000

I had real trouble mapping the taxonomy to the models I am familair with.

ODL uses YANG models to define the persistent data and interface APIs to 
any and all of its internal services.  These include controlling 
anything and everything the controller does.  But the results of the 
YANG operations are operations internal to ODL, although many result 
after processing in actions applied to the network.

Yours,
Joel

On 5/24/16 11:07 AM, Dean Bogdanovic wrote:
> Joel,
>
>
>> On Apr 24, 2016, at 9:31 PM, Joel M. Halpern  wrote:
>>
>> What is the relationship between this taxonomy and the many models that do not fit its cateogrization?
>>
>> Three examples:
>> Models used in ODL to generate results which may be neither network services nor network elements.  They may be in between, or in some other dimension?
>
> When you say generate results, those models generate results based on what? Can you give some examples?
>
>>
>> Also, models used to describe things in other aspects of environments, such as Policy models?
>
> Policy will describe an action on device or on a network service, as in general policy is defined as a set of match condition(s) followed by an action. I would even say that most policies are for network service models.
>>
>> And models of things which are not conventional network elements, such as models of compute platforms, models of applications, even models of control systems.
>
> We haven’t created device as generic network element, but with networking in mind. You can view it as generic. Device should always provide what it is capable of and it is a superset into which all other models must fit.
>
> Dean
>
>>
>> Yours,
>> Joel
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Tue May 24 08:20:41 2016
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 2097512D8C1 for ; Tue, 24 May 2016 08:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 KkHB7G1qZMrZ for ; Tue, 24 May 2016 08:20:27 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D0112D8BD for ; Tue, 24 May 2016 08:20:23 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id CE116600C7; Tue, 24 May 2016 17:20:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464103221; bh=V+D9QK/KiRGd7hLFv36cGQc7r0IP2zwDWmZ079lYIMk=; h=From:Date:To; b=dhR0jKioyiH2zjW6EQ6ojaYE5JVn9P4H1cj3Fw8X1r+UNgzqxPuUOAfJD8B3X5R23 AP+G09S+3/zgPPakgtPrLpg8cWSKkADMRgng1jRqw1SDuY/9HNp1y7yybyCwQI3JfA 64GJsyIsrhudHS66vrTY3N5BH293nJbxopERuvUY=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <87a8jfh6fe.fsf@hobgoblin.ariadne.com>
Date: Tue, 24 May 2016 17:20:27 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <81F9F575-5DA4-4390-A2F2-B6F55B4DC075@nic.cz>
References: <87a8jfh6fe.fsf@hobgoblin.ariadne.com>
To: "Dale R. Worley" 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 15:20:32 -0000

> On 24 May 2016, at 16:33, Dale R. Worley  wrote:
> 
> (I've not received some of the discussion e-mails, so I am just now
> responding.)
> 
> Ladislav Lhotka  writes:
>> This follows from the fact that YANG doesn't support mixed content:
>> there is no way how this whitespace can be made significant.
> 
> It seems to me that this is the restriction that should be stated:  "In
> NETCONF XML, non-whitespace character content is only allowed as content
> of elements that provide values.

Yes, it means in elements representing leaf and leaf-list instances.

> Non-whitespace character content in other locations is ignored."

You probably meant "whitespace character content" here. (?)

> 
> 
> Of course, this is a general statement about the XML encoding, not about
> any specific Yang element.
> 
>> What about comments and processing instructions?
> 
> My understanding is that comments are always allowed, because they're
> understood to be deleted by the XML parsing process.  Processing
> instructions seem to be defined to be significant.  I would assume that
> by default no processing instructions are allowed unless Netconf defines
> one.

I agree.

Lada

> 
> Dale

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





From nobody Tue May 24 08:26:08 2016
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 5A37412D8C3 for ; Tue, 24 May 2016 08:26:05 -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 k237UuPdEwiJ for ; Tue, 24 May 2016 08:25:59 -0700 (PDT)
Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 2147912D8D3 for ; Tue, 24 May 2016 08:25:54 -0700 (PDT)
Received: by mail-qg0-x234.google.com with SMTP id e93so8755956qgf.2 for ; Tue, 24 May 2016 08:25:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PFq+Udg1Zi4s+S8M0Tiz7/geLyFZA5UByDpdzUyXdP0=; b=HhPfpahy8Dyj6HvuRK1t6478JkS3IeiO7qmhXX9D5rD9Ly77/Ij8ihrBtvpvIVhRY0 oHr3jMIR+KIGIrEZ9Sc1l6uihiRv1VP50eRipX9GeltvOcliuKr5OQkJcZzcHkoyaBk9 0QHMNk0ERQmk9I/f99zPT1BdgayVB3F3xyvfD6WqvyCbv0av0ll+fsBTfyvTrVYB69c+ Y1TjBzl9Q6ZEC1utzDsH5Ic5x6H4jokC/HYoKVlXm1AHnzyUzJT+pBhAfk3WXouqtC/r EFS91vvN8z4QJIZ8/JpJGYGFp/Kyw2NeX6i/YaBgDv24g8yKogSi19N4rSpn266glvqd za6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PFq+Udg1Zi4s+S8M0Tiz7/geLyFZA5UByDpdzUyXdP0=; b=kCH+0gbYYC6EfPkvfg2sYQ+WLuJW/Tyd2V+nOtRRGHjocKNEwTedZuJtFfC+dDVYRe RXjzphXd2dcgzyJIPXhaWwWB7UoW5yrYOd7Lr6GCTH0u1eNIW14dkspIB8wgPbdfYSay 17UEtAvVWz12Gl9gMrb2umx+KaB5xY8l/z5Se0cagT+C3BQmnzubuuTGmFdaDhR025de f1oPdPTnBXVRYLnblb4RGBPQA/mElDZUEkqi/dXBwZpumaGe5gqmQXIlAHoVVdWa9cky AFzCm/yAl1owjybDWgHE8Y94XigMXqcJpX7bZBBotsCJ03WVJPTRYQ46eCrXFLzdAmvz Q1RA==
X-Gm-Message-State: ALyK8tIouOPPktG+ql1fPWLBtniPpoPs2TtEgmYJq0gjYFWm4QjZfyec6wktKkz/nlM/Ng==
X-Received: by 10.140.95.68 with SMTP id h62mr3760993qge.33.1464103553056; Tue, 24 May 2016 08:25:53 -0700 (PDT)
Received: from [10.0.1.3] (c-75-68-179-118.hsd1.ma.comcast.net. [75.68.179.118]) by smtp.gmail.com with ESMTPSA id b73sm956684qkg.44.2016.05.24.08.25.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 08:25:52 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dean Bogdanovic 
In-Reply-To: 
Date: Tue, 24 May 2016 11:26:52 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <41C3B3BF-7578-42A5-A691-A3C6499F2038@gmail.com>
References: <4480964A-C459-45C9-BCD6-A6EAF409C38D@gmail.com>  <015E0A28-E0A0-415D-AE00-F90CBA444A4A@gmail.com>  <0EC4FCB5-1228-4D98-AC5C-12961765AA5D@gmail.com>  
To: "Sterne, Jason (Nokia - CA)" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] input Interface match
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 15:26:06 -0000

Jason,


> On Apr 29, 2016, at 3:33 PM, Sterne, Jason (Nokia - CA) =
 wrote:
>=20
> Hi guys,
>=20
> I agree that we may want to consider other metadata items and also =
agree they will tend to be more implementation-specific.  But rather =
than hold up this base ACL model for metadata why don't we treat =
metadata in either a follow up extension draft or leave them to =
vendor-specific augmentations (if there isn't enough commonality).

I believe that we have to add text that metadata can be match conditions =
in an ACL. In this case, I would add an example at the end of the =
document to show how it can be done through augmentation.

>=20
> I don't think this model should have ingress vs egress as an attribute =
of an ACL. An ACL is directionless on its own and direction can be part =
of how it is applied to an object (e.g. maybe an augmentation to the =
interfaces module to add "ingress-acl" and "egress-acl" leaf refs).

I think that would be a good example to show how to augment model.

Dean

>=20
> Jason
>=20
> -----Original Message-----
> From: EXT Ladislav Lhotka [mailto:lhotka@nic.cz]=20
> Sent: Friday, April 22, 2016 9:49
> To: Dean Bogdanovic; Sterne, Jason (Nokia - CA)
> Cc: netmod WG
> Subject: Re: [netmod] input Interface match
>=20
> Dean Bogdanovic  writes:
>=20
>> Any other opinions on this issue? There were quite a few hands in the=20=

>> air during the WG meeting
>=20
> Unlike packet header fields, metadata are very much =
implementation-specific, and may also depend on the context - e.g. =
whether packet filtering is ingress or egress.
>=20
> The draft cites nftables but in fact nftables includes several =
metadata items, not only input-interface:
>=20
> =
http://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainfor=
mation
>=20
> I would suggest to think about other aspects of ACL type, such as =
"ingress-acl" versus "egress-acl", and either define additional leafs =
for these aspects or utilize multiple inheritance of identities that is =
possible in YANG 1.1.
>=20
> Then, I would extend the "metadata" grouping with other reasonably =
common metadata items (for example, output-interface or packet-length), =
and make each item conditional via "when" and/or "if-feature".
>=20
> Lada
>=20
>>=20
>> Dean
>>=20
>>> On Apr 8, 2016, at 8:25 AM, Sterne, Jason (Nokia - CA) =
 wrote:
>>>=20
>>> Hi Dean,
>>>=20
>>> We should remove the metadata grouping from the base model.  It is =
out of place with the rest of the model and a fairly clean line to draw =
as a boundary for future extension/augmentation.
>>>=20
>>> Regards,
>>> Jason
>>>=20
>>> From: EXT Dean Bogdanovic [mailto:ivandean@gmail.com]
>>> Sent: Friday, April 08, 2016 9:25
>>> To: Sterne, Jason (Nokia - CA)
>>> Cc: netmod WG
>>> Subject: Re: [netmod] input Interface match
>>>=20
>>> Jason,
>>>=20
>>> After looking at the document and the model, it is also about having =
metadata grouping in the model. If you want to have metadata grouping in =
the model, then you have to have something inside and then =
input-interface questions comes up. If you don=E2=80=99t have to have =
metadata grouping in the base model, everything is easy.
>>>=20
>>> I believe this is the right question
>>>=20
>>> Dean
>>>=20
>>> On Apr 8, 2016, at 9:20 AM, Sterne, Jason (Nokia - CA) =
> wrote:
>>>=20
>>> Hi Dean,
>>>=20
>>> Just to clarify -> the main question posed in the WG meeting was =
about the input-interface match criteria.  =46rom the meeting minutes:
>>>=20
>>> Chairs: call for if interface should be in base:
>>>    6 prefer NOT having it in the doc at all
>>>    5 prefer having it in, but as a feature
>>>    2 prefer having it in the doc as required
>>>=20
>>> Maybe we should get agreement on what to do about input-interface =
(on the list) first and then we can figure out what to do about the =
metadata grouping.
>>>=20
>>> Matching on basic IPv4/IPv4/MAC header fields is common =
functionality.  But having that input-interface match on metadata in the =
core model is out of place.  It should be left to further extension =
drafts or vendor specific augmentations (along with whatever other =
metadata might be useful or vendor-specific). Many major implementations =
do not support matching on input-interface (Cisco IOS-XR, Nokia SR OS, =
Brocade, others).  The typical way to associate ACLs and Interfaces is =
by assigning an ACL to an interface as shown in section A.3. of the ACL =
draft.   There is some discussion of this on the NETMOD thread =E2=80=9CRe=
move input-interface (metadata) from netmod-acl-model-07 ?=E2=80=9D.
>>>=20
>>> Regards,
>>> Jason
>>>=20
>>> From: netmod [mailto:netmod-bounces@ietf.org=20
>>> ] On Behalf Of EXT Dean Bogdanovic
>>> Sent: Thursday, April 07, 2016 11:12
>>> To: netmod WG
>>> Subject: [netmod] input Interface match
>>>=20
>>> As the action item from the netmod WG and, hopefully, last open item=20=

>>> in the ACL draft is the leaf input interface in the metadata =
grouping
>>>=20
>>> grouping metadata {
>>>    description
>>>      "Fields associated with a packet which are not in
>>>      the header.";
>>>    leaf input-interface {
>>>      type if:interface-ref {
>>>        require-instance false;
>>>      }
>>>      description
>>>        "Packet was received on this interface.";
>>>    }
>>>  }
>>> }
>>>=20
>>>=20
>>> Here are two questions:
>>> One
>>> Do want to have a metadata grouping in the basic ACL model? If yes,=20=

>>> we have to put in some leafs in there. There are implementations=20
>>> which use metadata as match condition
>>>=20
>>> If we agree that metadata grouping is not needed in the basic model,=20=

>>> then the authors would remove the grouping from the model and I=20
>>> believe that no more discussion is needed on this point
>>>=20
>>> Dean
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C


From nobody Tue May 24 08:41:55 2016
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 C296A12D0DD for ; Tue, 24 May 2016 08:41:53 -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 QOqBvOfZoep9 for ; Tue, 24 May 2016 08:41:52 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 D1507128B44 for ; Tue, 24 May 2016 08:41:51 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id n63so14173634qkf.0 for ; Tue, 24 May 2016 08:41:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l03ZPBsZlWF1+hHG5woX4gQwOFiyGJh9u3pN+4qGzW8=; b=PAWP5V/KcLNXgP92ZN1y8uHGYy/SNUjQo61x3KOkqVXM73GX/gtc/CtGtBUBTVLmLa skfVOpqvbQn68xnoglGe6Bi/lAY/3da5KzDWkQgEQs55ltbMEC919OrSBrF9qnjWKcOb EjtwecmVyjsf5gyaxji0aTzBN618zstTZhZZAuxChXeh/+jY509xzk4gSZONeOMFTjwg 820jHR1QlcM7b40Nxc2IQnFueAyrcmYOxUlGtpYoBrr8cfWE11bZWXbRFa7QhNKdw2QM bsg8MgtEVJ5MJxUCbw1LE4hQ4Pm8/H08QD/pM5dcqHjYzG+w86PvsAfUki+S8INQphwC 8RPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l03ZPBsZlWF1+hHG5woX4gQwOFiyGJh9u3pN+4qGzW8=; b=Jn6fsWsrIzbM6EwZp1mi9kvFX/U/xVKi9wI0/hJbi14bSjT6jpkZ+BurkaRwVz80Fj JG2WXlSDi3Cqo2Po2xznAXlrU4HIbzhM5tWAmb54Dubsy4EyXePLG8SB8Nqlmm+zg522 562eTTeObd+BzXiFQy3kyfw6DqIB41ya6TrLAtoO9rdeuSL2PykaAt6yngvcp2UOE4Pz qCNdZ4hNmZV6MZCUa5sYLsPJdeZZ5m5ANtAfSQfirgXis3MY9XrZxDhi3Hbc7aKobVCT 2fA72LkFAoVZpeeXE7aLRIDzExUwT07jSR90sMfROVVsKfIvjEc6bMwltBdb1wDUrl0e 0Gxw==
X-Gm-Message-State: ALyK8tKDgKOMCuPfNbad/LrUGoy0A/x1ZWwsoy900REKb/I70L7dABqfYqViJfBLBQUNeg==
X-Received: by 10.55.153.3 with SMTP id b3mr3929134qke.102.1464104510883; Tue, 24 May 2016 08:41:50 -0700 (PDT)
Received: from [10.0.1.3] (c-75-68-179-118.hsd1.ma.comcast.net. [75.68.179.118]) by smtp.gmail.com with ESMTPSA id d84sm996421qkj.5.2016.05.24.08.41.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 08:41:50 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dean Bogdanovic 
In-Reply-To: <8d00f3c0-180c-22e3-ef35-98a5e2a09a0c@joelhalpern.com>
Date: Tue, 24 May 2016 11:42:50 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <67A4408D-E02C-4448-8875-C8757F53A3EA@gmail.com>
References:   <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com>  <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com>  <4F517FA6-936C-463C-B5EB-0256A323CAD9@cisco.com>   <571D7380.1090205@joelhalpern.com>  <8d00f3c0-180c-22e3-ef35-98a5e2a09a0c@joelhalpern.com>
To: "Joel M. Halpern" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] yang model classification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 15:41:54 -0000

WG,=20

Joel and I had an offline discussion and in order to make it more clear, =
a text clarification should be added to the document in which is stated =
that this document proposes initial elements for a taxonomy, rather than =
an initial taxonomy.

Dean

> On May 24, 2016, at 11:09 AM, Joel M. Halpern  =
wrote:
>=20
> I had real trouble mapping the taxonomy to the models I am familair =
with.
>=20
> ODL uses YANG models to define the persistent data and interface APIs =
to any and all of its internal services.  These include controlling =
anything and everything the controller does.  But the results of the =
YANG operations are operations internal to ODL, although many result =
after processing in actions applied to the network.
>=20
> Yours,
> Joel
>=20
> On 5/24/16 11:07 AM, Dean Bogdanovic wrote:
>> Joel,
>>=20
>>=20
>>> On Apr 24, 2016, at 9:31 PM, Joel M. Halpern  =
wrote:
>>>=20
>>> What is the relationship between this taxonomy and the many models =
that do not fit its cateogrization?
>>>=20
>>> Three examples:
>>> Models used in ODL to generate results which may be neither network =
services nor network elements.  They may be in between, or in some other =
dimension?
>>=20
>> When you say generate results, those models generate results based on =
what? Can you give some examples?
>>=20
>>>=20
>>> Also, models used to describe things in other aspects of =
environments, such as Policy models?
>>=20
>> Policy will describe an action on device or on a network service, as =
in general policy is defined as a set of match condition(s) followed by =
an action. I would even say that most policies are for network service =
models.
>>>=20
>>> And models of things which are not conventional network elements, =
such as models of compute platforms, models of applications, even models =
of control systems.
>>=20
>> We haven=E2=80=99t created device as generic network element, but =
with networking in mind. You can view it as generic. Device should =
always provide what it is capable of and it is a superset into which all =
other models must fit.
>>=20
>> Dean
>>=20
>>>=20
>>> Yours,
>>> Joel
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20


From nobody Tue May 24 08:47:50 2016
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 EECD612D0C7 for ; Tue, 24 May 2016 08:47:48 -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 aF5tzpU0prqT for ; Tue, 24 May 2016 08:47:47 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 4661612B02A for ; Tue, 24 May 2016 08:47:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 32AEE2643EF; Tue, 24 May 2016 08:47:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464104867; bh=W7cJeX7qzaHcXKhaEJKf9XTgtfAqLJy3CfUWw4TK82E=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YvpLZe0JZt7k1H3NshZKLk0vZQ7j/KqPfghZmDjKKUegrIl5gVmdNgxEjFk44v8q/ cVxyxDOe76ZY8zu72oDqYCf0OiYwuV8KBwBZm6S5mUNTjGbo30X5DZIDWUDYLhcAlu nFQABcsjpycosRwhAp40NvzxyGY5gcDTsnl2KBEY=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BE05C24EA97; Tue, 24 May 2016 08:47:46 -0700 (PDT)
To: Dean Bogdanovic 
References:   <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com>  <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com>  <4F517FA6-936C-463C-B5EB-0256A323CAD9@cisco.com>   <571D7380.1090205@joelhalpern.com>  <8d00f3c0-180c-22e3-ef35-98a5e2a09a0c@joelhalpern.com> <67A4408D-E02C-4448-8875-C8757F53A3EA@gmail.com>
From: "Joel M. Halpern" 
Message-ID: <1de82b44-1eca-9293-fde8-5997ddba8443@joelhalpern.com>
Date: Tue, 24 May 2016 11:47:36 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <67A4408D-E02C-4448-8875-C8757F53A3EA@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] yang model classification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 15:47:49 -0000

Thank you very much Dean.
Yours,
Joel

On 5/24/16 11:42 AM, Dean Bogdanovic wrote:
> WG,
>
> Joel and I had an offline discussion and in order to make it more clear, a text clarification should be added to the document in which is stated that this document proposes initial elements for a taxonomy, rather than an initial taxonomy.
>
> Dean
>
>> On May 24, 2016, at 11:09 AM, Joel M. Halpern  wrote:
>>
>> I had real trouble mapping the taxonomy to the models I am familair with.
>>
>> ODL uses YANG models to define the persistent data and interface APIs to any and all of its internal services.  These include controlling anything and everything the controller does.  But the results of the YANG operations are operations internal to ODL, although many result after processing in actions applied to the network.
>>
>> Yours,
>> Joel
>>
>> On 5/24/16 11:07 AM, Dean Bogdanovic wrote:
>>> Joel,
>>>
>>>
>>>> On Apr 24, 2016, at 9:31 PM, Joel M. Halpern  wrote:
>>>>
>>>> What is the relationship between this taxonomy and the many models that do not fit its cateogrization?
>>>>
>>>> Three examples:
>>>> Models used in ODL to generate results which may be neither network services nor network elements.  They may be in between, or in some other dimension?
>>>
>>> When you say generate results, those models generate results based on what? Can you give some examples?
>>>
>>>>
>>>> Also, models used to describe things in other aspects of environments, such as Policy models?
>>>
>>> Policy will describe an action on device or on a network service, as in general policy is defined as a set of match condition(s) followed by an action. I would even say that most policies are for network service models.
>>>>
>>>> And models of things which are not conventional network elements, such as models of compute platforms, models of applications, even models of control systems.
>>>
>>> We haven’t created device as generic network element, but with networking in mind. You can view it as generic. Device should always provide what it is capable of and it is a superset into which all other models must fit.
>>>
>>> Dean
>>>
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>
>


From nobody Tue May 24 23:55:18 2016
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 B613812D940 for ; Tue, 24 May 2016 23:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 LVrBFm3H8r_u for ; Tue, 24 May 2016 23:55:15 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 71E9A12D642 for ; Tue, 24 May 2016 23:55:15 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 50E341AE030A; Wed, 25 May 2016 08:55:14 +0200 (CEST)
Date: Wed, 25 May 2016 08:55:35 +0200 (CEST)
Message-Id: <20160525.085535.1176974040136865078.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <81F9F575-5DA4-4390-A2F2-B6F55B4DC075@nic.cz>
References: <87a8jfh6fe.fsf@hobgoblin.ariadne.com> <81F9F575-5DA4-4390-A2F2-B6F55B4DC075@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: worley@ariadne.com, netmod@ietf.org
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 06:55:17 -0000

Ladislav Lhotka  wrote:
> 
> > On 24 May 2016, at 16:33, Dale R. Worley  wrote:
> > 
> > (I've not received some of the discussion e-mails, so I am just now
> > responding.)
> > 
> > Ladislav Lhotka  writes:
> >> This follows from the fact that YANG doesn't support mixed content:
> >> there is no way how this whitespace can be made significant.
> > 
> > It seems to me that this is the restriction that should be stated:  "In
> > NETCONF XML, non-whitespace character content is only allowed as content
> > of elements that provide values.
> 
> Yes, it means in elements representing leaf and leaf-list instances.
> 
> > Non-whitespace character content in other locations is ignored."
> 
> You probably meant "whitespace character content" here. (?)
> 
> > 
> > 
> > Of course, this is a general statement about the XML encoding, not about
> > any specific Yang element.
> > 
> >> What about comments and processing instructions?
> > 
> > My understanding is that comments are always allowed, because they're
> > understood to be deleted by the XML parsing process.  Processing
> > instructions seem to be defined to be significant.  I would assume that
> > by default no processing instructions are allowed unless Netconf defines
> > one.
> 
> I agree.

PIs are directed to applications / implementations.  There are no
standard PIs defined.  However, I don't think it would be correct to
state that there MUST NOT be any PIs - if some implementation supports
a PI the client can send it to that implementation and everything is
fine.


/martin


From nobody Wed May 25 02:10:39 2016
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 0E1BB12D17F for ; Wed, 25 May 2016 02:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 TZa9z-2USBL9 for ; Wed, 25 May 2016 02:10:36 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC19312D12C for ; Wed, 25 May 2016 02:10:35 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CFAC811E1; Wed, 25 May 2016 11:10:33 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4W0RIfLeXF67; Wed, 25 May 2016 11:10:21 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 May 2016 11:10:33 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED4592005E; Wed, 25 May 2016 11:10:32 +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 YtxfxAh56Rse; Wed, 25 May 2016 11:10:30 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4999320058; Wed, 25 May 2016 11:10:30 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 24CD93AF2820; Wed, 25 May 2016 11:10:29 +0200 (CEST)
Date: Wed, 25 May 2016 11:10:29 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20160525091029.GA11672@elstar.local>
Mail-Followup-To: Martin Bjorklund , worley@ariadne.com, netmod@ietf.org
References: <877feyrdz9.fsf@hobgoblin.ariadne.com> <20160523.154309.848500367505009627.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160523.154309.848500367505009627.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: worley@ariadne.com, netmod@ietf.org
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 09:10:38 -0000

On Mon, May 23, 2016 at 03:43:09PM +0200, Martin Bjorklund wrote:

> worley@ariadne.com (Dale R. Worley) wrote:
> > 
> > - Abstract
> > 
> > This Abstract does not list what the document does.  E.g., define Yang
> > 1.1.  Also might help to mention upward-incompatibility.  Basically,
> > go through section 1 to see what should be in Abstract.  Perhaps:
> > 
> >    YANG is a data modeling language originally designed to model
> >    configuration and state data manipulated by the Network
> >    Configuration Protocol (NETCONF), NETCONF remote procedure calls,
> >    and NETCONF notifications.  This document describes the syntax and
> >    semantics of version 1.1 of the YANG language.  YANG version 1.1 is
> >    a maintenance release of the YANG language, addressing ambiguities
> >    and defects in the original specification.  There are a small
> >    number of upward-incompatibilities from Yang 1.  This document also
> >    describes how a data model defined in a YANG module is encoded in
> >    the Extensible Markup Language (XML), and how NETCONF operations
> >    are used to manipulate the data.
> 
> Ok, but note that the abstract was changed a bit in -12, so
> incorporapting your proposed changes it would be:
> 
>   YANG is a data modeling language used to model configuration data,
>   state data, remote procedure calls, and notifications for network
>   management protocols. This document describes the syntax and
>   semantics of version 1.1 of the YANG language.  YANG version 1.1 is
>   a maintenance release of the YANG language, addressing ambiguities
>   and defects in the original specification.  There are a small number
>   of backward-incompatibilities from YANG version 1.  This document also
>   specifies the YANG mappings to the Network Configuration Protocol
>   (NETCONF).

Do we have to mention actions in the first sentence as well?

/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 May 25 03:12:02 2016
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 B54DD12D60B for ; Wed, 25 May 2016 03:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 eygj8i62dQPr for ; Wed, 25 May 2016 03:11:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D647A12D65B for ; Wed, 25 May 2016 03:11:52 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id E23191AE0397; Wed, 25 May 2016 12:11:50 +0200 (CEST)
Date: Wed, 25 May 2016 12:12:11 +0200 (CEST)
Message-Id: <20160525.121211.1586299840935146334.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20160525091029.GA11672@elstar.local>
References: <877feyrdz9.fsf@hobgoblin.ariadne.com> <20160523.154309.848500367505009627.mbj@tail-f.com> <20160525091029.GA11672@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: worley@ariadne.com, netmod@ietf.org
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 10:12:00 -0000

Juergen Schoenwaelder  wrote:
> On Mon, May 23, 2016 at 03:43:09PM +0200, Martin Bjorklund wrote:
> 
> > worley@ariadne.com (Dale R. Worley) wrote:
> > > 
> > > - Abstract
> > > 
> > > This Abstract does not list what the document does.  E.g., define Yang
> > > 1.1.  Also might help to mention upward-incompatibility.  Basically,
> > > go through section 1 to see what should be in Abstract.  Perhaps:
> > > 
> > >    YANG is a data modeling language originally designed to model
> > >    configuration and state data manipulated by the Network
> > >    Configuration Protocol (NETCONF), NETCONF remote procedure calls,
> > >    and NETCONF notifications.  This document describes the syntax and
> > >    semantics of version 1.1 of the YANG language.  YANG version 1.1 is
> > >    a maintenance release of the YANG language, addressing ambiguities
> > >    and defects in the original specification.  There are a small
> > >    number of upward-incompatibilities from Yang 1.  This document also
> > >    describes how a data model defined in a YANG module is encoded in
> > >    the Extensible Markup Language (XML), and how NETCONF operations
> > >    are used to manipulate the data.
> > 
> > Ok, but note that the abstract was changed a bit in -12, so
> > incorporapting your proposed changes it would be:
> > 
> >   YANG is a data modeling language used to model configuration data,
> >   state data, remote procedure calls, and notifications for network
> >   management protocols. This document describes the syntax and
> >   semantics of version 1.1 of the YANG language.  YANG version 1.1 is
> >   a maintenance release of the YANG language, addressing ambiguities
> >   and defects in the original specification.  There are a small number
> >   of backward-incompatibilities from YANG version 1.  This document also
> >   specifies the YANG mappings to the Network Configuration Protocol
> >   (NETCONF).
> 
> Do we have to mention actions in the first sentence as well?

I think it would be better to use a more generic term for rpc +
actions.  Maybe operations:

   YANG is a data modeling language used to model configuration data,
   state data, operations, and notifications for network management
   protocols.


But maybe it doesn't even matter; maybe the current text is ok for the
high-level Abstract; you might say that an action is a special kind of
remote procedure call.


/martin



From nobody Wed May 25 03:20:18 2016
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 9EF3E12B03A for ; Wed, 25 May 2016 03:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 ngzJo7u1asAd for ; Wed, 25 May 2016 03:20:14 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E0F12B039 for ; Wed, 25 May 2016 03:20:13 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4984E11E7; Wed, 25 May 2016 12:20:12 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id W8zJrNyXfgC4; Wed, 25 May 2016 12:19:59 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 May 2016 12:20:11 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A342B20069; Wed, 25 May 2016 12:20:10 +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 XZmSbW4FSGKA; Wed, 25 May 2016 12:20:08 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 406F920063; Wed, 25 May 2016 12:20:08 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 75BB93AF29D4; Wed, 25 May 2016 12:20:07 +0200 (CEST)
Date: Wed, 25 May 2016 12:20:06 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20160525102006.GB11672@elstar.local>
Mail-Followup-To: Martin Bjorklund , worley@ariadne.com, netmod@ietf.org
References: <877feyrdz9.fsf@hobgoblin.ariadne.com> <20160523.154309.848500367505009627.mbj@tail-f.com> <20160525091029.GA11672@elstar.local> <20160525.121211.1586299840935146334.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160525.121211.1586299840935146334.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: worley@ariadne.com, netmod@ietf.org
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 10:20:15 -0000

On Wed, May 25, 2016 at 12:12:11PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Mon, May 23, 2016 at 03:43:09PM +0200, Martin Bjorklund wrote:
> > 
> > > worley@ariadne.com (Dale R. Worley) wrote:
> > > > 
> > > > - Abstract
> > > > 
> > > > This Abstract does not list what the document does.  E.g., define Yang
> > > > 1.1.  Also might help to mention upward-incompatibility.  Basically,
> > > > go through section 1 to see what should be in Abstract.  Perhaps:
> > > > 
> > > >    YANG is a data modeling language originally designed to model
> > > >    configuration and state data manipulated by the Network
> > > >    Configuration Protocol (NETCONF), NETCONF remote procedure calls,
> > > >    and NETCONF notifications.  This document describes the syntax and
> > > >    semantics of version 1.1 of the YANG language.  YANG version 1.1 is
> > > >    a maintenance release of the YANG language, addressing ambiguities
> > > >    and defects in the original specification.  There are a small
> > > >    number of upward-incompatibilities from Yang 1.  This document also
> > > >    describes how a data model defined in a YANG module is encoded in
> > > >    the Extensible Markup Language (XML), and how NETCONF operations
> > > >    are used to manipulate the data.
> > > 
> > > Ok, but note that the abstract was changed a bit in -12, so
> > > incorporapting your proposed changes it would be:
> > > 
> > >   YANG is a data modeling language used to model configuration data,
> > >   state data, remote procedure calls, and notifications for network
> > >   management protocols. This document describes the syntax and
> > >   semantics of version 1.1 of the YANG language.  YANG version 1.1 is
> > >   a maintenance release of the YANG language, addressing ambiguities
> > >   and defects in the original specification.  There are a small number
> > >   of backward-incompatibilities from YANG version 1.  This document also
> > >   specifies the YANG mappings to the Network Configuration Protocol
> > >   (NETCONF).
> > 
> > Do we have to mention actions in the first sentence as well?
> 
> I think it would be better to use a more generic term for rpc +
> actions.  Maybe operations:
> 
>    YANG is a data modeling language used to model configuration data,
>    state data, operations, and notifications for network management
>    protocols.
 
I like 'operations' and the notion of operations = rpcs + actions.
 
/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 May 25 05:28:28 2016
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 982D912D52B; Wed, 25 May 2016 05:28: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] 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 Z8zrBMWNn_gb; Wed, 25 May 2016 05:28:25 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 77C1F12D554; Wed, 25 May 2016 05:28:25 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id D54851CC026F; Wed, 25 May 2016 14:28:25 +0200 (CEST)
From: Ladislav Lhotka 
To: "Ing-Wher \(Helen\) Chen" , "draft-ietf-ospf-yang\@ietf.org" , "draft-ietf-isis-yang-isis-cfg\@ietf.org" , "draft-acee-rtgwg-yang-rib-extend\@ietf.org" , "draft-ietf-netmod-routing-cfg\@ietf.org" , netmod@ietf.org
In-Reply-To: 
References: 
User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 25 May 2016 14:28:23 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] identical RIB augmentations in OSPF and ISIS YANG models
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 12:28:27 -0000

"Ing-Wher (Helen) Chen"  writes:

> Hello,
>
> I notice that the OSPF and ISIS YANG models
> ( and
> ) each
> defines its own augmentation to
> /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route that adds metric,
> tag and route-type to the OSPF and ISIS YANG models.

Both IS-IS and OSPF define route-type but each uses a different enumeration
type, so presumably their semantics are different as well. So I am not
sure it is a good idea to define a common route-type in
ietf-routing. What would be its type?

I remember there was already a similar discussion about metric,
too. Different protocols use metrics with different ranges and
semantics, so the conclusion then was to leave the definition of metric
to each protocol.

Route tag is uint32 in all cases, so it could be added to ietf-routing.

Lada

>
> Separately, I notice that the RIB extension YANG model () also defines a similar augmentation to /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route that adds metric and tag (but not route-type).
>
> Since it looks like the metric/tag/route-type augmentation is common to most routing protocols, may I suggest that these attributes, metric, tag, and route-type, be placed in the (base) routing YANG model () instead of individual routing protocols or even the RIB extension model?
>
> Thanks,
> Helen

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


From nobody Wed May 25 07:03:04 2016
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 3969A12D7AC; Wed, 25 May 2016 07:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=kuatrotechnology.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 rsRjCJG1Yex1; Wed, 25 May 2016 07:02:55 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0636.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B9612D18F; Wed, 25 May 2016 06:59:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=81pAZKmUWr8kaDi7ItAjyM5BusjprOg5S7tmGxP6jQ4=; b=MsUR4cB56H+DQW6FJf2uxOJdF32RJWHMHjnmqBSXUxzxldq6V87WRLv8rDRKG7AoOQN0n9lB7GKqV98pwCwT2+1SUl8pTCZ7SPr5c2SNvnRE9HohqdaBRDBbRsUUpIHXDdwBVNaGz1p9HsUAr6cPqeuuyygE3mclqNGxFAhQ0tA=
Received: from DB5PR06MB0950.eurprd06.prod.outlook.com (10.162.158.140) by DB5PR06MB0949.eurprd06.prod.outlook.com (10.162.158.14) with Microsoft SMTP Server (TLS) id 15.1.506.2; Wed, 25 May 2016 13:59:00 +0000
Received: from DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) by DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) with mapi id 15.01.0506.009; Wed, 25 May 2016 13:59:00 +0000
From: "Ing-Wher (Helen) Chen" 
To: Ladislav Lhotka , "draft-ietf-ospf-yang@ietf.org" , "draft-ietf-isis-yang-isis-cfg@ietf.org" , "draft-acee-rtgwg-yang-rib-extend@ietf.org" , "draft-ietf-netmod-routing-cfg@ietf.org" , "netmod@ietf.org" 
Thread-Topic: identical RIB augmentations in OSPF and ISIS YANG models
Thread-Index: AdG1x/2pAjrzaAn4TVOECoNkbQ+FvQAuPACAAAIRx7A=
Date: Wed, 25 May 2016 13:58:59 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=kuatrotech.com;
x-originating-ip: [98.191.72.170]
x-ms-office365-filtering-correlation-id: 36660dda-7102-4444-aa53-08d384a4b90d
x-microsoft-exchange-diagnostics: 1; DB5PR06MB0949; 5:rWiDdnZsR95Zk0A9wueB8xNMI6X8lBsoPtjjGV1VhE63QCVkzo0bCi7UBv+/FKZfdg3vD6QOZhjaDAm/r/UbJ3FEvhGa50J/PcrgzXNKnpCKN8v86W3Uc9cVa5v8khJT4j3uVOrnu1OYLsHj6+IS4w==; 24:NejEDbuHtBWtICaUNAg8cA0mBeAERyrqPHIqeR55NZ4pFqN0Fy4KDNXYZxThbHCK/qaeKGqLfAX2QILoFvNncw3kLbeb8loLav18LRlhm7Y=; 7:LW+TQ1X+2Kyr4jhrmvxVlz0ADf/VdSm4bNNoc58JIkJg0V6MUiHozAQy4F03wFhXMJOYr1BQ8UpmjLRgRaujOC05Y3ql1v0wbVezS4id43zhz3xCwiSelwkGiFatHB6XjMpjvK4cL7Hpxmx7T4V+Kt35DgnruWfJeg0DqJlZ0FhJEZUflwti+A9DRdUUNHck
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR06MB0949;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046); SRVR:DB5PR06MB0949; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB0949; 
x-forefront-prvs: 09538D3531
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(13464003)(122556002)(54356999)(19580405001)(19580395003)(87936001)(3846002)(1220700001)(6116002)(10400500002)(2906002)(2201001)(586003)(50986999)(5008740100001)(76176999)(107886002)(189998001)(8936002)(66066001)(5001770100001)(81166006)(8676002)(575784001)(86362001)(3280700002)(3660700001)(92566002)(5002640100001)(5004730100002)(2950100001)(15975445007)(74316001)(11100500001)(102836003)(5003600100002)(33656002)(9686002)(2900100001)(77096005)(76576001)(2501003)(170073001)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR06MB0949; H:DB5PR06MB0950.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: kuatrotech.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2016 13:59:00.0117 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR06MB0949
Archived-At: 
Subject: Re: [netmod] identical RIB augmentations in OSPF and ISIS YANG models
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 14:03:02 -0000

Hi Lada,

"metric" in this case is the operational state metric (or cost) of a route,=
 and
has identical definitions in in all three drafts (OSPF, ISIS, and RIB exten=
sion).
(They're all defined to be type uint32, with no range or default value.)  I
understand that each protocol might define and configure the metric (or
cost) of a link differently, but shouldn't the operational state,
/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/ospf:metric or
/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/isis:metric or
/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:metrc , be
comparable and with the same semantics so that RIB can determine the
best route?

For route-type, is it possible to define the type as an identityref, and le=
t
each protocol define identities?  (Similar to how=20
/rt:routing/rt:routing-protocols/rt:routing-protocol/rt:type is defined to =
be
type identityref.)

For route-tag, I missed that ISIS defines is as a leaf-list instead of a le=
af...

Thanks,
Helen

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Wednesday, May 25, 2016 8:28 AM
> To: Ing-Wher (Helen) Chen ; draft-ietf-ospf-
> yang@ietf.org; draft-ietf-isis-yang-isis-cfg@ietf.org; draft-acee-rtgwg-y=
ang-
> rib-extend@ietf.org; draft-ietf-netmod-routing-cfg@ietf.org;
> netmod@ietf.org
> Subject: Re: identical RIB augmentations in OSPF and ISIS YANG models
>=20
> "Ing-Wher (Helen) Chen"  writes:
>=20
> > Hello,
> >
> > I notice that the OSPF and ISIS YANG models
> > ( and
> > ) each
> > defines its own augmentation to
> > /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route that adds metric,
> > tag and route-type to the OSPF and ISIS YANG models.
>=20
> Both IS-IS and OSPF define route-type but each uses a different enumerati=
on
> type, so presumably their semantics are different as well. So I am not su=
re it
> is a good idea to define a common route-type in ietf-routing. What would =
be
> its type?
>=20
> I remember there was already a similar discussion about metric, too.
> Different protocols use metrics with different ranges and semantics, so t=
he
> conclusion then was to leave the definition of metric to each protocol.
>=20
> Route tag is uint32 in all cases, so it could be added to ietf-routing.
>=20
> Lada
>=20
> >
> > Separately, I notice that the RIB extension YANG model
> () also
> defines a similar augmentation to /rt:routing-
> state/rt:ribs/rt:rib/rt:routes/rt:route that adds metric and tag (but not=
 route-
> type).
> >
> > Since it looks like the metric/tag/route-type augmentation is common to
> most routing protocols, may I suggest that these attributes, metric, tag,=
 and
> route-type, be placed in the (base) routing YANG model
> () instead =
of
> individual routing protocols or even the RIB extension model?
> >
> > Thanks,
> > Helen
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C


From nobody Wed May 25 07:10:31 2016
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 6046412D751; Wed, 25 May 2016 07:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level: 
X-Spam-Status: No, score=-15.947 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=-1.426, 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 4JTqolZysdVl; Wed, 25 May 2016 07:10:27 -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 537CD12D720; Wed, 25 May 2016 07:09:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5330; q=dns/txt; s=iport; t=1464185345; x=1465394945; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KJFLnWZsgwQaBbDUXa8QPisP2pX3DPlMBu1kD1AwwNs=; b=Ug9LhTeuahTt8A5DHKX/48oTdLlvdsJSc2jZbDbeLYyfhk9+M3jkrFxM wfYf6wMG8V37SsM1e0w7b44cPSZjWZWfnIeEAapwxpnmd/qo4d9swntyu sKLfu0U/tHtJgLiVEOqT0VTI2ZPwLDr7pWZtq124ZYS1ZdSNIyn1a/ov8 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQAXsUVX/4YNJK1cgzdWfQa3YoIPA?= =?us-ascii?q?Q2BdiKFbwIcgSI4FAEBAQEBAQFlJ4RDAQEBBCMRUQQCAQgRBAEBAwIjAwICAjA?= =?us-ascii?q?UAQgIAQEEARKILw6yOZF4AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYlyhD+DA?= =?us-ascii?q?YJZBZg3AYV/hWWCO4IAjRyPSwEeAQFCg21uiQh/AQEB?=
X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208";a="277679140"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 May 2016 14:09:04 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4PE94ff004651 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 14:09:04 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.1104.5; Wed, 25 May 2016 10:09:02 -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.1104.009; Wed, 25 May 2016 10:09:03 -0400
From: "Acee Lindem (acee)" 
To: "Ing-Wher (Helen) Chen" , Ladislav Lhotka , "draft-ietf-ospf-yang@ietf.org" , "draft-ietf-isis-yang-isis-cfg@ietf.org" , "draft-acee-rtgwg-yang-rib-extend@ietf.org" , "draft-ietf-netmod-routing-cfg@ietf.org" , "netmod@ietf.org" 
Thread-Topic: identical RIB augmentations in OSPF and ISIS YANG models
Thread-Index: AdG1x/2pAjrzaAn4TVOECoNkbQ+FvQA2ncWAAAMqB4D//7+9gA==
Date: Wed, 25 May 2016 14:09:03 +0000
Message-ID: 
References:   
In-Reply-To: 
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: <7F99BCB7187FC44D9FB8558684C0DF49@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] identical RIB augmentations in OSPF and ISIS YANG models
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 14:10:29 -0000

SGkgTGFkYSwgSGVsZW4sIA0KDQpPbiA1LzI1LzE2LCA5OjU4IEFNLCAiSW5nLVdoZXIgKEhlbGVu
KSBDaGVuIiA8aWNoZW5Aa3VhdHJvdGVjaC5jb20+IHdyb3RlOg0KDQo+SGkgTGFkYSwNCj4NCj4i
bWV0cmljIiBpbiB0aGlzIGNhc2UgaXMgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIG1ldHJpYyAob3Ig
Y29zdCkgb2YgYQ0KPnJvdXRlLCBhbmQNCj5oYXMgaWRlbnRpY2FsIGRlZmluaXRpb25zIGluIGlu
IGFsbCB0aHJlZSBkcmFmdHMgKE9TUEYsIElTSVMsIGFuZCBSSUINCj5leHRlbnNpb24pLg0KPihU
aGV5J3JlIGFsbCBkZWZpbmVkIHRvIGJlIHR5cGUgdWludDMyLCB3aXRoIG5vIHJhbmdlIG9yIGRl
ZmF1bHQgdmFsdWUuKQ0KPkkNCj51bmRlcnN0YW5kIHRoYXQgZWFjaCBwcm90b2NvbCBtaWdodCBk
ZWZpbmUgYW5kIGNvbmZpZ3VyZSB0aGUgbWV0cmljIChvcg0KPmNvc3QpIG9mIGEgbGluayBkaWZm
ZXJlbnRseSwgYnV0IHNob3VsZG4ndCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUsDQo+L3J0OnJvdXRp
bmctc3RhdGUvcnQ6cmlicy9ydDpyaWIvcnQ6cm91dGVzL3J0OnJvdXRlL29zcGY6bWV0cmljIG9y
DQo+L3J0OnJvdXRpbmctc3RhdGUvcnQ6cmlicy9ydDpyaWIvcnQ6cm91dGVzL3J0OnJvdXRlL2lz
aXM6bWV0cmljIG9yDQo+L3J0OnJvdXRpbmctc3RhdGUvcnQ6cmlicy9ydDpyaWIvcnQ6cm91dGVz
L3J0OnJvdXRlL3JpYi1leHQ6bWV0cmMgLCBiZQ0KPmNvbXBhcmFibGUgYW5kIHdpdGggdGhlIHNh
bWUgc2VtYW50aWNzIHNvIHRoYXQgUklCIGNhbiBkZXRlcm1pbmUgdGhlDQo+YmVzdCByb3V0ZT8N
Cg0KSSBjYW7igJl0IHRoaW5rIGEgc2luZ2xlIHVpbnQzMiBtZXRyaWMgc2hvdWxkIGhhbmRsZSB0
aGUgc3VwZXJzZXQgb2YgY2FzZXMuDQoNCg0KPg0KPkZvciByb3V0ZS10eXBlLCBpcyBpdCBwb3Nz
aWJsZSB0byBkZWZpbmUgdGhlIHR5cGUgYXMgYW4gaWRlbnRpdHlyZWYsIGFuZA0KPmxldA0KPmVh
Y2ggcHJvdG9jb2wgZGVmaW5lIGlkZW50aXRpZXM/ICAoU2ltaWxhciB0byBob3cNCj4vcnQ6cm91
dGluZy9ydDpyb3V0aW5nLXByb3RvY29scy9ydDpyb3V0aW5nLXByb3RvY29sL3J0OnR5cGUgaXMg
ZGVmaW5lZA0KPnRvIGJlDQo+dHlwZSBpZGVudGl0eXJlZi4pDQoNClRoYXQgaXMgYSBnb29kIGlk
ZWEuIFRyeWluZyB0byBkZWZpbmUgYWxsIHRoZSBwb3NzaWJsZSByb3V0ZS10eXBlcyBhDQpwcmlv
cmkgaXMgYW4gZXhlcmNpc2UgaW4gZnV0aWxpdHkuDQoNCg0KPg0KPkZvciByb3V0ZS10YWcsIEkg
bWlzc2VkIHRoYXQgSVNJUyBkZWZpbmVzIGlzIGFzIGEgbGVhZi1saXN0IGluc3RlYWQgb2YgYQ0K
PmxlYWYuLi4NCg0KVGhpcyBpcyBub3Qgd2lkZWx5IGltcGxlbWVudGVkIChpZiBhdCBhbGwpIGFs
dGhvdWdoIEkgaGF2ZSBkcmFmdCBmb3IgT1NQRg0Kc3VwcG9ydGluZyBtdWx0aXBsZSB0YWdzIHBl
ciBwcmVmaXguIElzIGl0IHBvc3NpYmxlIHRvIHN1cHBvcnQgYSBzaW5nbGUNCnRhZyBpbiB0aGUg
aWV0Zi1yb3V0aW5nIGFuZCBzdXBwb3J0IGFuIGF1Z21lbnRhdGlvbiB0byBzdXBwb3J0IG11bHRp
cGxlcw0KKHdpdGhvdXQgaXQgYmVpbmcgdG9vIHVnbHkpPw0KDQpUaGFua3MsDQpBY2VlDQoNCj4N
Cj5UaGFua3MsDQo+SGVsZW4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG
cm9tOiBMYWRpc2xhdiBMaG90a2EgW21haWx0bzpsaG90a2FAbmljLmN6XQ0KPj4gU2VudDogV2Vk
bmVzZGF5LCBNYXkgMjUsIDIwMTYgODoyOCBBTQ0KPj4gVG86IEluZy1XaGVyIChIZWxlbikgQ2hl
biA8aWNoZW5Aa3VhdHJvdGVjaC5jb20+OyBkcmFmdC1pZXRmLW9zcGYtDQo+PiB5YW5nQGlldGYu
b3JnOyBkcmFmdC1pZXRmLWlzaXMteWFuZy1pc2lzLWNmZ0BpZXRmLm9yZzsNCj4+ZHJhZnQtYWNl
ZS1ydGd3Zy15YW5nLQ0KPj4gcmliLWV4dGVuZEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1uZXRtb2Qt
cm91dGluZy1jZmdAaWV0Zi5vcmc7DQo+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJl
OiBpZGVudGljYWwgUklCIGF1Z21lbnRhdGlvbnMgaW4gT1NQRiBhbmQgSVNJUyBZQU5HIG1vZGVs
cw0KPj4gDQo+PiAiSW5nLVdoZXIgKEhlbGVuKSBDaGVuIiA8aWNoZW5Aa3VhdHJvdGVjaC5jb20+
IHdyaXRlczoNCj4+IA0KPj4gPiBIZWxsbywNCj4+ID4NCj4+ID4gSSBub3RpY2UgdGhhdCB0aGUg
T1NQRiBhbmQgSVNJUyBZQU5HIG1vZGVscw0KPj4gPiAoPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLW9zcGYteWFuZy0wND4gYW5kDQo+PiA+IDxodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pc2lzLXlhbmctaXNpcy1jZmctMDg+KSBlYWNoDQo+PiA+
IGRlZmluZXMgaXRzIG93biBhdWdtZW50YXRpb24gdG8NCj4+ID4gL3J0OnJvdXRpbmctc3RhdGUv
cnQ6cmlicy9ydDpyaWIvcnQ6cm91dGVzL3J0OnJvdXRlIHRoYXQgYWRkcyBtZXRyaWMsDQo+PiA+
IHRhZyBhbmQgcm91dGUtdHlwZSB0byB0aGUgT1NQRiBhbmQgSVNJUyBZQU5HIG1vZGVscy4NCj4+
IA0KPj4gQm90aCBJUy1JUyBhbmQgT1NQRiBkZWZpbmUgcm91dGUtdHlwZSBidXQgZWFjaCB1c2Vz
IGEgZGlmZmVyZW50DQo+PmVudW1lcmF0aW9uDQo+PiB0eXBlLCBzbyBwcmVzdW1hYmx5IHRoZWly
IHNlbWFudGljcyBhcmUgZGlmZmVyZW50IGFzIHdlbGwuIFNvIEkgYW0gbm90DQo+PnN1cmUgaXQN
Cj4+IGlzIGEgZ29vZCBpZGVhIHRvIGRlZmluZSBhIGNvbW1vbiByb3V0ZS10eXBlIGluIGlldGYt
cm91dGluZy4gV2hhdA0KPj53b3VsZCBiZQ0KPj4gaXRzIHR5cGU/DQo+PiANCj4+IEkgcmVtZW1i
ZXIgdGhlcmUgd2FzIGFscmVhZHkgYSBzaW1pbGFyIGRpc2N1c3Npb24gYWJvdXQgbWV0cmljLCB0
b28uDQo+PiBEaWZmZXJlbnQgcHJvdG9jb2xzIHVzZSBtZXRyaWNzIHdpdGggZGlmZmVyZW50IHJh
bmdlcyBhbmQgc2VtYW50aWNzLCBzbw0KPj50aGUNCj4+IGNvbmNsdXNpb24gdGhlbiB3YXMgdG8g
bGVhdmUgdGhlIGRlZmluaXRpb24gb2YgbWV0cmljIHRvIGVhY2ggcHJvdG9jb2wuDQo+PiANCj4+
IFJvdXRlIHRhZyBpcyB1aW50MzIgaW4gYWxsIGNhc2VzLCBzbyBpdCBjb3VsZCBiZSBhZGRlZCB0
byBpZXRmLXJvdXRpbmcuDQo+PiANCj4+IExhZGENCj4+IA0KPj4gPg0KPj4gPiBTZXBhcmF0ZWx5
LCBJIG5vdGljZSB0aGF0IHRoZSBSSUIgZXh0ZW5zaW9uIFlBTkcgbW9kZWwNCj4+ICg8aHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFjZWUtcnRnd2cteWFuZy1yaWItZXh0ZW5kLTAx
PikgYWxzbw0KPj4gZGVmaW5lcyBhIHNpbWlsYXIgYXVnbWVudGF0aW9uIHRvIC9ydDpyb3V0aW5n
LQ0KPj4gc3RhdGUvcnQ6cmlicy9ydDpyaWIvcnQ6cm91dGVzL3J0OnJvdXRlIHRoYXQgYWRkcyBt
ZXRyaWMgYW5kIHRhZyAoYnV0DQo+Pm5vdCByb3V0ZS0NCj4+IHR5cGUpLg0KPj4gPg0KPj4gPiBT
aW5jZSBpdCBsb29rcyBsaWtlIHRoZSBtZXRyaWMvdGFnL3JvdXRlLXR5cGUgYXVnbWVudGF0aW9u
IGlzIGNvbW1vbg0KPj50bw0KPj4gbW9zdCByb3V0aW5nIHByb3RvY29scywgbWF5IEkgc3VnZ2Vz
dCB0aGF0IHRoZXNlIGF0dHJpYnV0ZXMsIG1ldHJpYywNCj4+dGFnLCBhbmQNCj4+IHJvdXRlLXR5
cGUsIGJlIHBsYWNlZCBpbiB0aGUgKGJhc2UpIHJvdXRpbmcgWUFORyBtb2RlbA0KPj4gKDxodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMjE+
KQ0KPj5pbnN0ZWFkIG9mDQo+PiBpbmRpdmlkdWFsIHJvdXRpbmcgcHJvdG9jb2xzIG9yIGV2ZW4g
dGhlIFJJQiBleHRlbnNpb24gbW9kZWw/DQo+PiA+DQo+PiA+IFRoYW5rcywNCj4+ID4gSGVsZW4N
Cj4+IA0KPj4gLS0NCj4+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+IFBHUCBLZXkg
SUQ6IEU3NEU4QzBDDQoNCg==


From nobody Wed May 25 07:13:55 2016
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 B5C2812D6F3; Wed, 25 May 2016 07:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level: 
X-Spam-Status: No, score=-15.947 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=-1.426, 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 63uHyyn3ujOS; Wed, 25 May 2016 07:13:52 -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 1F10A12D77F; Wed, 25 May 2016 07:12:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5736; q=dns/txt; s=iport; t=1464185559; x=1465395159; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qKT7r7ISKcZ8T/K/ZEANzkA674uxJUyUJXzr9InNXMw=; b=gc7h7NvVAoLeFulFqCKKKOozzPwO5INq1Y7331xX+w2Mt8ToqVOxs/ZY MfcHbUOHeg0z/9hc26w8WXiv2Qx0tTrlvReDym2kFB1WHe/56KZZotQTf 6wSVIFMZkQW5wE2x+mUqGFn1GCk1cIXmTgbd3Ow9teX5Q0a8q5OUWNtC+ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAgAMskVX/5RdJa1cgzdWbw4Gt2KCD?= =?us-ascii?q?wENgXYihW8CHIEiOBQBAQEBAQEBZSeEQwEBAQQjEVEEAgEIEQQBAQECAiMDAgI?= =?us-ascii?q?CMBQBCAgBAQQBEogvDrI5kXgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBiXKEP?= =?us-ascii?q?4MBglkFmDcBhX+FZYI7ggCNHI9LAR4BAUKDbW6JCH8BAQE?=
X-IronPort-AV: E=Sophos;i="5.26,364,1459814400"; d="scan'208";a="276251788"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 14:12:38 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4PECbSG001998 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 14:12:38 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 10:12:36 -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.1104.009; Wed, 25 May 2016 10:12:37 -0400
From: "Acee Lindem (acee)" 
To: "Acee Lindem (acee)" , "Ing-Wher (Helen) Chen" , Ladislav Lhotka , "draft-ietf-ospf-yang@ietf.org" , "draft-ietf-isis-yang-isis-cfg@ietf.org" , "draft-acee-rtgwg-yang-rib-extend@ietf.org" , "draft-ietf-netmod-routing-cfg@ietf.org" , "netmod@ietf.org" 
Thread-Topic: identical RIB augmentations in OSPF and ISIS YANG models
Thread-Index: AdG1x/2pAjrzaAn4TVOECoNkbQ+FvQA2ncWAAAMqB4D//7+9gIAAAQAA
Date: Wed, 25 May 2016 14:12:37 +0000
Message-ID: 
References:    
In-Reply-To: 
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: <605F56DFE61B094DB2F7302FBF9C90C9@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] identical RIB augmentations in OSPF and ISIS YANG models
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 14:13:54 -0000

U2lnaOKApiANCg0KT24gNS8yNS8xNiwgMTA6MDkgQU0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxh
Y2VlQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5IaSBMYWRhLCBIZWxlbiwgDQo+DQo+T24gNS8yNS8x
NiwgOTo1OCBBTSwgIkluZy1XaGVyIChIZWxlbikgQ2hlbiIgPGljaGVuQGt1YXRyb3RlY2guY29t
PiB3cm90ZToNCj4NCj4+SGkgTGFkYSwNCj4+DQo+PiJtZXRyaWMiIGluIHRoaXMgY2FzZSBpcyB0
aGUgb3BlcmF0aW9uYWwgc3RhdGUgbWV0cmljIChvciBjb3N0KSBvZiBhDQo+PnJvdXRlLCBhbmQN
Cj4+aGFzIGlkZW50aWNhbCBkZWZpbml0aW9ucyBpbiBpbiBhbGwgdGhyZWUgZHJhZnRzIChPU1BG
LCBJU0lTLCBhbmQgUklCDQo+PmV4dGVuc2lvbikuDQo+PihUaGV5J3JlIGFsbCBkZWZpbmVkIHRv
IGJlIHR5cGUgdWludDMyLCB3aXRoIG5vIHJhbmdlIG9yIGRlZmF1bHQgdmFsdWUuKQ0KPj5JDQo+
PnVuZGVyc3RhbmQgdGhhdCBlYWNoIHByb3RvY29sIG1pZ2h0IGRlZmluZSBhbmQgY29uZmlndXJl
IHRoZSBtZXRyaWMgKG9yDQo+PmNvc3QpIG9mIGEgbGluayBkaWZmZXJlbnRseSwgYnV0IHNob3Vs
ZG4ndCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUsDQo+Pi9ydDpyb3V0aW5nLXN0YXRlL3J0OnJpYnMv
cnQ6cmliL3J0OnJvdXRlcy9ydDpyb3V0ZS9vc3BmOm1ldHJpYyBvcg0KPj4vcnQ6cm91dGluZy1z
dGF0ZS9ydDpyaWJzL3J0OnJpYi9ydDpyb3V0ZXMvcnQ6cm91dGUvaXNpczptZXRyaWMgb3INCj4+
L3J0OnJvdXRpbmctc3RhdGUvcnQ6cmlicy9ydDpyaWIvcnQ6cm91dGVzL3J0OnJvdXRlL3JpYi1l
eHQ6bWV0cmMgLCBiZQ0KPj5jb21wYXJhYmxlIGFuZCB3aXRoIHRoZSBzYW1lIHNlbWFudGljcyBz
byB0aGF0IFJJQiBjYW4gZGV0ZXJtaW5lIHRoZQ0KPj5iZXN0IHJvdXRlPw0KPg0KPkkgY2Fu4oCZ
dCB0aGluayBhIHNpbmdsZSB1aW50MzIgbWV0cmljIHNob3VsZCBoYW5kbGUgdGhlIHN1cGVyc2V0
IG9mIGNhc2VzLg0KDQpJIHRoaW5rIGEgc2luZ2xlIHVpbnQzMiBtZXRyaWMgc2hvdWxkIGhhbmRs
ZSB0aGUgc3VwZXJzZXQgb2YgY2FzZXMgZm9yIHRoZQ0KZ2xvYmFsIFJJQi4gDQoNCg0KPg0KPg0K
Pj4NCj4+Rm9yIHJvdXRlLXR5cGUsIGlzIGl0IHBvc3NpYmxlIHRvIGRlZmluZSB0aGUgdHlwZSBh
cyBhbiBpZGVudGl0eXJlZiwgYW5kDQo+PmxldA0KPj5lYWNoIHByb3RvY29sIGRlZmluZSBpZGVu
dGl0aWVzPyAgKFNpbWlsYXIgdG8gaG93DQo+Pi9ydDpyb3V0aW5nL3J0OnJvdXRpbmctcHJvdG9j
b2xzL3J0OnJvdXRpbmctcHJvdG9jb2wvcnQ6dHlwZSBpcyBkZWZpbmVkDQo+PnRvIGJlDQo+PnR5
cGUgaWRlbnRpdHlyZWYuKQ0KPg0KPlRoYXQgaXMgYSBnb29kIGlkZWEuIFRyeWluZyB0byBkZWZp
bmUgYWxsIHRoZSBwb3NzaWJsZSByb3V0ZS10eXBlcyBhDQo+cHJpb3JpIGlzIGFuIGV4ZXJjaXNl
IGluIGZ1dGlsaXR5Lg0KPg0KPg0KPj4NCj4+Rm9yIHJvdXRlLXRhZywgSSBtaXNzZWQgdGhhdCBJ
U0lTIGRlZmluZXMgaXMgYXMgYSBsZWFmLWxpc3QgaW5zdGVhZCBvZiBhDQo+PmxlYWYuLi4NCj4N
Cj5UaGlzIGlzIG5vdCB3aWRlbHkgaW1wbGVtZW50ZWQgKGlmIGF0IGFsbCkgYWx0aG91Z2ggSSBo
YXZlIGRyYWZ0IGZvciBPU1BGDQo+c3VwcG9ydGluZyBtdWx0aXBsZSB0YWdzIHBlciBwcmVmaXgu
IElzIGl0IHBvc3NpYmxlIHRvIHN1cHBvcnQgYSBzaW5nbGUNCj50YWcgaW4gdGhlIGlldGYtcm91
dGluZyBhbmQgc3VwcG9ydCBhbiBhdWdtZW50YXRpb24gdG8gc3VwcG9ydCBtdWx0aXBsZXMNCj4o
d2l0aG91dCBpdCBiZWluZyB0b28gdWdseSk/DQo+DQo+VGhhbmtzLA0KPkFjZWUNCj4NCj4+DQo+
PlRoYW5rcywNCj4+SGVsZW4NCj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+
PiBGcm9tOiBMYWRpc2xhdiBMaG90a2EgW21haWx0bzpsaG90a2FAbmljLmN6XQ0KPj4+IFNlbnQ6
IFdlZG5lc2RheSwgTWF5IDI1LCAyMDE2IDg6MjggQU0NCj4+PiBUbzogSW5nLVdoZXIgKEhlbGVu
KSBDaGVuIDxpY2hlbkBrdWF0cm90ZWNoLmNvbT47IGRyYWZ0LWlldGYtb3NwZi0NCj4+PiB5YW5n
QGlldGYub3JnOyBkcmFmdC1pZXRmLWlzaXMteWFuZy1pc2lzLWNmZ0BpZXRmLm9yZzsNCj4+PmRy
YWZ0LWFjZWUtcnRnd2cteWFuZy0NCj4+PiByaWItZXh0ZW5kQGlldGYub3JnOyBkcmFmdC1pZXRm
LW5ldG1vZC1yb3V0aW5nLWNmZ0BpZXRmLm9yZzsNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+PiBT
dWJqZWN0OiBSZTogaWRlbnRpY2FsIFJJQiBhdWdtZW50YXRpb25zIGluIE9TUEYgYW5kIElTSVMg
WUFORyBtb2RlbHMNCj4+PiANCj4+PiAiSW5nLVdoZXIgKEhlbGVuKSBDaGVuIiA8aWNoZW5Aa3Vh
dHJvdGVjaC5jb20+IHdyaXRlczoNCj4+PiANCj4+PiA+IEhlbGxvLA0KPj4+ID4NCj4+PiA+IEkg
bm90aWNlIHRoYXQgdGhlIE9TUEYgYW5kIElTSVMgWUFORyBtb2RlbHMNCj4+PiA+ICg8aHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3NwZi15YW5nLTA0PiBhbmQNCj4+PiA+
IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pc2lzLXlhbmctaXNpcy1j
ZmctMDg+KSBlYWNoDQo+Pj4gPiBkZWZpbmVzIGl0cyBvd24gYXVnbWVudGF0aW9uIHRvDQo+Pj4g
PiAvcnQ6cm91dGluZy1zdGF0ZS9ydDpyaWJzL3J0OnJpYi9ydDpyb3V0ZXMvcnQ6cm91dGUgdGhh
dCBhZGRzIG1ldHJpYywNCj4+PiA+IHRhZyBhbmQgcm91dGUtdHlwZSB0byB0aGUgT1NQRiBhbmQg
SVNJUyBZQU5HIG1vZGVscy4NCj4+PiANCj4+PiBCb3RoIElTLUlTIGFuZCBPU1BGIGRlZmluZSBy
b3V0ZS10eXBlIGJ1dCBlYWNoIHVzZXMgYSBkaWZmZXJlbnQNCj4+PmVudW1lcmF0aW9uDQo+Pj4g
dHlwZSwgc28gcHJlc3VtYWJseSB0aGVpciBzZW1hbnRpY3MgYXJlIGRpZmZlcmVudCBhcyB3ZWxs
LiBTbyBJIGFtIG5vdA0KPj4+c3VyZSBpdA0KPj4+IGlzIGEgZ29vZCBpZGVhIHRvIGRlZmluZSBh
IGNvbW1vbiByb3V0ZS10eXBlIGluIGlldGYtcm91dGluZy4gV2hhdA0KPj4+d291bGQgYmUNCj4+
PiBpdHMgdHlwZT8NCj4+PiANCj4+PiBJIHJlbWVtYmVyIHRoZXJlIHdhcyBhbHJlYWR5IGEgc2lt
aWxhciBkaXNjdXNzaW9uIGFib3V0IG1ldHJpYywgdG9vLg0KPj4+IERpZmZlcmVudCBwcm90b2Nv
bHMgdXNlIG1ldHJpY3Mgd2l0aCBkaWZmZXJlbnQgcmFuZ2VzIGFuZCBzZW1hbnRpY3MsIHNvDQo+
Pj50aGUNCj4+PiBjb25jbHVzaW9uIHRoZW4gd2FzIHRvIGxlYXZlIHRoZSBkZWZpbml0aW9uIG9m
IG1ldHJpYyB0byBlYWNoIHByb3RvY29sLg0KPj4+IA0KPj4+IFJvdXRlIHRhZyBpcyB1aW50MzIg
aW4gYWxsIGNhc2VzLCBzbyBpdCBjb3VsZCBiZSBhZGRlZCB0byBpZXRmLXJvdXRpbmcuDQo+Pj4g
DQo+Pj4gTGFkYQ0KPj4+IA0KPj4+ID4NCj4+PiA+IFNlcGFyYXRlbHksIEkgbm90aWNlIHRoYXQg
dGhlIFJJQiBleHRlbnNpb24gWUFORyBtb2RlbA0KPj4+ICg8aHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWFjZWUtcnRnd2cteWFuZy1yaWItZXh0ZW5kLTAxPikNCj4+PmFsc28NCj4+
PiBkZWZpbmVzIGEgc2ltaWxhciBhdWdtZW50YXRpb24gdG8gL3J0OnJvdXRpbmctDQo+Pj4gc3Rh
dGUvcnQ6cmlicy9ydDpyaWIvcnQ6cm91dGVzL3J0OnJvdXRlIHRoYXQgYWRkcyBtZXRyaWMgYW5k
IHRhZyAoYnV0DQo+Pj5ub3Qgcm91dGUtDQo+Pj4gdHlwZSkuDQo+Pj4gPg0KPj4+ID4gU2luY2Ug
aXQgbG9va3MgbGlrZSB0aGUgbWV0cmljL3RhZy9yb3V0ZS10eXBlIGF1Z21lbnRhdGlvbiBpcyBj
b21tb24NCj4+PnRvDQo+Pj4gbW9zdCByb3V0aW5nIHByb3RvY29scywgbWF5IEkgc3VnZ2VzdCB0
aGF0IHRoZXNlIGF0dHJpYnV0ZXMsIG1ldHJpYywNCj4+PnRhZywgYW5kDQo+Pj4gcm91dGUtdHlw
ZSwgYmUgcGxhY2VkIGluIHRoZSAoYmFzZSkgcm91dGluZyBZQU5HIG1vZGVsDQo+Pj4gKDxodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMjE+
KQ0KPj4+aW5zdGVhZCBvZg0KPj4+IGluZGl2aWR1YWwgcm91dGluZyBwcm90b2NvbHMgb3IgZXZl
biB0aGUgUklCIGV4dGVuc2lvbiBtb2RlbD8NCj4+PiA+DQo+Pj4gPiBUaGFua3MsDQo+Pj4gPiBI
ZWxlbg0KPj4+IA0KPj4+IC0tDQo+Pj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4+
IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+DQoNCg==


From nobody Wed May 25 09:08:28 2016
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 6DAD412D7CD for ; Wed, 25 May 2016 09:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.793
X-Spam-Level: 
X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo3sN2qF61vN for ; Wed, 25 May 2016 09:08:25 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412FD12D7CF for ; Wed, 25 May 2016 09:08:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AEx8fujjykJdBgST0QmKM+pMHcJW+ocH5FiUaRP/YZg=; b=IHGe7oBZUaVkHNiqizGila7Ywaj/nxPjMjnK4bd8Ffboyr3hwqCxoWkTxeOsRcTGVtlS8saqoIsUlb4rKhhx4kHLKRAFHp7jIZxseIEjVH4YMAR8Pnthe+JGOeG9JtCNOirVHbE/if56p+MbXQccxm3eP5KDVnLOABWTVwEU8wM=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (TLS) id 15.1.501.7; Wed, 25 May 2016 16:08:20 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0501.013; Wed, 25 May 2016 16:08:20 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , "Martin Bjorklund" 
Thread-Topic: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
Thread-Index: AQHRtPkPnzkfkoSK/UaHkNiKym2xnJ/JYJ6AgAARPYCAAAI2AIAAHj4A
Date: Wed, 25 May 2016 16:08:20 +0000
Message-ID: 
References: <877feyrdz9.fsf@hobgoblin.ariadne.com> <20160523.154309.848500367505009627.mbj@tail-f.com> <20160525091029.GA11672@elstar.local> <20160525.121211.1586299840935146334.mbj@tail-f.com> <20160525102006.GB11672@elstar.local>
In-Reply-To: <20160525102006.GB11672@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.16.0.160506
authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.10]
x-ms-office365-filtering-correlation-id: a54d2f17-9569-4cac-30c7-08d384b6caa3
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 5:csdKEfa/NECIDcLlc84wRFmZhz8NKh4FyLlOT6rN/iJJZQwiGOxH37WkQQYbvjwDz5vaf6h3l7gSpmqImYuyNI2o6xmtf7K+6r2Exu1zQxeDTQcLEhV1xlKF9zbNOOWOCnzcp2Lidd5gyxysBO+ZmQ==; 24:GpKUcclEIYLBubmV1oXggz7KkmIbUKcNzFzkgBSTG7gdAvKseKWfg2OePoa8WZzLdAtjlA9BwuOSB+w3SNXUIckawR5q3RlJLYTwRFohCm4=; 7:d+d5l4OpccQ9jvw04hGRBfyiGYa3o5JAl2K2ACmF9Cr3Z3kJcQ4IilhPjvhx4YU0Z/jfCq3+t7XOhmU6fkeF5O2RX3rqXwQFTbm2kRTXrHQzu3Dod1uWJLiGYalAF4nE53bxW+JrsutiAiLeMhYyqiQWEYlC7ON60QBLwjVXSiZuf6Ffqa3L3161WySLutoz
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1450;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);  SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; 
x-forefront-prvs: 09538D3531
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(36756003)(92566002)(87936001)(5008740100001)(2950100001)(8676002)(2900100001)(93886004)(586003)(4326007)(81166006)(1220700001)(33656002)(3280700002)(106116001)(5002640100001)(3660700001)(6116002)(102836003)(2906002)(3846002)(10400500002)(5001770100001)(82746002)(230783001)(54356999)(76176999)(189998001)(66066001)(50986999)(8936002)(86362001)(122556002)(77096005)(83716003)(83506001)(11100500001)(99286002)(5004730100002)(104396002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
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: 25 May 2016 16:08:20.6416 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450
Archived-At: 
Cc: "worley@ariadne.com" , "netmod@ietf.org" 
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 16:08:27 -0000

DQoNCj4+IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIHVzZSBhIG1vcmUgZ2VuZXJpYyB0
ZXJtIGZvciBycGMgKw0KPj4gYWN0aW9ucy4gIE1heWJlIG9wZXJhdGlvbnM6DQo+PiANCj4+ICAg
IFlBTkcgaXMgYSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIHVzZWQgdG8gbW9kZWwgY29uZmlndXJh
dGlvbiBkYXRhLA0KPj4gICAgc3RhdGUgZGF0YSwgb3BlcmF0aW9ucywgYW5kIG5vdGlmaWNhdGlv
bnMgZm9yIG5ldHdvcmsgbWFuYWdlbWVudA0KPj4gICAgcHJvdG9jb2xzLg0KPiANCj5JIGxpa2Ug
J29wZXJhdGlvbnMnIGFuZCB0aGUgbm90aW9uIG9mIG9wZXJhdGlvbnMgPSBycGNzICsgYWN0aW9u
cy4NCg0KKzENCg0KS2VudA0KDQoNCg==


From nobody Wed May 25 20:25:35 2016
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 CEC9C12D58E for ; Wed, 25 May 2016 20:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 TO1j_9n1WwBC for ; Wed, 25 May 2016 20:25:30 -0700 (PDT)
Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (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 9776712D54F for ; Wed, 25 May 2016 20:25:30 -0700 (PDT)
Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by comcast with SMTP id 5lvKbi0AuWmAB5lvNb0dst; Thu, 26 May 2016 03:25:29 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464233129; bh=DQx5+KtB/5YRIKRfwTuqKGPlXdutTKMqz84ChJXhaVw=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Qos3ELutuBkug2ys2dQ8hWymgv3i5A9y8H5LzxznUo993w5rFtOboRqKHWCGS0HHe rLGAYl7OLP5XFaqJYTLxPNYXeDQTvi+Kgq4uPVhPmWCcjh0Ht6kRofq45rR1Yl1xEy vhpvWRUW1SuYQ6iGl7IV9TEgkvgouIhclYKljN9Z+y4ViPRwfX1lqdRyeCkAW/Bgq+ EdDC1Z12qhqzwBua/U+OpU6cJrEb+d0WgAK2XS0oo6EwdKloAaipKBYNdA80rlwyIh F+pxocGc5F6ny+Gsuiamwc30Iq+pPG8JH1hsv1mRWCY+6TAIESHYZCT0A8nZ+nOg7q vKBF7aRaazbeQ==
Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-10v.sys.comcast.net with comcast id yrRT1s00E1nMCLR01rRU5v; Thu, 26 May 2016 03:25:28 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u4Q3PQQA032062; Wed, 25 May 2016 23:25:26 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u4Q3PQbV032055; Wed, 25 May 2016 23:25:26 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Martin Bjorklund , netmod@ietf.org
In-Reply-To: <20160523.154309.848500367505009627.mbj@tail-f.com>
References: <20160523.154309.848500367505009627.mbj@tail-f.com>, <877feyrdz9.fsf@hobgoblin.ariadne.com>
Sender: worley@ariadne.com (Dale R. Worley)
Date: Wed, 25 May 2016 23:25:26 -0400
Message-ID: <87mvndfql5.fsf@hobgoblin.ariadne.com>
Archived-At: 
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 03:25:34 -0000

Martin Bjorklund  wrote on Mon, 23 May 2016 15:43:09 +0200 (CEST):
> worley@ariadne.com (Dale R. Worley) wrote:

Almost all of these points I'm happy with the authors fixing in the
manner they suggest.  The points where I have further comment are:

> > The incompatibilities should be marked whether the old, incompatible
> > usage always causes an error "at compile time", "at run time", or
> > changed behavior.
> 
> Ok, but I'd like to avoid the term "compile-time" here.

True...  The distinction I'm looking for is "Incompatible usage will
cause an error report before the software is put into operation."
vs. "Incompatible usage will cause an error report when the software is
in operation." vs. "Incompatible usage will cause a difference in
behavior without an error report."

> How about:
> 
>    The following changes are not backwards compatible with YANG version
>    1:
> 
>    o  Changed the rules for the interpretation of escaped characters in
>       double quoted strings.  This is an backwards incompatible change
>       from YANG version 1.  A module that uses a character sequence that
>       is now illegal must change the string to match the new rules.  See
>       Section 6.1.3 for details.
> 
>    o  An unquoted string cannot contain any single or double quote
>       characters.  This is an backwards incompatible change from YANG
>       version 1.  A module that uses such quote characters must change
>       the string to match the new rules.  See Section 6.1.3 for details.

I assume that the first two situations will cause an error report before
the module is put into production.

>    o  Made noncharacters illegal in the built-in type "string".  This
>       change affects the run-time behavior of YANG-based protocols.

What happens if you attempt to use a noncharacter in a string?

> >    o  leaf: A data node that exists in at most one instance in the data
> >       tree.  A leaf has a value but no child nodes.
> > 
> > I'm not sure that this is correct; a leaf schema node inside a list
> > schema node can have many instances in a data tree.  The real
> > criterion is that it has a value but no child nodes.
> 
> Would "one instance per parent node" work?

I think that's correct.  The case I would expect to be tricky is be a
leaf contained in a list, but the XML for lists wraps an element around
each list member, so each leaf has "one instance per parent node".

It might be worth inserting a definition of "node" as shorthand for
"data node", as there seems to be no definition of "node" alone, but it
is commonly used to mean "data node".  In particular, the reader needs
to be fully aware that "node" is a node in the schema tree, not an
instantiation thereof.

> > It would be useful to insert a note somewhere that all data is either
> > "configuration" or "state" data.  It's hard to learn that now, because
> > the terms "configuration data" and "state data" are defined only by
> > reference to RFC 6241.
> 
> But this is not strictly correct.  For example RPC input is neither
> config nor state.  Section 3 has:
> 
>   o data tree: An instantiated tree of any data modeled with YANG,
>     e.g., configuration data, state data, combined configuration and
>     state data, RPC or action input, RPC or action output, or
>     notification.

Section 4.1 contains a similar statement.

I think the problem I'm having is with the first sentences of 4.2.3:

   YANG can model state data, as well as configuration data, based on
   the "config" statement.

At first read, this suggests that data is partitioned into
"configuration data" and "state data".  What's really happening is that
there are various sorts of data, but some contexts admit a mixture of
configuration and state data, so the data model definitions of those
contexts requires that individual data items can be flagged as
configuration vs. data.  Maybe starting 4.2.3 like this would work:

   In some contexts, data modeled by YANG can contain mixtures of state
   data and configuration data, based on the "config" statement.  When a
   node is tagged with "config false", its subhierarchy is flagged as
   state data.

> > - section 3.1
> > 
> > There is an overall question regarding whitespace in XML in
> > "non-significant" places.  Is it allowed in the XML representation of
> > data trees?  And if so, precisely what whitespace is allowed?  Also,
> > to what degree is the whitespace shown in examples what is allowed on
> > the wire, and to what degree is it there just to make the example
> > easier to read?  (It's possible that XML has implemented some sort of
> > global solution for the issue of non-significant whitespace, but back
> > when I was using it regularly, there was none.)
> 
> Good catch!  Interesting that noone has found this before!

This point is discussed in other e-mail.

> > - section 4.2.7
> > 
> >    YANG allows the data model to segregate incompatible nodes into
> >    distinct choices using the "choice" and "case" statements.  The
> >    "choice" statement contains a set of "case" statements that define
> >    sets of schema nodes that cannot appear together.  Each "case" may
> >    contain multiple nodes, but each node may appear in only one "case"
> >    under a "choice".
> > 
> >    When a node from one case is created in the data tree, all nodes from
> >    all other cases are implicitly deleted.  The server handles the
> >    enforcement of the constraint, preventing incompatibilities from
> >    existing in the configuration.
> > 
> >    The choice and case nodes appear only in the schema tree but not in
> >    the data tree.  The additional levels of hierarchy are not needed
> >    beyond the conceptual schema.
> > 
> > This description reads very oddly.  AFAICT, "choice" simply defines a
> > union type, where each alternative is a container (usually called a
> > structure or record).  Or rather, it's conceptually a container, but
> > in an XML instance of data, there is no start-end tags for the
> > structure as a whole (paralleling the lack of start-end tags for lists
> > as a whole).  Once you state that, it's clear why there are "sets of
> > schema nodes that cannot appear together".
> 
> I'm worried that if we describe "case" as a special kind of
> "container" it will be pretty confusing.

Perhaps so.  But it seems to me that it needs to be pointed out that the
"choice" and "case" are not materialized as XML nodes themselves; you
can only tell which case is present by the fact that one or more of its
elements are present.  Hmmm...  The third paragraph says that, more or
less.  I think the second paragraph would be clearer if the third
paragraph was moved before it, and some text added:

   The choice and case nodes appear only in the schema tree but not in
   the data tree.  The additional levels of hierarchy are not needed
   beyond the conceptual schema.  >>The presence of a case is indicated by
   the presence of one or more of the nodes within it.<<

   When a node from one case is created in the data tree, all nodes from
   all other cases are implicitly deleted.  The server handles the
   enforcement of the constraint, preventing incompatibilities from
   existing in the configuration.

> > - section 4.2.8
> > 
> > It would help to give a general discussion of augmenting.  If one
> > module augments another, is the augmented data definition part of the
> > data structures defined by augmenting module or the augmented one?
> > 
> > If I've got it right, this module:
> > 
> >    module /system/login/user {
> >      namespace "urn:user";
> >      prefix "user";
> > 
> >      list user {
> >        key "name";
> >        leaf name {
> >          type string;
> >        }
> >        leaf full-name {
> >          type string;
> >        }
> >        leaf class {
> >          type string;
> >        }
> >      }
> >    }
> > 
> > gives this as the XML encoding of a typical data tree:
> > 
> >      
> >        alicew
> >        Alice N. Wonderland
> >        drop-out
> >        1024
> >      
> 
> Did you mean:
> 
>       
>         alicew
>         Alice N. Wonderland
>         drop-out
>       
> 
> ?

Yes, I made a mistake there.  (I must have.)

> > whereas the *existence* (in some sense) of this module:
> > 
> >    module /system/login/user-augmenter {
> >      namespace "urn:user-extension";
> >      prefix "ext";
> > 
> >      augment /system/login/user {
> >        when "class != 'wheel'";
> >        leaf uid {
> >          type uint16 {
> >            range "1000 .. 30000";
> >          }
> >        }
> >      }
> >    }
> > 
> > changes the encoding of the data tree to:
> > 
> >      
> >        alicew
> >        Alice N. Wonderland
> >        drop-out
> >        1024
> >      
> > 
> > What is it that triggers this action-at-a-distance?
> 
> The fact that the server implements both modules.

It might be helpful to state that explicitly.  Could we add to the
second paragraph of 4.2.8 this:

   (( The "augment" statement defines the location in the data model
   hierarchy where new nodes are inserted, and the "when" statement
   defines the conditions when the new nodes are valid. ))  When a
   server implements a module containing an "augment" statement, that
   implies that the server's implementation of the augmented module
   contains the additional nodes.

> >    Developers of YANG modules and submodules are RECOMMENDED to choose
> >    names ...
> > 
> > "RECOMMENDED" is an adjective which qualifies the choice, not an
> > adverb that qualifies the act of choosing.  I think you want
> > "... SHOULD choose ...".  See RFC 2119.
> 
> Hmm.  Are you saying that if RECOMMENDED is used as an adverb then it
> should not be used like this?  A quick grep on some RFCs gives quite a
> few matches, e.g. this one from RFC 6353:
> 
>    Implementations are RECOMMENDED to support and use
>    the contextEngineID discovery mechanism defined in [RFC5343].
> 
> Is this also not correct?
> 
> Can you give an example of a correct usage of RECOMMENDED?

Hmmm, it's curious.  I wouldn't use "Developers are recommended to
choose ..." but I would use "the ingress-egress-aggregate is RECOMMENDED
to have ...".  It's not clear to me what the distinction is.  In any
case, I defer to what the RFC Editor considers good usage.

> > - section 5.1.2
> > 
> >    YANG allows modeling of data in multiple hierarchies, where data may
> >    have more than one top-level node.  Models that have multiple top-
> >    level nodes are sometimes convenient, and are supported by YANG.
> > 
> > Any single module seems to define only one data structure, the one
> > whose elements are the items listed in the module, and Yang doesn't
> > seem to provide for any sort of "model" definition other than a
> > module.  Or are the nodes at the top level within the module all
> > usable as independent data structures?
> 
> The term "data structure" isn't used in the document.  YANG allows
> a module to define more than one subtree.

OK, I think I see where I was confused.  I think that would have been
avoided if the 5.1.2 started:

   YANG allows modeling of data in multiple hierarchies.  Each top-level
   data node in a module defines an independent hierarchy.  Models that
   have ...

> >    NETCONF is capable of carrying any XML content as the payload in the
> >     and  elements.  The top-level nodes of YANG modules
> >    are encoded as child elements, in any order, within these elements.
> > 
> > This isn't very clear.  AFAICT from the example:
> > 
> >    NETCONF  and  elements each contain sequences of
> >    instances of top-level nodes of the appropriate YANG module.
> 
> I am not sure that this proposed text is more clear, maybe b/c I don't
> see what in the original text is unclear.

See the preceding item for what I think the problem is.

> > Given that this example is about a particular module, it would help if
> > the module namespace and prefix was used correctly in the XML example.
> 
> I think the example uses the XML namespace correctly.

What I was noticing is that the module statement starts:

     module example-config {
       yang-version 1.1;
       namespace "urn:example:config";
       prefix "co";

       container system { ... }
       ...

And the XML starts:

     
       
         
           
         
         
           
             
             ...

But it seemed to me that the recommended style for the XML has the
specified prefix "co" used on the data nodes defined in the module:

           ...
           
             
             ...

Looking again at 7.1.4 and the examples, it seems that the style of the
examples is to use an XMLNS prefix only when a data node is from a
different namespace than the top-level node containing it, i.e., data
nodes with imported definitions.  I was expecting to see prefixes used
even for non-imported data nodes.  But reading 7.1.4 suggests that I am
incorrect there.

> > - section 5.2
> > 
> >    YANG modules and submodules are typically stored in files, one module
> >    or submodule per file.
> > 
> > This might be clearer as "... one module or submodule statement per
> > file."
> 
> How is "one module per file" interpreted differently than "one module
> statement per file"?

The problem is that "module" is ambiguous.  One meaning is the
collection of all data definitions that are usable in the NETCONF
operations.  The other is the contents of the module statement.  In a
sense, module (1) = module (2) plus zero or more submodules.

See this in 4.2.1:

   A module may be divided into submodules, based on the needs of the
   module owner.  The external view remains that of a single module,
   regardless of the presence or size of its submodules.

So one could read the current sentence as meaning that a file could
contain a module (1) statement and all of the submodule statements that
are included by the module (1) statement, and so the contents of the
file as a whole constitutes a module (2).  The question is, does one
module (1) go in a file, or one module (2) go in a file?

> >    XML namespaces for private modules are assigned by the organization
> >    owning the module without a central registry.  Namespace URIs MUST be
> >    chosen so they cannot collide with standard or other enterprise
> >    namespaces, for example by using the enterprise or organization name
> >    in the namespace.
> > 
> > I don't see the use of "without a central registry"; haven't you
> > already said the module is is private?  (Or is "without a central
> > registry" a term of art?)
> 
> It could be that all namespaces had to be registered with IANA for
> example.

I guess I consider that namespaces registered with IANA or another
organization are the uncommon case.  But perhaps in network management
the reverse is the case.

> > - section 5.5
> > 
> > This section talks a great deal about why scoping is done, but isn't
> > specifically clear what the rules are.  (Traditionally, the rule is
> > stated as either what range of source text a particular definition is
> > visible in, or given an identifier use, how the matching definition is
> > found.)
> > 
> >    Scoped definitions MUST NOT shadow definitions at a higher scope.  A
> >    type or grouping cannot be defined if a higher level in the schema
> >    hierarchy has a definition with a matching identifier.
> > 
> > I think the second sentence is confusing, because (to me) the term
> > "schema hierarchy" implies the data tree structure, whereas the
> > scoping rule seems to be intended to be entirely lexical.  In either
> > case, this needs to be clarified.
> 
> The first sentence says:
> 
>   Typedefs and groupings may appear nested under many YANG statements,
>   allowing these to be lexically scoped by the hierarchy under which
>   they appear.
> 
> Maybe it would help to move paragraph 2 and 3 to the end, so that the
> motivational text is at the end of the section?

It looks like current paragraphs 1, 4, and 5 are prescriptive, and 2 and
3 are motivational.  Putting 1, 4, and 5 together should make them
clearer.  But since paragraph 2 starts with "Scoping...", it really
needs to be after 1.  So, yes, moving 2 and 3 to the end seems like the
clearest order.  Does it make sense to you to put all of the motivation
at the end of this section?

> > - section 5.6.5
> > 
> > I suspect that if a server implements module A, and A imports B, the
> > server is not required to implement B.  (Even if A references
> > groupings in B.)  The answer to that should probably be stated
> > explicitly.
> 
> It is not so simple.  The rest of the text defines the rules for when
> the server is required to implement B.

Yes, I was wrong there.  (I can't see why I made that mistake.)

> > Is this the correct way to specify multiple revisions of this module?
> > Or is this an informal notation for the two module definitions:
> > 
> >      module b {
> >        yang-version 1.1;
> >        namespace "urn:example:b";
> >        prefix "b";
> > 
> >        revision 2015-04-04;
> >        revision 2015-01-01;
> > 
> >        typedef myenum {
> >          type enumeration {
> >            enum zero; // added in 2015-01-01
> >            enum one;  // added in 2015-04-04
> >          }
> >        }
> > 
> >        container x {  // added in 2015-01-01
> >          container y; // added in 2015-04-04
> >        }
> >      }
> > 
> >      module b {
> >        yang-version 1.1;
> >        namespace "urn:example:b";
> >        prefix "b";
> > 
> >        revision 2015-01-01;
> > 
> >        typedef myenum {
> >          type enumeration {
> >            enum zero; // added in 2015-01-01
> >          }
> >        }
> > 
> >        container x {  // added in 2015-01-01
> >        }
> >      }
> > 
> > If it is the latter, it would help the new reader to explain the
> > convention (as no example of a multi-revision module is given in the
> > document).
> 
> The comments are not required.  There is no correct (mandated) way to
> specify which changes are done in a new revision.

What I was concerned with is what does the above module statement do?
If I understand correctly, it defines the 2015-04-04 revision of b, and
also tells us that a 2015-01-01 revision exists, but does not define
that revision.  Implicitly, there must be a .yang file somewhere
containing the module statement that defines the 2015-01-01 revision of
b.

But despite that the text talks about the 2015-01-01 revision ('can
implement revision "2015-01-01" or "2015-04-04" of module "b"'), that
file is not included in the example, which is not what I expected, which
led me to wonder if the 2015-01-01 revision was somehow also defined by
the presented "module b" statement.  I would have had less trouble with
the example if the definition of the earlier revision of b was also
given.

> > - section 6
> > 
> >    YANG modules use the UTF-8 [RFC3629] character encoding.
> > 
> > Better to say that YANG modules use the Unicode character set and are
> > stored in files using the UTF-8 character encoding.
> 
> Do you mean:
> 
> OLD:
> 
>    YANG modules use the UTF-8 [RFC3629] character encoding.
> 
>    Legal characters in YANG modules are the Unicode and ISO/IEC 10646
>    [ISO.10646] characters, including tab, carriage return, and line feed
>    but excluding the other C0 control characters, the surrogate blocks,
>    and the noncharacters.  The character syntax is formally defined by
>    the rule "yang-char" in Section 14.
> 
> NEW:
> 
>    Legal characters in YANG modules are the Unicode and ISO/IEC 10646
>    [ISO.10646] characters, including tab, carriage return, and line feed
>    but excluding the other C0 control characters, the surrogate blocks,
>    and the noncharacters.  The character syntax is formally defined by
>    the rule "yang-char" in Section 14.
> 
>    YANG modules and submodules are stored in files using the UTF-8
>    [RFC3629] character encoding.

Yes, that's right.

> > This might be a good place to talk about line-breaks in Yang source
> > files.  It looks from section 14 that line-breaks MUST be either CRLF
> > or LF.
> > 
> > It is worth noting (either here or in 6.1.3) how line-breaks inside
> > quoted strings are transcribed into the string's value.  As now
> > written, it seems that the line-break is transcribed identically to
> > how it is represented in the source.  That means (1) If the source is
> > recoded with the other type of line break, the semantics of the Yang
> > code change; and (2) if the source uses line-breaks of one type (CRLF
> > or LF), only that type can be directly transcribed into string values.
> > (But regardless of the source line-breaks, an LF can be transcribed
> > into a double-quoted string with "\n".  But a CRLF cannot be
> > transcribed into a double-quoted string with escape sequences.  Was
> > that intended, or was "\r" intended to be legal?)

Don't forget this.

> > - section 6.1
> > 
> >    This section details the rules for recognizing tokens from an input
> >    stream.
> > 
> > Generally, language definitions intersperse the narrative text with
> > the relevant grammar definitions.  Yang's statement grammar is simple
> > enough that one doesn't need to see the context-free part of the
> > grammar to understand the narrative for statements.  But when reading
> > about tokenization, not having the grammar presented at the same time
> > is quite a burden.  I'd recommend duplicating the relevant productions
> > from section 14 into the subsections of section 6.
> > 
> > There is some sort of exposition problem.  The result of
> > "tokenization" is that the sequence of characters of the source is
> > converted into a sequence of "tokens".  Then some subset of the tokens
> > is discarded as being non-significant (e.g., whitespace and comments),
> > and the remainder is parsed with a context-free grammar.  Here I can't
> > figure out what the set of tokens is.  Looking at the grammar in
> > section 14, it seems to be a context-free grammar on characters.  But
> > that implies that there is no separate tokenization phase.
> > 
> > An example that shows the problems:
> > 
> >    mod:ext
> > 
> > Is this one token, which is also an extension keyword, or is it a
> > sequence of three tokens?
> 
> The text says:
> 
>   A token in YANG is either a keyword, a string, a semicolon (";"), or
>   braces ("{" or "}").
> 
> and:
> 
>   A keyword is [...] or a prefix identifier, followed by a colon
>   (":"), followed by a language extension keyword.
> 
> So "mod:ext" is one token.

Certainly it can be one token.  My question is how do verify that it is
not a string?  I think that may be the origin of my confusion here is
that I haven't spotted a clear syntax for unquoted string.  In most
programming languages, mod:ext would be parsed as an identifier, a
colon, and an identifier.  In YANG, identifiers are usually tokenized as
strings, so I ask whether YANG tokenizes it as a string, a colon, and a
string.

Looking at the beginning of 6.1.3, it doesn't appear that an unquoted
string is forbidden from containing a colon.

I think that the underlying problem is that I'm not clear on what gets
tokenized as an unquoted string.

> > -- it must be an unquoted string.
> > 
> >    If a double-quoted string contains a line break followed by space or
> >    tab characters that are used to indent the text according to the
> >    layout in the YANG file, this leading whitespace is stripped from the
> >    string, up to and including the column of the double quote character,
> >    or to the first non-whitespace character, whichever occurs first.  In
> >    this process, a tab character is treated as 8 space characters.
> > 
> > This description isn't quite careful enough.  Better:
> > 
> >    If a double-quoted string contains a line break followed by space or
> >    tab characters, an initial part of this whitespace is removed from the
> >    string.  The amount removed is the longest prefix whose width is no
> >    larger than the width of the prefix of Yang source line containing
> >    the opening double quote character of the string to and including the
> >    opening double quote character.  For this purpose, the width of a
> >    tab character is 8 and the width of any other character is 1.
> > 
> > This does assume that all tabs are considered to have width 8, that
> > is, tabs do not have the usual semantics of "advance to the next
> > column that is divisible by 8".  That will sometimes cause unexpected
> > results, e.g., if some source lines start with SPC TAB.  (Consider
> > that whitespace before a line break is removed, which suggests the
> > intention is that the value of the string should depend only on its
> > visual appearance.)
> > 
> > Also, we're using the convention that "whitespace" does NOT include CR
> > or LF, which is not always how the term is used.  Perhaps a definition
> > of "whitespace" should be put in section 3.
> > 
> > There is also the special case:
> > 
> >    SPC " LF
> >    TAB x "
> > 
> > Is the initial TAB of the second line to be removed or not?  There is
> > no whitespace removal in the second line that will exactly reach the
> > opening double quote.  As I've written it, the TAB is not removed.

Don't forget this ugly special case.

> >    Within a double-quoted string (enclosed within " "), a backslash
> >    character introduces a special character, which depends on the
> >    character that immediately follows the backslash:
> > 
> > s/introduces a special character/introduces a representation of a
> > special character/
> 
> Hmm.  I think the original text is correct.  In the string "x\ny", the
> backslash introduces the LF character into the string.  What is the
> representation of LF that it would introduce?

I would call the character pair \n a "representation" of LF, and the
first character of that pair, \, "introduces" the representation, in the
sense "to make (something) known by formal announcement or
recommendation", because it is the distinctive first character of the
representation.  There may be an ambiguity in that "introduce" can also
be used to mean "to add (something) to a system, a mixture, or a
container", in this case, "to put a newline character into the string".

> > Verify that CR cannot be specified by an escape.
> 
> This is correct.  I can see that it would make sense to allow it, but
> I am not sure it is necessary.

I agree.  I just wanted to verify that it was not omitted from the text
by accident.

> >    If a quoted string is followed by a plus character ("+"), followed by
> >    another quoted string, the two strings are concatenated into one
> >    string, allowing multiple concatenations to build one string.
> > 
> > Are whitespace, line endings, or comments allowed between the quoted
> > strings and the "+"?
> 
> Yes.  The normal usage of "+" is of course to split a long string to
> several lines.
> 
> Maybe we can add a new sentence after the one above:
> 
>    Whitespace, line breaks, and comments are allowed between the
>    quoted strings and the plus character.

Yes.  It's fairly obvious that you want this rule, but since this part
of the text concerns tokenization (as opposed to statement syntax), the
reader can't assume that the context of this discussion assumed
non-significant tokens have been ignored/removed.

> > - section 6.3.1
> > 
> >    The processing of extensions depends on whether support for those
> >    extensions is claimed for a given YANG parser or the tool set in
> >    which it is embedded.  An unsupported extension, appearing in a YANG
> >    module as an unknown-statement (see Section 14) MAY be ignored in its
> >    entirety.  Any supported extension MUST be processed in accordance
> >    with the specification governing that extension.
> > 
> > This allows a loophole, where an implementation can not claim support,
> > but then not ignore the extension.  I think you want to say "An
> > unsupported extension ... MUST be ignored in its entirety."
> 
> No; this would be up to the implementation.
> 
> > (See also
> > 7.20.1, which implies that an unsupported *feature* must be
> > ignored.) If you really mean "MAY", what are the limits regarding what the
> > server can do?
> 
> Up to the implementation.

It might be worth warning the reader if this sort of partial
implementation is allowed.  OTOH, perhaps that is understood in the
network management world.

> > - section 7.5.7
> > 
> > I suspect that child elements can be omitted if they're not mandatory,
> > but their order need not match the order in the schema.
> 
> Not all payloads must contain mandatory nodes; e.g. if you do an
> edit-config to remove a single optional leaf in a list entry, you
> don't have to repeat all mandatory nodes.

Aaaaah, yes, "mandatory" only applies to the validation check on the
configuration tree sitting in the server, not the XML encodings in
NETCONF operations.  That's why 7.6.5 says that the mandatory constraint
on a leaf "is enforced according to the rules in Section 8".

> > But it's not clear what the whole set of situations is that should be
> > forbidden.  For instance, this should work:
> > 
> >      typedef xyz {
> >        type enumeration {
> > 	 enum blue { if-feature blue; }
> > 	 ...
> >        }
> >      }
> > 
> >      leaf color {
> >        if-feature blue;
> >        type xyz;
> >        default blue;
> >      }
> > 
> > Whereas this won't:
> > 
> >      typedef xyz {
> >        type enumeration {
> > 	 enum blue { if-feature blue; }
> > 	 ...
> >        }
> >      }
> > 
> >      leaf color {
> >        // No if-feature here.
> >        type xyz;
> >        default blue;
> >      }
> > 
> > Is this rule only meant to cover the situation where the leaf's type
> > is an "in-line" enum and the particular enum value has an if-feature?
> 
> Good point.  Yes, the first example should be valid.  Another valid
> example would be:
> 
>     container colors {
>       if-feature blue;
>       leaf color {
>         type xyz;
>         default blue;
>       }
>     }
> 
> Maybe:
> 
> OLD:
> 
>   The definition of the default value MUST NOT be marked with an
>   "if-feature" statement.
> 
> NEW:
> 
>   If the definition of the default value is conditional based on one or
>   more features (see ^if-feature^), then the leaf node MUST
>   also be conditional based on at least the same set of features.
> 
> (modelled after the text in 9.9)
> 
> I'll start a separate thread for this issue on the ML.

That would be good.  (I think I getting in over my depth on this one.)

> > - section 7.7.2
> > 
> > It appears to be assumed that the server's behavior is the same if (1)
> > a leaf-list node is specified with zero values, and (2) if the
> > leaf-list node is absent and has no default values.
> > 
> >    Otherwise, if the leaf-list's type has
> >    a default value, and the leaf-list does not have a "min-elements"
> >    statement with a value greater than or equal to one, then the leaf-
> >    list's default value is the type's default value.  In all other
> >    cases, the leaf-list does not have any default values.
> > 
> > I think it would help to s/the type's default value/one instance of
> > the type's default value/.
> 
> I don't understand why this is better?

If I have an integer leaf, then values of the leaf are integers and it's
proper to say that the default value of the leaf is 1.  But if I have an
integer leaf-list, the values of the leaf-list are sequences of
integers, and it's not quite proper to say that the default value of the
leaf-list is the integer 1; properly said, the default value is a
sequence containing one integer, which integer is 1 -- a sequence
containing one item is not the same as the one item.

> > Is the final condition correct?  E.g., if the leaf-list's type has a
> > default value, and it has a min-elements with value 2, then the
> > leaf-list has no default values
> 
> Correct.
> 
> > -- which is invalid.
> 
> I don't understand what you mean?  An exmaple is this:
> 
>   typedef foo {
>     type int32;
>     default 42;
>   }
> 
>   leaf-list bar {
>     type foo;
>     min-elements 1;
>   }
> 
> In this example, "bar" doesn't have a default value - since
> min-elements means that the user MUST provide at least one value, and
> the default value is only used if no value has been provided.

Let me run though the cases and you can check that I understand them
correctly:

   leaf-list bar {
     type foo;
   }
   -or-
   leaf-list bar {
     type foo;
     min-elements 0;
   }

The default value is one instance of 42.  If the data tree doesn't
supply a value, the effect is the same as 42.

   leaf-list bar {
     type foo;
     min-elements 1;
   }

There is no default value.  If the data tree doesn't supply a value,
then no values are implied.  But that violates the restriction, so the
data tree must supply one or more values -- if there are no values, that
violates the restriction and the data tree is invalid.

Am I correct?

> > - section 7.7.7.1
> > 
> >    The entries in the list are sorted according to an order determined
> >    by the system.  The "description" string for the list may suggest an
> >    order to the server implementor.  If not, an implementation is free
> >    to sort the entries in the most appropriate order.
> > 
> > This is mealy-mouthed about what is required and what is recommended.
> > Better would be to omit "If not, an implementation is free to sort the
> > entries in the most appropriate order."
> 
> I think the last sentence makes it clear that there you cannot assume
> anything about the order, e.g., that a list that has an int32 as the
> key is sorted in numerical order.

I guess what is bothering me is "appropriate", which to me implies that
there is some standard of appropriateness.  I think I would prefer "to
sort the entries in any order".

Actually, there is a somewhat subtle problem:  If I say "the system can
sort them any way it wants", I am asserting that *there is a sorting
order*.  Which means that if value A is put before value B at one time,
then if values A and B are in the list at some other time, A will
precede B.

I think the way to remove that implication is to replace "sort" with
"order" -- a change which you devised for 7.7.7.2, I see:

    The entries in the list are ordered as determined by the system.
    The "description" string for the list may suggest an order to the
    server implementor.  But an implementation is free to sort the
    entries in any other manner.

> > - section 7.7.7.2
> > 
> >    The entries in the list are sorted according to an order defined by
> >    the user.  This order is controlled by using special XML attributes
> >    in the  request.
> > 
> > Actually, the entries aren't "sorted", as there is no requirement that
> > any particular set of values always has a particular order; the user
> > can insert 1, 2, 3 at one time, and 3, 2, 1 at another.  The correct
> > meaning is splicing these two sentences:
> > 
> >    The user orders entries in the list by using special XML attributes
> >    in the  request.
> 
> I prefer to keep the second sentence, and actually modify it to be:
> 
>   In NETCONF, this order is controlled by using special XML attributes
>   in the  request.

Ah, yes, of course that only applies in NETCONF.

> Would it help to s/sorted/ordered/ in the first sentence?

Yes, that is a definite improvement.

> > - section 7.9.5.  XML Encoding Rules
> > 
> >    The choice and case nodes are not visible in XML.
> > 
> > Use this sort of statement for lists and leaf-lists, which have no
> > visible XML for the lists as a whole.
> 
> The current text says:
> 
>   A list is encoded as a series of XML elements, one for each entry in
>   the list.
> 
> I think this text is clear.  I think it might be a bit confusing to
> say that a list node is not visible in the XML - it is visible, per
> entry.

My difficulty is that by default, I would expect that XML representing a
"list of things" would have a pattern like

    
        thing
        thing
        thing
    

or perhaps 

    
        ...
        ...
        ...
    
       
whereas Yang uses

    ...
    ...
    ...

that is, there is an element for each list item, but not one for the
list as a whole.  I don't know why I expect there to be an XML element
that wraps the whole list, I suspect it is from my background in
programming language theory.  OTOH, YANG seems to use the opposite
convention of often avoiding XML elements to wrap aggregate types as a
whole, and only having XML elements for the component data items.
(Although containers have enwrapping XML elements.)

Perhaps this revision would work:

   A list is encoded as a series of XML elements, one for each entry in
   the list.  There is no XML element surrounding the list as a whole.

> > - section 7.10
> > 
> >    The "anydata" statement is used to represent an unknown set of nodes
> >    that can be modelled with YANG, except anyxml, ...
> > 
> > What is the practical consequence of this restriction?  It's not at
> > all clear to me which chunks of XML could be modelled with Yang and
> > which could not.
> 
> In practice, this means that if you see an instance of anydata, there
> is a YANG model behind that chunk somewhere, although you might not
> know what it is.  In an implementation it means you can use your
> normal parser (which maybe doesn't handle mixed content and processing
> instructions etc).

Ah, yes.  That last sentence is the practical consequence, and yes, it's
directly implied by the text in the draft.

> > - section 7.12
> > 
> >    A grouping is like a "structure" or a "record" in conventional
> >    programming languages.
> > 
> > Add, "... though no grouping node exists in the XML."
> 
> Since we try to decouple the defintion of the language from the
> encodings, I'd prefer to not add this.

Yes...  What I'm talking about is actually the XML encoding of a uses
statement.  7.13.3 specifies by omission that the XML for the set of
nodes in the grouping is not wrapped in a "grouping" element.
 
> > - section 7.18
> > 
> > It would help to insert a discussion of the global purpose and use of
> > identities.  In particular, what things can refer to them?  It looks
> > like only identityref leafs can do so, but I could easily be wrong.
> > Also, more discussion in the example (7.18.3) would be helpful.
> > 
> >    The "identity" statement is used to define a new globally unique,
> >    abstract, and untyped identity.  Its only purpose is to denote its
> >    name, semantics, and existence.
> > 
> > The two uses of "its" in the second sentence are ambiguous.  I think
> > you mean "The statement's only purpose is to denote the identity's
> > name, semantics, and existence."
> 
> No, rather "The identity's only purpose...".  The point is that this
> just an abstract concept.

OK, but I think you may want to replace the first "Its" with "The
identity's".

> > - section 7.21.4
> > 
> >    The "reference" statement takes as an argument a string ...
> > 
> > Perhaps s/a string/a human-readable string/.
> 
> "string" refers to the YANG token "string".  The same wording is used
> across the document for all arguments.

I was thinking that it is a string, but in this particular case, it is
supposed to be human-readable, whereas strings in other contexts aren't
expected to be.

> > - section 7.21.5
> > 
> > Note that if a data definition has both an "if-feature" and a "when",
> > then the "if-feature" is tested first.
> > 
> >    If the XPath expression references any node that also has associated
> >    "when" statements, these "when" expressions MUST be evaluated first.
> >    There MUST NOT be any circular dependencies in these "when"
> >    expressions.
> > 
> > I think this could be better phrased:
> > 
> >    If the XPath expression references any node that also has
> >    associated "when" statements, then the "when" expressions of the
> >    referenced nodes MUST be evaluated first.  There MUST NOT be any
> >    circular dependencies among "when" expressions.
> 
> Ok to the last sentence.  Do you think that the word "these" in the
> first sentence is ambigious?

I must have thought it was unclear when I read it, otherwise I would not
have suggested changing it.  But reading it again, I think that there is
no ambiguity.  Perhaps it would be a little clearer to use 'those "when"
expressions' rather than 'these "when" expressions'.  (I can't explain
clearly why "those" seems less ambiguous than "these".)

> > - section 9.9
> > 
> >    The leafref type is used to declare a constraint on the value space
> >    of a leaf, based on a reference to a set of leaf instances in the
> >    data tree.  The "path" substatement (Section 9.9.2) selects a set of
> >    leaf instances, and the leafref value space is the set of values of
> >    these leaf instances.
> > 
> > The first sentence isn't quite right.  Perhaps:
> > 
> >    The value space of a leaf with leafref type is one of the values of
> >    a set of leaf instances in the data tree.  The "path" substatement
> >    (Section 9.9.2) selects the set of leaf instances, and the leafref
> >    value space is the set of values of these leaf instances.
> 
> The point is that "leafref" introduces a constraint on valid data.
> In for example the candidate configuration of NETCONF, it is ok if a
> leafref leaf points to something that doesn't exist.  However it must
> exist at commit-time.  See below.

Let me think this through...  Really, the leafref *type* has the same
set of values as the type of the nodes its path selects (let's call it
the base type), but it also has an attached constraint (which must be
satisfied at the times specified in section 8).  In particular, you do
not expect the constraint to be satisfied within the data tree of an
RPC.

By implication, the leafref's value is considered to be a pointer to a
particular leaf instance, the one with the matching value.  But that
idea is not embedded in the Yang semantics of leafref types in any way
(other than the output of the deref function), so the fact that there
might be more than one matching leaf instance does not matter.

As stated in 9.9.4 and 9.9.5, the lexical representations of its values
are the same as those of the referenced nodes.

How is the leafref's value compared to the values of the referenced
nodes?  I can see that question getting ugly for the more complex types
(e.g., anyxml) which do not have canonical forms.  I suspect the
intention is that values are equal if they have the same canonical form
-- and that only base types with canonical forms are allowed.

If I'm reading correctly, the constraint is only applied to
configuration leafs which have require-instance=true.  Any other leafref
leaf has no constraint (though its values are required to be compatible
with the base type).  I'm not sure I'm reading this correctly, though.
But look at the second paragraph of section 9.9:

   If the leaf with the leafref type represents configuration data, and
   the "require-instance" property (Section 9.9.3) is "true", the leaf
   it refers to MUST also represent configuration.  Such a leaf puts a
   constraint on valid data.  All such nodes MUST reference existing
   leaf instances or leafs with default values in use (see Section 7.6.1
   and Section 7.7.2) for the data to be valid.  This constraint is
   enforced according to the rules in Section 8.

The second sentence starts "Such a leaf puts a constraint ...".  But
"such a leaf" must mean "the leaf with the leafref type represents
configuration data, and the "require-instance" property (Section 9.9.3)
is "true"".  I suspect that is not the intended meaning.

In 9.9.2,

   The "path" expression evaluates to a node set consisting of zero,
   one, or more nodes.  If the leaf with the leafref type represents
   configuration data, this node set MUST be non-empty.

This appears to be a constraint that applies even if
require-instance=false.  Is that correct?  If so, it represents a
constraint that is independent of the main constraint (that there is a
leaf with a matching value), because that constraint is only effective
if require-instance=true.  That probably should be mentioned in 9.9
along with the other constraint.

> > - section 9.9.3
> > 
> >    If "require-instance" is "true", it means that the instance being
> >    referred MUST exist for the data to be valid.  This constraint is
> >    enforced according to the rules in Section 8.
> > 
> >    If "require-instance" is "false", it means that the instance being
> >    referred MAY exist in valid data.
> > 
> > What does "the instance being referred" mean?  Perhaps you meant "the
> > instance being referred to"?
> 
> Yes.

I think this could be made clearer, because it's not quite right to say
that "the XXX does not exist" -- if it doesn't exist, there is no "the
XXX".  Perhaps,

    If "require-instance" is "true", it means that the value of the
    leafref or instance-identifier leaf must equal the value of one of
    the leafs in the set that the "path" expression evaluates to.  This
    constraint is enforced according to the rules in Section 8.
 
    If "require-instance" is "false", it means that the value of the
    leafref or instance-identifier leaf is not constrained in this way.

Though this constraint only applies if the leafref leaf is configuration
data (per section 9.9), which limitation needs to be stated in this text
also.

There seem to be significant differences between the application of
require-instance to leafref types and instance-identifier types.  The
general idea is similar, but the specific semantics are different to the
point that the instance-identifier case might require a seperate
statement.

If I understand correctly, require-instance is a restriction, and so can
be applied to a derived type which itself has a require-instance
restriction.  Generally, that sort of restriction requires that the new
restriction is compatible with the old one.  E.g., in 9.2.4:

   If a range restriction is applied to an already
   range-restricted type, the new restriction MUST be equal or more
   limiting, that is raising the lower bounds, reducing the upper
   bounds, removing explicit values or ranges, or splitting ranges into
   multiple ranges with intermediate gaps.

In the case of require-instance, the new restriction should presumably
have the same value as that of the base type.  OTOH, that adds no
expressive power, so perhaps applying a require-instance restriction to
a derived type can be forbidden.  Or perhaps it is allowed to add
require-instance=true to a base type with require-instance=false?  That
override does make the type definition more restrictive, and so is
compatible with the general idea of restrictions on derived types.

OK, now back to what you said:

> Right; so what we want to say is:
> 
>   - the value space is the same as the value space of the referred
>     leaf
> 
>   - there is an additional constraint if require-instance is true that
>     the referred to leaf instance must exist
> 
> How about
> 
> OLD:
> 
>    The leafref type is used to declare a constraint on the value space
>    of a leaf, based on a reference to a set of leaf instances in the
>    data tree.  The "path" substatement (Section 9.9.2) selects a set of
>    leaf instances, and the leafref value space is the set of values of
>    these leaf instances.
> 
>    If the leaf with the leafref type represents configuration data, and
>    the "require-instance" property (Section 9.9.3) is "true", the leaf
>    it refers to MUST also represent configuration.  Such a leaf puts a
>    constraint on valid data.  All such nodes MUST reference existing
>    leaf instances or leafs with default values in use (see Section 7.6.1
>    and Section 7.7.2) for the data to be valid.  This constraint is
>    enforced according to the rules in Section 8.
> 
> NEW:
> 
>    The leafref type is used to declare a constraint on the value space
>    of a leaf, based on a reference to a set of leaf instances in the
>    data tree.  The "path" substatement (Section 9.9.2) is used to refer
>    to another leaf node.  The leafref value space is the value space of
>    this leaf node.
> 
>    If the "require-instance" property is "true", there MUST exist an
>    instance, or a leaf with a default value in use (see Section 7.6.1
>    and Section 7.7.2), of the leaf being referred to with the same value
>    as the leafref value in a valid data tree.
> 
>    If the leaf with the leafref type represents configuration data, and
>    the "require-instance" property (Section 9.9.3) is "true", the leaf
>    it refers to MUST also represent configuration.

I think the first paragraph needs to also say that the leafref type is
sort of a derived type of the type of the leaf node (which is in the
schema).

"If the "require-instance" property is "true", there MUST exist ..." is
really "If the "require-instance" property is "true", the constraint is
that there MUST exist ...".

For section 9.9.6, I think "an existing address of an interface" was
probably meant to be "the address of an existing interface".  Also,
shouldn't there be require-instance restrictions in the example Yang
code?

     container default-address {
       leaf ifname {
         type leafref {
           path "../../interface/name";
>>>	   require-instance true;
         }
       }
       leaf address {
         type leafref {
           path "../../interface[name = current()/../ifname]"
              + "/address/ip";
>>>	   require-instance true;
         }
       }
     }

> This needs to be verified on the ML (I'll start a separate thread for
> this).

Yes...  I get the feeling that I still don't have an accurate
understanding of what is intended.

> >    In the XML encoding, a value representing a union data type is
> >    validated consecutively against each member type, in the order they
> >    are specified in the "type" statement, until a match is found.  The
> >    type that matched will be the type of the value for the node that was
> >    validated.
> > 
> > I think a distinction needs to be made here between generating XML and
> > interpreting XML:
> > 
> >    When generating an XML encoding, a value is encoded according to
> >    the rules of the member type to which the value belongs.  When
> >    interpreting an XML encoding, a value is validated consecutively
> >    against each member type, in the order they are specified in the
> >    "type" statement, until a match is found.  The type that matched
> >    will be the type of the value for the node that was validated, and
> >    the encoding is interpreted according to the rules for that type.
> 
> Yes, better, but I don't understand what value the last part of the
> last sentence adds?

It makes explicit how the value is to be extracted from the encoding.

> > - section 10.3.1
> > 
> >    If the first argument node is of type leafref, the function returns a
> >    node set that contains the nodes that the leafref refers to.
> > 
> > I *think* that this means the set of nodes that the leafref's XPath
> > selects, but a plausible alternative is the subset of those nodes
> > which have the same value as the leafref does.  This hinges on the
> > meaning of "the leafref refers to a node", which isn't defined
> > unambiguously in section 9.9.
> 
> It is the latter.  Howabout:
> 
> NEW:
> 
>    If the first argument node is of type leafref, the function returns
>    a node set that contains the nodes that the leafref refers to.
>    Specifically, this set contains the nodes selected by the leafref's
>    "path" statement (Section 9.9.2) that has the same value as the
>    first argument node.

Yes.  (Although "that has the same value" should be "that have the same
value".)

> >    instance-identifier-specification =
> >                          [require-instance-stmt]
> > 
> > Why is require-instance-stmt in [...]?  The only use of
> > instance-identifier-specification is in type-body-stmts, and the only
> > use of type-body-stmts is in type-stmt, where it is in [...].  Compare
> > with numerical-restrictions:
> > 
> >    numerical-restrictions = range-stmt
> > 
> > --
> > 
> >    binary-specification = [length-stmt]
> 
> You're right that it isn't necessary.  However, imo it is more clear;
> in an instance-identifier spec require-instance is optional, but the
> only numerical-restriction is range.

As far as I can see, numerical-restrictions, decimal64-specification,
and numerical-restrictions are to be used similarly, as they are
alternatives of type-body-statements.  But there seems to be no
uniformity as to whether one of these alternatives can be empty:

   numerical-restrictions = range-stmt

   instance-identifier-specification =
                         [require-instance-stmt]

   decimal64-specification = ;; these stmts can appear in any order
                             fraction-digits-stmt
                             [range-stmt]

It seems to me that whatever reasoning applies to whether range-stmt is
optional within numerical-restrictions applies to require-instance-stmt
within instance-identifier-specification.

> > Similarly.
> > 
> >    quoted-string       = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)
> > 
> >    string              = < an unquoted string as returned by >
> >                          < the scanner, that matches the rule >
> >                          < yang-string >
> > 
> > The handling of "string" is hard to follow and/or inexact.  First, we
> > need a term for the "value" of a string written in Yang source, so we
> > can say
> > 
> >    prefix-arg-str      = < a string whose ??? matches the rule >
> >                          < prefix-arg >
> > 
> > The text that is now used is not too difficult to understand, but it's
> > inexact and makes it hard to write specifications about how the value
> > is determined.
> 
> It's not clear to me which problem you want to solve, and also it's
> not clear exactly what you propose.

I think the problem is that I don't see the rule for extracting unquoted
strings from the Yang source.  Certainly, not all yang-string's can be
written directly in the source as unquoted strings, not even all those
that satisfy the constraint of 6.1.3, "If a string contains any space,
tab, or newline characters, a single or double quote character, a
semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*",
or "*/"), then it MUST be enclosed within double or single quotes."

E.g., the null string matches yang-string, but it can't be written as an
unquoted string at all (else tokenizing any source would be ambiguous).
Similarly, mod:ext matches yang-string and is not required to be quoted
by 6.1.3, but it seems that those characters in the source are not
intended to be tokenized as a string.

> > (Also, there seem to be too many <...>, dividing the narrative text
> > into two parts.  The natural way to write it would be:
> > 
> >    prefix-arg-str      = < a string whose ??? matches the rule
> >                            prefix-arg >
> 
> Agreed, but LF isn't allowed in prose-val in ABNF (see RFC 5234).

Ah, I hadn't known that <...> was a defined usage.

> > We need a production that tells exactly the syntax of "an unquoted
> > string as return by the scanner".
> > 
> > We also need productions for quoted strings.  I can reconstruct these:
> > 
> >    quoted-string       = (single-quoted-string / double-quoted-string)
> >    		         *(optsep "+" optsep
> >                              (single-quoted-string / double-quoted-string))
> > 
> >    single-quoted-string = SQUOTE *(yang-char excluding "'") SQUOTE
> > 
> > (I don't know a good way to exclude one character from a character set
> > in ABNF.)
> > 
> >    double-quoted-string = DQUOTE *dq-char DQUOTE
> > 
> >    dq-char = yang-char excluding BACKSLASH and DQUOTE /
> >              BACKSLASH ( "n" / "t" / DQUOTE / BACKSLASH )
> > 
> > Verify that "optsep" is what is allowed to appear around "+".
> > 
> > Needs a comment pointing to Section 6.1.3 as telling how to interpret
> > quoted-strings.

The current ABNF doesn't allow for "+" for joining quoted strings.
Also, it doesn't show that \" can be included in a double quoted string
to include a literal ", and allows the string contents to continue --
the current ABNF "DQUOTE string DQUOTE" matches "abcd\", despite that
the latter is not a proper double-quoted string.

Dale


From nobody Thu May 26 06:11:58 2016
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 60D1F12D551 for ; Thu, 26 May 2016 06:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 V4cxZNO_JXA8 for ; Thu, 26 May 2016 06:11:53 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510E412D0FA for ; Thu, 26 May 2016 06:11:53 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 18BC0A85; Thu, 26 May 2016 15:11:52 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ZsBwQLegNj0I; Thu, 26 May 2016 15:11:34 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 26 May 2016 15:11:51 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4748B20060; Thu, 26 May 2016 15:11: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 N-32A1oKn9M2; Thu, 26 May 2016 15:11:49 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 708FB20058; Thu, 26 May 2016 15:11:48 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 60AFB3AF4F3D; Thu, 26 May 2016 15:11:47 +0200 (CEST)
Date: Thu, 26 May 2016 15:11:46 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20160526131146.GA13771@elstar.local>
Mail-Followup-To: Martin Bjorklund , ichen@kuatrotech.com, netmod@ietf.org
References:  <20160419182250.GA3771@elstar.local>  <20160420.164755.1169712416411367784.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160420.164755.1169712416411367784.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: ichen@kuatrotech.com, netmod@ietf.org
Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 13:11:56 -0000

On Wed, Apr 20, 2016 at 04:47:55PM +0200, Martin Bjorklund wrote:
> 
> If you really want to limit it to YANG module namespaces, maybe it
> should be called urn:yang-rdns:  or something.

I tend to agree, if this is YANG specific, it should say so. Perhaps it
should be:

  "rdns" URN       ::= urn:yang::

An example would be:

  urn:yang:com:acme:acme-interfaces

/js

PS: This is not as 'compact' as a solution where the module name would
    include the rdns part and thus we would not need to have the
     part, i.e., we would have just

      "rdns" URN       ::= urn:yang:

    which gives us

      urn:yang:org-acme-interfaces

    and this could even make the explicit namespace definition in YANG
    modules go away (with the default that the module org-acme-foo uses
    the namespace URN urn:yang:org-acme-foo).

-- 
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 May 26 06:14:49 2016
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 119AB12D54C for ; Thu, 26 May 2016 06:14:49 -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 7SvJMwdpn4AT for ; Thu, 26 May 2016 06:14:47 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 6DED012D1A7 for ; Thu, 26 May 2016 06:14:47 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id x189so75801509ywe.3 for ; Thu, 26 May 2016 06:14:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=U8JOfC3OQBLqqttuVAJ6fDZvet1y6FdVpGACHAA3Qjk=; b=hUceZbu8aCWNMr67B3WBpEHQFgoBAdzJL3a/qZwmk5QOxR7O/WNrx8Nv+5cEIw6rD9 xg+13b0ZiZJF6W9jgYFLohpl4dmHJL9t70xwfnef7xFA5XbHfs1XzHkIcc58vTmjJikq JgVjtF5dbOWXCEBe7UaEai2OlROdhj/5tlGQBx+v6jJhER49z7ruvjqtlhk9yWwFoUXx XbMeM1sKY2Qv8WFdzsaC4vz4noHUfmP0wLdKmE3DcmTTiIloxuJ3xop8G3YdkUUoykhH ZFnpyEMp7hMV0PxzS3kvXE6p5zxhgLm/FjjgFevy56vFdltcNnzCipu4t+0Vwdj8xSWK pZMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=U8JOfC3OQBLqqttuVAJ6fDZvet1y6FdVpGACHAA3Qjk=; b=EfzWY832QNXwaNlk6Snjz9/K6aCAuW32J0UK9p3A2ydKDeC2eNI9G36ozajmcm3t+m eDZ2/3xKmG2TM2noWm9e/4nanSaShf38QeQBC3SXFJff/pphSvQF533KrQD4Y27TVqrj MUZqWMm+AG1X/sLcH/zSQLE3vQ27dUzBEyOaoJeBDH50i9jkWwUm+QC6aCHIT9z/ytpO WY2cNL/rqCY9ZUFILBPSdH1Ox6q2j4Wy9/4V61dKaww6LjyggYrDpUGbaMPGr4kGrGN9 QPHgffJITItBB9OX0N2/rrsvtscMaOBdfZnLBld9AXnDwZaCmzpbm4tS/7f5x26iB184 b2vw==
X-Gm-Message-State: ALyK8tLpY3X+J0stw1/WnIAqtIp/FwBg5FAA/+Txzdp/Pey1c177SEQ4J1TPkbhHgI1bQxNrg12HaDd2sJOMIw==
MIME-Version: 1.0
X-Received: by 10.13.215.149 with SMTP id z143mr5482605ywd.166.1464268486630;  Thu, 26 May 2016 06:14:46 -0700 (PDT)
Received: by 10.37.44.199 with HTTP; Thu, 26 May 2016 06:14:46 -0700 (PDT)
Date: Thu, 26 May 2016 06:14:46 -0700
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c07621e009f220533be9343
Archived-At: 
Subject: [netmod] NP-container and min-elements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 13:14:49 -0000

--94eb2c07621e009f220533be9343
Content-Type: text/plain; charset=UTF-8

Hi,

Our compiler generates a "top-level mandatory" warning for something
like this:

   container top {
     list foo {
        min-elements 1;
        ...
      }
   }

A customer is saying this is incorrect.  RFC6020bis is confusing on this
issue.


Terms::

   o  mandatory node: A mandatory node is one of:

      *  A leaf, choice, anydata, or anyxml node with a "mandatory"
         statement with the value "true".

      *  A list or leaf-list node with a "min-elements" statement with a
         value greater than zero.

      *  A container node without a "presence" statement, which has at
         least one mandatory node as a child.


7.7.5.  The min-elements Statement

   The "min-elements" statement, which is optional, takes as an argument
   a non-negative integer that puts a constraint on valid list entries.
   A valid leaf-list or list MUST have at least min-elements entries.

   If no "min-elements" statement is present, it defaults to zero.

 *  The behavior of the constraint depends on the type of the leaf-list's
   or list's closest ancestor node in the schema tree that is not a non-
   presence-container (see Section 7.5.1):
*
   o  If this ancestor is a case node, the constraint is enforced if any
      other node from the case exists.

   o  Otherwise, it is enforced if the ancestor node exists.


8.1:

  o  The "mandatory" constraint is enforced for leafs and choices,
      unless the node or any of its ancestors has a "when" condition or
      "if-feature" expression that evaluates to "false".

   o  The "min-elements" and "max-elements" constraints are enforced for
      lists and leaf-lists, unless the node or any of its ancestors has
      a "when" condition or "if-feature" expression that evaluates to
      "false".

In this example, there is no ancestor node (except docroot) that is not an
NP-container. The "mandatory" term and sec. 7.7.5 implies that the
warning is correct. Sec. 8.1 implies the ancestor data node has to exist for
min-elements to be enforced. Is the docroot the ancestor node in this
example?

The transparent nature of NP-containers has always confused people.
It is not that obvious that they are so very different than all other node
types.


Andy

--94eb2c07621e009f220533be9343
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

Our compiler generates a "top-=
level mandatory" warning for something
like this:
=

=C2=A0 =C2=A0container top {
=C2=A0 =C2=A0 =C2=A0l=
ist foo {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 min-elements 1;
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 }
=
=C2=A0 =C2=A0}

A customer is saying this is incorr=
ect.=C2=A0 RFC6020bis is confusing on this issue.

=

Terms::
   o  mandatory node: A mandatory node is o=
ne of:

      *  A leaf, choice, anydata, or anyxml node with a "mandatory&quo=
t;
         statement with the value "true".

      *  A list or leaf-list node with a "min-elements" statement=
 with a
         value greater than zero.

      *  A container node without a "presence" statement, which h=
as at
         least one mandatory node as a child.


7.7.5.  The min-elements Statement

   The "min-elements" statement, which is optional, takes as an a=
rgument
   a non-negative integer that puts a constraint on valid list entries.
   A valid leaf-list or list MUST have at least min-elements entries.

   If no "min-elements" statement is present, it defaults to zero=
.

   The behavior of the constraint depends on the type of the leaf-list&#=
39;s
   or list's closest ancestor node in the schema tree that is not a non=
-
   presence-container (see Section 7.5.1):

   o  If this ancestor is a case node, the constraint is enforced if any
      other node from the case exists.

   o  Otherwise, it is enforced if the ancestor node exists.

8.1:

  o  The "mandatory"=
; constraint is enforced for leafs and choices,
      unless the node or any of its ancestors has a "when" condit=
ion or
      "if-feature" expression that evaluates to "false"=
.

   o  The "min-elements" and "max-elements" constraints=
 are enforced for
      lists and leaf-lists, unless the node or any of its ancestors has
      a "when" condition or "if-feature" expression tha=
t evaluates to
      "false".

In this example, there is no ancestor node (except docroot=
) that is not an
NP-container. The "mandatory" term and=
 sec. 7.7.5 implies that the
warning is correct. Sec. 8.1 implies=
 the ancestor data node has to exist for
min-elements to be enfor=
ced. Is the docroot the ancestor node in this example?

=

The transparent nature of NP-containers has always confused people.
It is not that obvious that they are so very different than all oth=
er node types.


Andy

<=
/div>





--94eb2c07621e009f220533be9343--


From nobody Thu May 26 06:26:33 2016
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 B9E3012D5BE for ; Thu, 26 May 2016 06:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 xdIeHSmMSavR for ; Thu, 26 May 2016 06:26:28 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 26B0A12D54C for ; Thu, 26 May 2016 06:26:28 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id B5AD21AE039E; Thu, 26 May 2016 15:26:25 +0200 (CEST)
Date: Thu, 26 May 2016 15:26:46 +0200 (CEST)
Message-Id: <20160526.152646.615068717107290692.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] NP-container and min-elements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 13:26:31 -0000

Andy Bierman  wrote:
> Hi,
> 
> Our compiler generates a "top-level mandatory" warning for something
> like this:
> 
>    container top {
>      list foo {
>         min-elements 1;
>         ...
>       }
>    }
> 
> A customer is saying this is incorrect.  RFC6020bis is confusing on this
> issue.
> 
> 
> Terms::
> 
>    o  mandatory node: A mandatory node is one of:
> 
>       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
>          statement with the value "true".
> 
>       *  A list or leaf-list node with a "min-elements" statement with a
>          value greater than zero.
> 
>       *  A container node without a "presence" statement, which has at
>          least one mandatory node as a child.

With this definition, I think it is clear that 'top' is a "mandatory
node".  What is confusing about this?



/martin



> 
> 
> 7.7.5.  The min-elements Statement
> 
>    The "min-elements" statement, which is optional, takes as an argument
>    a non-negative integer that puts a constraint on valid list entries.
>    A valid leaf-list or list MUST have at least min-elements entries.
> 
>    If no "min-elements" statement is present, it defaults to zero.
> 
>  *  The behavior of the constraint depends on the type of the leaf-list's
>    or list's closest ancestor node in the schema tree that is not a non-
>    presence-container (see Section 7.5.1):
> *
>    o  If this ancestor is a case node, the constraint is enforced if any
>       other node from the case exists.
> 
>    o  Otherwise, it is enforced if the ancestor node exists.
> 
> 
> 8.1:
> 
>   o  The "mandatory" constraint is enforced for leafs and choices,
>       unless the node or any of its ancestors has a "when" condition or
>       "if-feature" expression that evaluates to "false".
> 
>    o  The "min-elements" and "max-elements" constraints are enforced for
>       lists and leaf-lists, unless the node or any of its ancestors has
>       a "when" condition or "if-feature" expression that evaluates to
>       "false".
> 
> In this example, there is no ancestor node (except docroot) that is not an
> NP-container. The "mandatory" term and sec. 7.7.5 implies that the
> warning is correct. Sec. 8.1 implies the ancestor data node has to exist for
> min-elements to be enforced. Is the docroot the ancestor node in this
> example?
> 
> The transparent nature of NP-containers has always confused people.
> It is not that obvious that they are so very different than all other node
> types.
> 
> 
> Andy


From nobody Thu May 26 06:29:39 2016
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 A86B212D184 for ; Thu, 26 May 2016 06:29:37 -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 0AEoGCqMdHEs for ; Thu, 26 May 2016 06:29:36 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 DF71A12D615 for ; Thu, 26 May 2016 06:29:35 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id x189so76203086ywe.3 for ; Thu, 26 May 2016 06:29:35 -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:date:message-id:subject:from:to :cc; bh=Dj8jAGz2oaMjIJUFAahYQKK65D/cZFXk411BVFOYt+s=; b=bydXfoEb1FhQ3Jk+pe2rYh1uS0jiDE495N8lV0sW89ZUbtM39n4LGbBeKnzJLDZavN bT6UueOknyV79EAAjTgQuStw38FRhlAdXtb4fc2QXapPvY3thofhzv2an3twHZa7Auhi 4/LGBrUuaqa2q4H/01xV2kyF/U89311QGin5g66B8BXDvZ9yIyrJgqMHGydUFoCrBdk0 Bd+/Ks7HDf8ByF/SPqsfCNQM/lXQsQSQ0EM7yvpYwPYf84V9Hf5xeTC4xMwfqD0FomIN 5d9hhxxcMDtV+2ez+bP+E7eQQiUbzdrqfZoSyObLULuy7xSuuEJsSX3DfZ6Mcnf4jJAy ZSEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Dj8jAGz2oaMjIJUFAahYQKK65D/cZFXk411BVFOYt+s=; b=a+Zo04OjFxdxYSGMT/OfAEAeszVpTvi0UN51w/23WLuldOE3xEpF9ON9MzvmQQoGnB cQUWBkcnlmzq9ycDw//RP52Xzsr1n6vj1pYVa0MyaeZSjEr+3m3oa95ksC2bahF1zn5p BD8Sg+wFWQ109+1kMIyX2MaKj76Xl3ngLdqoc2ntHr0Zl+vcfonzfgZlIfVhRZWDHYaI kDOhFg/nEzFUghGPFU4U1qT69CMYpkrlGB4xquuD9h5q0FOG/AUHpPLq1+9r34cv6YjR AbUr7wht2FER2Cwo9FKhA+20pbYWiURWoP22XZl7d3bqiRujAqLJpM5Hi87Qh5lnPByR HI8A==
X-Gm-Message-State: ALyK8tJCWIVHdxaSY02hxLMDcpNw8FVvKJR7tSM532oM37voFg2CbLMk/WVhcGCr39NAFDVKkLiPaHLp0eEtNg==
MIME-Version: 1.0
X-Received: by 10.13.202.15 with SMTP id m15mr5376044ywd.259.1464269375190; Thu, 26 May 2016 06:29:35 -0700 (PDT)
Received: by 10.37.44.199 with HTTP; Thu, 26 May 2016 06:29:35 -0700 (PDT)
In-Reply-To: <20160526.152646.615068717107290692.mbj@tail-f.com>
References:  <20160526.152646.615068717107290692.mbj@tail-f.com>
Date: Thu, 26 May 2016 06:29:35 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11481ab6f7165c0533bec7b4
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NP-container and min-elements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 13:29:37 -0000

--001a11481ab6f7165c0533bec7b4
Content-Type: text/plain; charset=UTF-8

On Thu, May 26, 2016 at 6:26 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > Hi,
> >
> > Our compiler generates a "top-level mandatory" warning for something
> > like this:
> >
> >    container top {
> >      list foo {
> >         min-elements 1;
> >         ...
> >       }
> >    }
> >
> > A customer is saying this is incorrect.  RFC6020bis is confusing on this
> > issue.
> >
> >
> > Terms::
> >
> >    o  mandatory node: A mandatory node is one of:
> >
> >       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
> >          statement with the value "true".
> >
> >       *  A list or leaf-list node with a "min-elements" statement with a
> >          value greater than zero.
> >
> >       *  A container node without a "presence" statement, which has at
> >          least one mandatory node as a child.
>
> With this definition, I think it is clear that 'top' is a "mandatory
> node".  What is confusing about this?
>
>
>
This is clear but 7.7.5 is not clear that the docroot is an ancestor data
node.



>
> /martin
>
>
Andy


>
>
> >
> >
> > 7.7.5.  The min-elements Statement
> >
> >    The "min-elements" statement, which is optional, takes as an argument
> >    a non-negative integer that puts a constraint on valid list entries.
> >    A valid leaf-list or list MUST have at least min-elements entries.
> >
> >    If no "min-elements" statement is present, it defaults to zero.
> >
> >  *  The behavior of the constraint depends on the type of the leaf-list's
> >    or list's closest ancestor node in the schema tree that is not a non-
> >    presence-container (see Section 7.5.1):
> > *
> >    o  If this ancestor is a case node, the constraint is enforced if any
> >       other node from the case exists.
> >
> >    o  Otherwise, it is enforced if the ancestor node exists.
> >
> >
> > 8.1:
> >
> >   o  The "mandatory" constraint is enforced for leafs and choices,
> >       unless the node or any of its ancestors has a "when" condition or
> >       "if-feature" expression that evaluates to "false".
> >
> >    o  The "min-elements" and "max-elements" constraints are enforced for
> >       lists and leaf-lists, unless the node or any of its ancestors has
> >       a "when" condition or "if-feature" expression that evaluates to
> >       "false".
> >
> > In this example, there is no ancestor node (except docroot) that is not
> an
> > NP-container. The "mandatory" term and sec. 7.7.5 implies that the
> > warning is correct. Sec. 8.1 implies the ancestor data node has to exist
> for
> > min-elements to be enforced. Is the docroot the ancestor node in this
> > example?
> >
> > The transparent nature of NP-containers has always confused people.
> > It is not that obvious that they are so very different than all other
> node
> > types.
> >
> >
> > Andy
>

--001a11481ab6f7165c0533bec7b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 26, 2016 at 6:26 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> Hi,

>

> Our compiler generates a "top-level mandatory" warning for s=
omething

> like this:

>

>=C2=A0 =C2=A0 container top {

>=C2=A0 =C2=A0 =C2=A0 list foo {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0min-elements 1;

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

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

>=C2=A0 =C2=A0 }

>

> A customer is saying this is incorrect.=C2=A0 RFC6020bis is confusing =
on this

> issue.

>

>

> Terms::

>

>=C2=A0 =C2=A0 o=C2=A0 mandatory node: A mandatory node is one of:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A leaf, choice, anydata, or anyxml n=
ode with a "mandatory"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 statement with the value "true&=
quot;.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A list or leaf-list node with a &quo=
t;min-elements" statement with a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value greater than zero.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A container node without a "pre=
sence" statement, which has at

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 least one mandatory node as a child.=




With this definition, I think it is clear that 'top' is a "man=
datory

node".=C2=A0 What is confusing about this?





This is clear but 7.7.5 is not clear t=
hat the docroot is an ancestor data node.

=C2=A0



/martin



Andy
=C2=A0





>

>

> 7.7.5.=C2=A0 The min-elements Statement

>

>=C2=A0 =C2=A0 The "min-elements" statement, which is optional=
, takes as an argument

>=C2=A0 =C2=A0 a non-negative integer that puts a constraint on valid li=
st entries.

>=C2=A0 =C2=A0 A valid leaf-list or list MUST have at least min-elements=
 entries.

>

>=C2=A0 =C2=A0 If no "min-elements" statement is present, it d=
efaults to zero.

>

>=C2=A0 *=C2=A0 The behavior of the constraint depends on the type of th=
e leaf-list's

>=C2=A0 =C2=A0 or list's closest ancestor node in the schema tree th=
at is not a non-

>=C2=A0 =C2=A0 presence-container (see Section 7.5.1):

> *

>=C2=A0 =C2=A0 o=C2=A0 If this ancestor is a case node, the constraint i=
s enforced if any

>=C2=A0 =C2=A0 =C2=A0 =C2=A0other node from the case exists.

>

>=C2=A0 =C2=A0 o=C2=A0 Otherwise, it is enforced if the ancestor node ex=
ists.

>

>

> 8.1:

>

>=C2=A0 =C2=A0o=C2=A0 The "mandatory" constraint is enforced f=
or leafs and choices,

>=C2=A0 =C2=A0 =C2=A0 =C2=A0unless the node or any of its ancestors has =
a "when" condition or

>=C2=A0 =C2=A0 =C2=A0 =C2=A0"if-feature" expression that evalu=
ates to "false".

>

>=C2=A0 =C2=A0 o=C2=A0 The "min-elements" and "max-elemen=
ts" constraints are enforced for

>=C2=A0 =C2=A0 =C2=A0 =C2=A0lists and leaf-lists, unless the node or any=
 of its ancestors has

>=C2=A0 =C2=A0 =C2=A0 =C2=A0a "when" condition or "if-fea=
ture" expression that evaluates to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0"false".

>

> In this example, there is no ancestor node (except docroot) that is no=
t an

> NP-container. The "mandatory" term and sec. 7.7.5 implies th=
at the

> warning is correct. Sec. 8.1 implies the ancestor data node has to exi=
st for

> min-elements to be enforced. Is the docroot the ancestor node in this<=
br>
> example?

>

> The transparent nature of NP-containers has always confused people.
> It is not that obvious that they are so very different than all other =
node

> types.

>

>

> Andy





--001a11481ab6f7165c0533bec7b4--


From nobody Thu May 26 06:45:56 2016
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 CC78712DB32 for ; Thu, 26 May 2016 06:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 pdwiu9LyqPyy for ; Thu, 26 May 2016 06:45:50 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52D212DEBB for ; Thu, 26 May 2016 06:44:06 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:b865:59ae:e7cb:f375] (unknown [IPv6:2001:718:1a02:1:b865:59ae:e7cb:f375]) by mail.nic.cz (Postfix) with ESMTPSA id 8E3AB607D9; Thu, 26 May 2016 15:44:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464270245; bh=vv9+W7m8GmBptE7ceCotOePqJ+8RdQ03j7BmUeEzDIQ=; h=From:Date:To; b=KBEgpSMSd14jZ8VXdZp6lZ14sKSecJQhsqtkyUy1Ck2Seno8+6H3SozUim0262hqE faEZePaX9LmTMcpgDlHnd6lhds6+8Hp+dNp1ZvTALoyYbLjUtqEEyhbOsvXSl9kqqe gdZWRVLr972P5YbCx6NMqRNhEYhrjau+o2hLYIFY=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Thu, 26 May 2016 15:44:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20160526.152646.615068717107290692.mbj@tail-f.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NP-container and min-elements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 13:45:54 -0000

> On 26 May 2016, at 15:29, Andy Bierman  wrote:
>=20
>=20
>=20
> On Thu, May 26, 2016 at 6:26 AM, Martin Bjorklund  =
wrote:
> Andy Bierman  wrote:
> > Hi,
> >
> > Our compiler generates a "top-level mandatory" warning for something
> > like this:
> >
> >    container top {
> >      list foo {
> >         min-elements 1;
> >         ...
> >       }
> >    }
> >
> > A customer is saying this is incorrect.  RFC6020bis is confusing on =
this
> > issue.
> >
> >
> > Terms::
> >
> >    o  mandatory node: A mandatory node is one of:
> >
> >       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
> >          statement with the value "true".
> >
> >       *  A list or leaf-list node with a "min-elements" statement =
with a
> >          value greater than zero.
> >
> >       *  A container node without a "presence" statement, which has =
at
> >          least one mandatory node as a child.
>=20
> With this definition, I think it is clear that 'top' is a "mandatory
> node".  What is confusing about this?
>=20
>=20
>=20
> This is clear but 7.7.5 is not clear that the docroot is an ancestor =
data node.

But in your example the ancestor is the "top" container, and it is a =
mandatory top-level node.

Lada=20

>=20
> =20
>=20
> /martin
>=20
>=20
> Andy
> =20
>=20
>=20
> >
> >
> > 7.7.5.  The min-elements Statement
> >
> >    The "min-elements" statement, which is optional, takes as an =
argument
> >    a non-negative integer that puts a constraint on valid list =
entries.
> >    A valid leaf-list or list MUST have at least min-elements =
entries.
> >
> >    If no "min-elements" statement is present, it defaults to zero.
> >
> >  *  The behavior of the constraint depends on the type of the =
leaf-list's
> >    or list's closest ancestor node in the schema tree that is not a =
non-
> >    presence-container (see Section 7.5.1):
> > *
> >    o  If this ancestor is a case node, the constraint is enforced if =
any
> >       other node from the case exists.
> >
> >    o  Otherwise, it is enforced if the ancestor node exists.
> >
> >
> > 8.1:
> >
> >   o  The "mandatory" constraint is enforced for leafs and choices,
> >       unless the node or any of its ancestors has a "when" condition =
or
> >       "if-feature" expression that evaluates to "false".
> >
> >    o  The "min-elements" and "max-elements" constraints are enforced =
for
> >       lists and leaf-lists, unless the node or any of its ancestors =
has
> >       a "when" condition or "if-feature" expression that evaluates =
to
> >       "false".
> >
> > In this example, there is no ancestor node (except docroot) that is =
not an
> > NP-container. The "mandatory" term and sec. 7.7.5 implies that the
> > warning is correct. Sec. 8.1 implies the ancestor data node has to =
exist for
> > min-elements to be enforced. Is the docroot the ancestor node in =
this
> > example?
> >
> > The transparent nature of NP-containers has always confused people.
> > It is not that obvious that they are so very different than all =
other node
> > types.
> >
> >
> > Andy
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Thu May 26 06:49:30 2016
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 1318612DAB7 for ; Thu, 26 May 2016 06:49:28 -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 DGOa-qjVbP_S for ; Thu, 26 May 2016 06:49:26 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 4214D12DA16 for ; Thu, 26 May 2016 06:49:25 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id h19so76993963ywc.0 for ; Thu, 26 May 2016 06:49: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:date:message-id:subject:from:to :cc; bh=vKHEjUqKy6/nnXlg2Db0QVnYlXwO5wAZFpGUV7ImuRc=; b=m9/gt8ECGwoQqvCb57ykNIJ2VJEt4bJfRi7fwlU1fn0FbDp/Ep89KwkO4QaIo+Yhld C4mpAaAQGyfJBTXAkXshIhk1VXREpnjEsqHx32TBAfNcKhtbyt/NCaqLQvzK6XBnxH+m x4TBIBfv87SOvQK4uOPRQhfKxa5OZTyjzeUg9z8si0ibRJEtssWD9udjIkB1JX27R47j SrCCASkV5Hw0384e8UW1HWGaqp19H5sKzhXz1/LBl4dekXOL2aWGfjeiWTBdDuHUiVde 5l8KHzSUzfAcHzYHIVqMJRd9cH3MkhV2ZdRzabwZ/47AL5dQNu1B5+m31wyOsAnNc3vi 9I5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vKHEjUqKy6/nnXlg2Db0QVnYlXwO5wAZFpGUV7ImuRc=; b=LQS3Jodgc0r+bh0f5/4D51ZuzQD7ssvbzI28gFFJL4GLDfazlTt74slpY89nydG+bI F9016zcIYvjVW70abCa3hfR5wkMzrvo/XrvHgmZLXjX1YeB489QiY5yj/yU++V1SDE/D /HGyj+7b7LCy1xG6/x5ERvnzEpcaUn8h7fcStyPdJ/1+nstxjNGW1x2MzKBsWEfgoRUU zABKyBezl41PLn7nTnZFeIjmmnV4XqAKJcyHV5iFjcVVnj30lCghbrNClkrNYscsLDCk D1h3XTbf3uLb7oHvkxFozV0upd83k5uzF2MPv8e0sZaE0udN7eSx6yEkSXZd8dX+N2DP OvHw==
X-Gm-Message-State: ALyK8tK1HnRHYM8QTT5gTtpyuJI8rpzJgUl6w8715Fvwwp5qBL7vLtgOvBQ3AcMkz1/LBWO/HgDTDpzIO9AQfg==
MIME-Version: 1.0
X-Received: by 10.129.74.86 with SMTP id x83mr6307876ywa.38.1464270564497; Thu, 26 May 2016 06:49:24 -0700 (PDT)
Received: by 10.37.44.199 with HTTP; Thu, 26 May 2016 06:49:24 -0700 (PDT)
In-Reply-To: 
References:  <20160526.152646.615068717107290692.mbj@tail-f.com>  
Date: Thu, 26 May 2016 06:49:24 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a114c8c3ada53c90533bf0eff
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NP-container and min-elements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 13:49:28 -0000

--001a114c8c3ada53c90533bf0eff
Content-Type: text/plain; charset=UTF-8

On Thu, May 26, 2016 at 6:44 AM, Ladislav Lhotka  wrote:

>
> > On 26 May 2016, at 15:29, Andy Bierman  wrote:
> >
> >
> >
> > On Thu, May 26, 2016 at 6:26 AM, Martin Bjorklund 
> wrote:
> > Andy Bierman  wrote:
> > > Hi,
> > >
> > > Our compiler generates a "top-level mandatory" warning for something
> > > like this:
> > >
> > >    container top {
> > >      list foo {
> > >         min-elements 1;
> > >         ...
> > >       }
> > >    }
> > >
> > > A customer is saying this is incorrect.  RFC6020bis is confusing on
> this
> > > issue.
> > >
> > >
> > > Terms::
> > >
> > >    o  mandatory node: A mandatory node is one of:
> > >
> > >       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
> > >          statement with the value "true".
> > >
> > >       *  A list or leaf-list node with a "min-elements" statement with
> a
> > >          value greater than zero.
> > >
> > >       *  A container node without a "presence" statement, which has at
> > >          least one mandatory node as a child.
> >
> > With this definition, I think it is clear that 'top' is a "mandatory
> > node".  What is confusing about this?
> >
> >
> >
> > This is clear but 7.7.5 is not clear that the docroot is an ancestor
> data node.
>
> But in your example the ancestor is the "top" container, and it is a
> mandatory top-level node.
>
>

  The behavior of the constraint depends on the type of the leaf-list's
   or list's closest ancestor node in the schema tree *that is not a non-*
*   presence-container *(see Section 7.5.1):


The min-elements text seems to indicate that the NP container is skipped
when checking if min-elements is enforced or not.


Lada
>

Andy


>
> >
> >
> >
> > /martin
> >
> >
> > Andy
> >
> >
> >
> > >
> > >
> > > 7.7.5.  The min-elements Statement
> > >
> > >    The "min-elements" statement, which is optional, takes as an
> argument
> > >    a non-negative integer that puts a constraint on valid list entries.
> > >    A valid leaf-list or list MUST have at least min-elements entries.
> > >
> > >    If no "min-elements" statement is present, it defaults to zero.
> > >
> > >  *  The behavior of the constraint depends on the type of the
> leaf-list's
> > >    or list's closest ancestor node in the schema tree that is not a
> non-
> > >    presence-container (see Section 7.5.1):
> > > *
> > >    o  If this ancestor is a case node, the constraint is enforced if
> any
> > >       other node from the case exists.
> > >
> > >    o  Otherwise, it is enforced if the ancestor node exists.
> > >
> > >
> > > 8.1:
> > >
> > >   o  The "mandatory" constraint is enforced for leafs and choices,
> > >       unless the node or any of its ancestors has a "when" condition or
> > >       "if-feature" expression that evaluates to "false".
> > >
> > >    o  The "min-elements" and "max-elements" constraints are enforced
> for
> > >       lists and leaf-lists, unless the node or any of its ancestors has
> > >       a "when" condition or "if-feature" expression that evaluates to
> > >       "false".
> > >
> > > In this example, there is no ancestor node (except docroot) that is
> not an
> > > NP-container. The "mandatory" term and sec. 7.7.5 implies that the
> > > warning is correct. Sec. 8.1 implies the ancestor data node has to
> exist for
> > > min-elements to be enforced. Is the docroot the ancestor node in this
> > > example?
> > >
> > > The transparent nature of NP-containers has always confused people.
> > > It is not that obvious that they are so very different than all other
> node
> > > types.
> > >
> > >
> > > Andy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a114c8c3ada53c90533bf0eff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 26, 2016 at 6:44 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 26 May 2016, at 15:29, Andy Bierman <andy@yumaworks.com> wrote:

>

>

>

> On Thu, May 26, 2016 at 6:26 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Andy Bierman <andy@yumaworks.=
com> wrote:

> > Hi,

> >

> > Our compiler generates a "top-level mandatory" warning =
for something

> > like this:

> >

> >=C2=A0 =C2=A0 container top {

> >=C2=A0 =C2=A0 =C2=A0 list foo {

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0min-elements 1;

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

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

> >=C2=A0 =C2=A0 }

> >

> > A customer is saying this is incorrect.=C2=A0 RFC6020bis is confu=
sing on this

> > issue.

> >

> >

> > Terms::

> >

> >=C2=A0 =C2=A0 o=C2=A0 mandatory node: A mandatory node is one of:<=
br>
> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A leaf, choice, anydata, or any=
xml node with a "mandatory"

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 statement with the value "=
true".

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A list or leaf-list node with a=
 "min-elements" statement with a

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value greater than zero.

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A container node without a &quo=
t;presence" statement, which has at

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 least one mandatory node as a c=
hild.

>

> With this definition, I think it is clear that 'top' is a &quo=
t;mandatory

> node".=C2=A0 What is confusing about this?

>

>

>

> This is clear but 7.7.5 is not clear that the docroot is an ancestor d=
ata node.



But in your example the ancestor is the "top" container, and it i=
s a mandatory top-level node.




=C2=A0 The behavior of the constraint depends on the type of the leaf-=
list's
=C2=A0 =C2=A0or list's closest ancestor node in the schema tree=
 that is not a non-
=C2=A0 =C2=A0presence-container (s=
ee Section 7.5.1):

=C2=A0
The min=
-elements text seems to indicate that the NP container is skipped
when checking if min-elements is enforced or not.



Lada

Andy
=C2=A0



>

>

>

> /martin

>

>

> Andy

>

>

>

> >

> >

> > 7.7.5.=C2=A0 The min-elements Statement

> >

> >=C2=A0 =C2=A0 The "min-elements" statement, which is opt=
ional, takes as an argument

> >=C2=A0 =C2=A0 a non-negative integer that puts a constraint on val=
id list entries.

> >=C2=A0 =C2=A0 A valid leaf-list or list MUST have at least min-ele=
ments entries.

> >

> >=C2=A0 =C2=A0 If no "min-elements" statement is present,=
 it defaults to zero.

> >

> >=C2=A0 *=C2=A0 The behavior of the constraint depends on the type =
of the leaf-list's

> >=C2=A0 =C2=A0 or list's closest ancestor node in the schema tr=
ee that is not a non-

> >=C2=A0 =C2=A0 presence-container (see Section 7.5.1):

> > *

> >=C2=A0 =C2=A0 o=C2=A0 If this ancestor is a case node, the constra=
int is enforced if any

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0other node from the case exists.

> >

> >=C2=A0 =C2=A0 o=C2=A0 Otherwise, it is enforced if the ancestor no=
de exists.

> >

> >

> > 8.1:

> >

> >=C2=A0 =C2=A0o=C2=A0 The "mandatory" constraint is enfor=
ced for leafs and choices,

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0unless the node or any of its ancestors=
 has a "when" condition or

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"if-feature" expression that =
evaluates to "false".

> >

> >=C2=A0 =C2=A0 o=C2=A0 The "min-elements" and "max-e=
lements" constraints are enforced for

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0lists and leaf-lists, unless the node o=
r any of its ancestors has

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0a "when" condition or "i=
f-feature" expression that evaluates to

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"false".

> >

> > In this example, there is no ancestor node (except docroot) that =
is not an

> > NP-container. The "mandatory" term and sec. 7.7.5 impli=
es that the

> > warning is correct. Sec. 8.1 implies the ancestor data node has t=
o exist for

> > min-elements to be enforced. Is the docroot the ancestor node in =
this

> > example?

> >

> > The transparent nature of NP-containers has always confused peopl=
e.

> > It is not that obvious that they are so very different than all o=
ther node

> > types.

> >

> >

> > Andy

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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


--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--001a114c8c3ada53c90533bf0eff--


From nobody Thu May 26 06:51:16 2016
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 1E4B312D146 for ; Thu, 26 May 2016 06:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 pguXE6BwuZb7 for ; Thu, 26 May 2016 06:51:15 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A091912D534 for ; Thu, 26 May 2016 06:51:14 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 98C141AE039E; Thu, 26 May 2016 15:51:13 +0200 (CEST)
Date: Thu, 26 May 2016 15:51:34 +0200 (CEST)
Message-Id: <20160526.155134.1248818963670983436.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <20160526.152646.615068717107290692.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] NP-container and min-elements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 13:51:16 -0000

Andy Bierman  wrote:
> On Thu, May 26, 2016 at 6:26 AM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > Hi,
> > >
> > > Our compiler generates a "top-level mandatory" warning for something
> > > like this:
> > >
> > >    container top {
> > >      list foo {
> > >         min-elements 1;
> > >         ...
> > >       }
> > >    }
> > >
> > > A customer is saying this is incorrect.  RFC6020bis is confusing on this
> > > issue.
> > >
> > >
> > > Terms::
> > >
> > >    o  mandatory node: A mandatory node is one of:
> > >
> > >       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
> > >          statement with the value "true".
> > >
> > >       *  A list or leaf-list node with a "min-elements" statement with a
> > >          value greater than zero.
> > >
> > >       *  A container node without a "presence" statement, which has at
> > >          least one mandatory node as a child.
> >
> > With this definition, I think it is clear that 'top' is a "mandatory
> > node".  What is confusing about this?
> >
> >
> >
> This is clear

Ok.

> but 7.7.5 is not clear that the docroot is an ancestor data
> node.

You're right.  There is similar text in 7.6.1, 7.6.5, 7.7.2, 7.7.5,
7.9.4.  Of these, 7.7.5 and 7.9.4 doesn't handle the "docroot" case.

So I suggest we align these sections.  Specifically:

OLD in 7.7.5 and 7.9.4:

   o  If this ancestor is a case node, the constraint is enforced if any
      other node from the case exists.

   o  Otherwise, it is enforced if the ancestor node exists.

NEW in 7.7.5 and 7.9.4:

   o  If no such ancestor exists in the schema tree, the constraint is
      enforced.

   o  Otherwise, if this ancestor is a case node, the constraint is
      enforced if any other node from the case exists.

   o  Otherwise, it is enforced if the ancestor node exists.


Do you think this addresses the issue?


/martin




> > > 7.7.5.  The min-elements Statement
> > >
> > >    The "min-elements" statement, which is optional, takes as an argument
> > >    a non-negative integer that puts a constraint on valid list entries.
> > >    A valid leaf-list or list MUST have at least min-elements entries.
> > >
> > >    If no "min-elements" statement is present, it defaults to zero.
> > >
> > >  *  The behavior of the constraint depends on the type of the leaf-list's
> > >    or list's closest ancestor node in the schema tree that is not a non-
> > >    presence-container (see Section 7.5.1):
> > > *
> > >    o  If this ancestor is a case node, the constraint is enforced if any
> > >       other node from the case exists.
> > >
> > >    o  Otherwise, it is enforced if the ancestor node exists.
> > >
> > >
> > > 8.1:
> > >
> > >   o  The "mandatory" constraint is enforced for leafs and choices,
> > >       unless the node or any of its ancestors has a "when" condition or
> > >       "if-feature" expression that evaluates to "false".
> > >
> > >    o  The "min-elements" and "max-elements" constraints are enforced for
> > >       lists and leaf-lists, unless the node or any of its ancestors has
> > >       a "when" condition or "if-feature" expression that evaluates to
> > >       "false".
> > >
> > > In this example, there is no ancestor node (except docroot) that is not
> > an
> > > NP-container. The "mandatory" term and sec. 7.7.5 implies that the
> > > warning is correct. Sec. 8.1 implies the ancestor data node has to exist
> > for
> > > min-elements to be enforced. Is the docroot the ancestor node in this
> > > example?
> > >
> > > The transparent nature of NP-containers has always confused people.
> > > It is not that obvious that they are so very different than all other
> > node
> > > types.
> > >
> > >
> > > Andy
> >


From nobody Thu May 26 07:02:35 2016
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 3431512DB3D for ; Thu, 26 May 2016 07:02:34 -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 aKOC1mxVS6F5 for ; Thu, 26 May 2016 07:02:30 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C950C12D0FB for ; Thu, 26 May 2016 07:02:29 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id x189so77132406ywe.3 for ; Thu, 26 May 2016 07:02:29 -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:date:message-id:subject:from:to :cc; bh=37fsmDpmlLKpnuU13ETAwp/+2yogkxg0UBde7dHLEOw=; b=c2VU2NpsCqPrPIn1V8SaqqxSxhH5oJOqL3iiYQnQKAbURi5ZqnDvYKoB/KteAp170m oNKpda9Akwmjpmu73jYHz4/85K4297Wd3NQlPKjVIcCS05oqrEW6204zHYjJz0Ax2lD4 3dM0OUHQMQCXbEKQWOyGl+PfO+1osrHDagO9FmYEZje5fK5a4uWJm+EXqd/hZbSU+mkl TMqamd8WXYliJdODKq/cwLPfXXBORzhtI79KOPYLg2LtZCCuhC0rTv0ArTJ2W5KFMsuc leAatgz1001e5wbm2Myj7bghG0cKAYhzGMD9WHaQJlaY2elvThuLE0p9eAyPJVM7LRQ1 csrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=37fsmDpmlLKpnuU13ETAwp/+2yogkxg0UBde7dHLEOw=; b=LeMeqxzeU9AUZ/1Q233SfN7exlSN83HSAOFHr07MKFcaj/gbjuYNYJuav6XwD9mUOK c7HQ4DGxuLSh6ocwU412lTbLY2o2oYSGdHCVwheuw4ej+j7CsWqRTiPhSYaiGMY8Apzz 4a5tzU5lwjTQhwgXxokADtQ7KDIDR7Fc8+AUVhVAemzhyxPwWPmrc9T8lpUC+5pQuV1/ vxRvKf8Xpk0zcAX7hE2iw9HyO4pBZdsCTT/tKBaoUgNDvUKdZv3A/l27adIQQ92/SMPU F9YXm+uc0n5B21nSz2jt3EjSyXTZvvp+NxnFMJyawmU6uL6/34EbJSlLX5Tqd5LU6PpT 9ZDQ==
X-Gm-Message-State: ALyK8tL6H77mJMChW1b/AeUAxRufwMnm1tq22u4CCGTGx4/9MmR8jJ/6rjRe66yQt9m6kXOuudPR1QMmBR8tCw==
MIME-Version: 1.0
X-Received: by 10.13.215.149 with SMTP id z143mr5610497ywd.166.1464271349001;  Thu, 26 May 2016 07:02:29 -0700 (PDT)
Received: by 10.37.44.199 with HTTP; Thu, 26 May 2016 07:02:28 -0700 (PDT)
In-Reply-To: <20160526.155134.1248818963670983436.mbj@tail-f.com>
References:  <20160526.152646.615068717107290692.mbj@tail-f.com>  <20160526.155134.1248818963670983436.mbj@tail-f.com>
Date: Thu, 26 May 2016 07:02:28 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=94eb2c07621e9cf29b0533bf3dcd
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NP-container and min-elements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 14:02:34 -0000

--94eb2c07621e9cf29b0533bf3dcd
Content-Type: text/plain; charset=UTF-8

On Thu, May 26, 2016 at 6:51 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Thu, May 26, 2016 at 6:26 AM, Martin Bjorklund 
> wrote:
> >
> > > Andy Bierman  wrote:
> > > > Hi,
> > > >
> > > > Our compiler generates a "top-level mandatory" warning for something
> > > > like this:
> > > >
> > > >    container top {
> > > >      list foo {
> > > >         min-elements 1;
> > > >         ...
> > > >       }
> > > >    }
> > > >
> > > > A customer is saying this is incorrect.  RFC6020bis is confusing on
> this
> > > > issue.
> > > >
> > > >
> > > > Terms::
> > > >
> > > >    o  mandatory node: A mandatory node is one of:
> > > >
> > > >       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
> > > >          statement with the value "true".
> > > >
> > > >       *  A list or leaf-list node with a "min-elements" statement
> with a
> > > >          value greater than zero.
> > > >
> > > >       *  A container node without a "presence" statement, which has
> at
> > > >          least one mandatory node as a child.
> > >
> > > With this definition, I think it is clear that 'top' is a "mandatory
> > > node".  What is confusing about this?
> > >
> > >
> > >
> > This is clear
>
> Ok.
>
> > but 7.7.5 is not clear that the docroot is an ancestor data
> > node.
>
> You're right.  There is similar text in 7.6.1, 7.6.5, 7.7.2, 7.7.5,
> 7.9.4.  Of these, 7.7.5 and 7.9.4 doesn't handle the "docroot" case.
>
> So I suggest we align these sections.  Specifically:
>
> OLD in 7.7.5 and 7.9.4:
>
>    o  If this ancestor is a case node, the constraint is enforced if any
>       other node from the case exists.
>
>    o  Otherwise, it is enforced if the ancestor node exists.
>
> NEW in 7.7.5 and 7.9.4:
>
>    o  If no such ancestor exists in the schema tree, the constraint is
>       enforced.
>
>    o  Otherwise, if this ancestor is a case node, the constraint is
>       enforced if any other node from the case exists.
>
>    o  Otherwise, it is enforced if the ancestor node exists.
>
>
> Do you think this addresses the issue?
>
>

yes


>
> /martin
>
>
>
>
> > > > 7.7.5.  The min-elements Statement
> > > >
> > > >    The "min-elements" statement, which is optional, takes as an
> argument
> > > >    a non-negative integer that puts a constraint on valid list
> entries.
> > > >    A valid leaf-list or list MUST have at least min-elements entries.
> > > >
> > > >    If no "min-elements" statement is present, it defaults to zero.
> > > >
> > > >  *  The behavior of the constraint depends on the type of the
> leaf-list's
> > > >    or list's closest ancestor node in the schema tree that is not a
> non-
> > > >    presence-container (see Section 7.5.1):
> > > > *
> > > >    o  If this ancestor is a case node, the constraint is enforced if
> any
> > > >       other node from the case exists.
> > > >
> > > >    o  Otherwise, it is enforced if the ancestor node exists.
> > > >
> > > >
> > > > 8.1:
> > > >
> > > >   o  The "mandatory" constraint is enforced for leafs and choices,
> > > >       unless the node or any of its ancestors has a "when" condition
> or
> > > >       "if-feature" expression that evaluates to "false".
> > > >
> > > >    o  The "min-elements" and "max-elements" constraints are enforced
> for
> > > >       lists and leaf-lists, unless the node or any of its ancestors
> has
> > > >       a "when" condition or "if-feature" expression that evaluates to
> > > >       "false".
> > > >
> > > > In this example, there is no ancestor node (except docroot) that is
> not
> > > an
> > > > NP-container. The "mandatory" term and sec. 7.7.5 implies that the
> > > > warning is correct. Sec. 8.1 implies the ancestor data node has to
> exist
> > > for
> > > > min-elements to be enforced. Is the docroot the ancestor node in this
> > > > example?
> > > >
> > > > The transparent nature of NP-containers has always confused people.
> > > > It is not that obvious that they are so very different than all other
> > > node
> > > > types.
> > > >
> > > >
> > > > Andy
> > >
>

--94eb2c07621e9cf29b0533bf3dcd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, May 26, 2016 at 6:51 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> On Thu, May 26, 2016 at 6:26 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

>

> > Andy Bierman <andy@yumaw=
orks.com> wrote:

> > > Hi,

> > >

> > > Our compiler generates a "top-level mandatory" war=
ning for something

> > > like this:

> > >

> > >=C2=A0 =C2=A0 container top {

> > >=C2=A0 =C2=A0 =C2=A0 list foo {

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0min-elements 1;

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

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

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

> > >

> > > A customer is saying this is incorrect.=C2=A0 RFC6020bis is =
confusing on this

> > > issue.

> > >

> > >

> > > Terms::

> > >

> > >=C2=A0 =C2=A0 o=C2=A0 mandatory node: A mandatory node is one=
 of:

> > >

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A leaf, choice, anydata, o=
r anyxml node with a "mandatory"

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 statement with the value &=
quot;true".

> > >

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A list or leaf-list node w=
ith a "min-elements" statement with a

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value greater than zero.
> > >

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A container node without a=
 "presence" statement, which has at

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 least one mandatory node a=
s a child.

> >

> > With this definition, I think it is clear that 'top' is a=
 "mandatory

> > node".=C2=A0 What is confusing about this?

> >

> >

> >

> This is clear



Ok.



> but 7.7.5 is not clear that the docroot is an ancestor data

> node.



You're right.=C2=A0 There is similar text in 7.6.1, 7.6.5, 7.7.2, 7.7.5=
,

7.9.4.=C2=A0 Of these, 7.7.5 and 7.9.4 doesn't handle the "docroot=
" case.



So I suggest we align these sections.=C2=A0 Specifically:



OLD in 7.7.5 and 7.9.4:



=C2=A0 =C2=A0o=C2=A0 If this ancestor is a case node, the constraint is enf=
orced if any

=C2=A0 =C2=A0 =C2=A0 other node from the case exists.



=C2=A0 =C2=A0o=C2=A0 Otherwise, it is enforced if the ancestor node exists.=




NEW in 7.7.5 and 7.9.4:



=C2=A0 =C2=A0o=C2=A0 If no such ancestor exists in the schema tree, the con=
straint is

=C2=A0 =C2=A0 =C2=A0 enforced.



=C2=A0 =C2=A0o=C2=A0 Otherwise, if this ancestor is a case node, the constr=
aint is

=C2=A0 =C2=A0 =C2=A0 enforced if any other node from the case exists.



=C2=A0 =C2=A0o=C2=A0 Otherwise, it is enforced if the ancestor node exists.=






Do you think this addresses the issue?




yes
=C2=A0



/martin









> > > 7.7.5.=C2=A0 The min-elements Statement

> > >

> > >=C2=A0 =C2=A0 The "min-elements" statement, which i=
s optional, takes as an argument

> > >=C2=A0 =C2=A0 a non-negative integer that puts a constraint o=
n valid list entries.

> > >=C2=A0 =C2=A0 A valid leaf-list or list MUST have at least mi=
n-elements entries.

> > >

> > >=C2=A0 =C2=A0 If no "min-elements" statement is pre=
sent, it defaults to zero.

> > >

> > >=C2=A0 *=C2=A0 The behavior of the constraint depends on the =
type of the leaf-list's

> > >=C2=A0 =C2=A0 or list's closest ancestor node in the sche=
ma tree that is not a non-

> > >=C2=A0 =C2=A0 presence-container (see Section 7.5.1):

> > > *

> > >=C2=A0 =C2=A0 o=C2=A0 If this ancestor is a case node, the co=
nstraint is enforced if any

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0other node from the case exists.
> > >

> > >=C2=A0 =C2=A0 o=C2=A0 Otherwise, it is enforced if the ancest=
or node exists.

> > >

> > >

> > > 8.1:

> > >

> > >=C2=A0 =C2=A0o=C2=A0 The "mandatory" constraint is =
enforced for leafs and choices,

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0unless the node or any of its ance=
stors has a "when" condition or

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"if-feature" expression =
that evaluates to "false".

> > >

> > >=C2=A0 =C2=A0 o=C2=A0 The "min-elements" and "=
max-elements" constraints are enforced for

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0lists and leaf-lists, unless the n=
ode or any of its ancestors has

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0a "when" condition or &q=
uot;if-feature" expression that evaluates to

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"false".

> > >

> > > In this example, there is no ancestor node (except docroot) =
that is not

> > an

> > > NP-container. The "mandatory" term and sec. 7.7.5 =
implies that the

> > > warning is correct. Sec. 8.1 implies the ancestor data node =
has to exist

> > for

> > > min-elements to be enforced. Is the docroot the ancestor nod=
e in this

> > > example?

> > >

> > > The transparent nature of NP-containers has always confused =
people.

> > > It is not that obvious that they are so very different than =
all other

> > node

> > > types.

> > >

> > >

> > > Andy

> >





--94eb2c07621e9cf29b0533bf3dcd--


From nobody Thu May 26 07:37:02 2016
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 D43ED12D158 for ; Thu, 26 May 2016 07:37:00 -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 xBf74XoWOQ4x for ; Thu, 26 May 2016 07:36:58 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 37EC912D72F for ; Thu, 26 May 2016 07:36:13 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id c127so78193187ywb.1 for ; Thu, 26 May 2016 07:36:13 -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:date:message-id:subject:from:to :cc; bh=moPlicIVynTcpuxXtc8MYPsxEGRJJXlMg854KE+lEEY=; b=RKxS+Cca9I/dhml90FBXQysHRHxqXQovS022kHxr/yYADs0o6QvzVoQAeJ/WNH1jSX u8ZNlGgTLAxYct7gh8upgLtaA5JhdBftVXiXcHa6/9zJZ29Mz/xGqjs4BOEfhWi1F3OI 7tHSOe4hvFe6RZMuGweIcoEK2FbqN8wFnMsJZHpARf2NSHPOxMkyQk4kTH1sSpe/6IIO xLa84anPKmQfn186YlULMtbv6hFbtoNyQZY6Ebp9howLu6VU5ftcfLAnpJJkvfrpFFzC 5fWs4qBCfsT9zG5HPY7ZBoPVwrFUiW79CPE7fJMUlfvUoOCFlYitY20eO8/6xRy1s9pB 0SuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=moPlicIVynTcpuxXtc8MYPsxEGRJJXlMg854KE+lEEY=; b=NDvAxHMmAFeSWm1Q2Mxf+m6egL0PIGUP+A7LhtANypDgzN4DCl8ewzOXifiFqSQtSt d8rWwBp0+ZY6E9YfuwdvTvb0WX7g2V+kMS9OnBn5i8bCXq91UOqnfo5eSwVXow8arPJe yY2Is/bSaaiERUmKFs9D81dCvWhCORw/jc8j9Bth9s67xw19s70FDsK2MHxQqp2e1Odl oP6Keotu2j56I396XhkAd281y6WCZbBnyYW5Q6c+pmepPxidm7eNltYkbzow768JohP6 FOhqRxEarXG0hEJ3t/Ij4aba7BgTZNCCLjHo8UN0e0IKkf3BGzzjE3WqV1rsclHtf0OL dzSQ==
X-Gm-Message-State: ALyK8tLirVduTI9RrRwk7JZJ5Y6IFUj7UXKZdwwC1vm1of78mi7xSdKXkeF1AfG9emG8DqQq5USc1gA79g3nMw==
MIME-Version: 1.0
X-Received: by 10.37.66.145 with SMTP id p139mr5401484yba.97.1464273372313; Thu, 26 May 2016 07:36:12 -0700 (PDT)
Received: by 10.37.44.199 with HTTP; Thu, 26 May 2016 07:36:12 -0700 (PDT)
In-Reply-To: <20160526.155134.1248818963670983436.mbj@tail-f.com>
References:  <20160526.152646.615068717107290692.mbj@tail-f.com>  <20160526.155134.1248818963670983436.mbj@tail-f.com>
Date: Thu, 26 May 2016 07:36:12 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11c02ec4364a910533bfb60a
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NP-container and min-elements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 14:37:01 -0000

--001a11c02ec4364a910533bfb60a
Content-Type: text/plain; charset=UTF-8

Hi,

I ran a test on a module with these 2 statements:

  container top {
    list mand-list {
      key name;
      min-elements 1;
      leaf name { type string; }
      leaf-list vlan-id { type uint32; }
    }
  }


  choice top-ch {
    default A;
    case A {
      list mand-list {
        key name;
        min-elements 1;
        leaf name { type string; }
        leaf-list vlan-id { type uint32; }
      }
    }
  }


yangdump-pro gives a warning about container top is mandatory, but pyang is
silent.
Both compilers give an error about the mandatory node in a default case.

IMO YANG is inconsistent here. Both constructs result in exactly the same
mandatory list,
but 1 is an error and the other is not.


Andy


On Thu, May 26, 2016 at 6:51 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Thu, May 26, 2016 at 6:26 AM, Martin Bjorklund 
> wrote:
> >
> > > Andy Bierman  wrote:
> > > > Hi,
> > > >
> > > > Our compiler generates a "top-level mandatory" warning for something
> > > > like this:
> > > >
> > > >    container top {
> > > >      list foo {
> > > >         min-elements 1;
> > > >         ...
> > > >       }
> > > >    }
> > > >
> > > > A customer is saying this is incorrect.  RFC6020bis is confusing on
> this
> > > > issue.
> > > >
> > > >
> > > > Terms::
> > > >
> > > >    o  mandatory node: A mandatory node is one of:
> > > >
> > > >       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
> > > >          statement with the value "true".
> > > >
> > > >       *  A list or leaf-list node with a "min-elements" statement
> with a
> > > >          value greater than zero.
> > > >
> > > >       *  A container node without a "presence" statement, which has
> at
> > > >          least one mandatory node as a child.
> > >
> > > With this definition, I think it is clear that 'top' is a "mandatory
> > > node".  What is confusing about this?
> > >
> > >
> > >
> > This is clear
>
> Ok.
>
> > but 7.7.5 is not clear that the docroot is an ancestor data
> > node.
>
> You're right.  There is similar text in 7.6.1, 7.6.5, 7.7.2, 7.7.5,
> 7.9.4.  Of these, 7.7.5 and 7.9.4 doesn't handle the "docroot" case.
>
> So I suggest we align these sections.  Specifically:
>
> OLD in 7.7.5 and 7.9.4:
>
>    o  If this ancestor is a case node, the constraint is enforced if any
>       other node from the case exists.
>
>    o  Otherwise, it is enforced if the ancestor node exists.
>
> NEW in 7.7.5 and 7.9.4:
>
>    o  If no such ancestor exists in the schema tree, the constraint is
>       enforced.
>
>    o  Otherwise, if this ancestor is a case node, the constraint is
>       enforced if any other node from the case exists.
>
>    o  Otherwise, it is enforced if the ancestor node exists.
>
>
> Do you think this addresses the issue?
>
>
> /martin
>
>
>
>
> > > > 7.7.5.  The min-elements Statement
> > > >
> > > >    The "min-elements" statement, which is optional, takes as an
> argument
> > > >    a non-negative integer that puts a constraint on valid list
> entries.
> > > >    A valid leaf-list or list MUST have at least min-elements entries.
> > > >
> > > >    If no "min-elements" statement is present, it defaults to zero.
> > > >
> > > >  *  The behavior of the constraint depends on the type of the
> leaf-list's
> > > >    or list's closest ancestor node in the schema tree that is not a
> non-
> > > >    presence-container (see Section 7.5.1):
> > > > *
> > > >    o  If this ancestor is a case node, the constraint is enforced if
> any
> > > >       other node from the case exists.
> > > >
> > > >    o  Otherwise, it is enforced if the ancestor node exists.
> > > >
> > > >
> > > > 8.1:
> > > >
> > > >   o  The "mandatory" constraint is enforced for leafs and choices,
> > > >       unless the node or any of its ancestors has a "when" condition
> or
> > > >       "if-feature" expression that evaluates to "false".
> > > >
> > > >    o  The "min-elements" and "max-elements" constraints are enforced
> for
> > > >       lists and leaf-lists, unless the node or any of its ancestors
> has
> > > >       a "when" condition or "if-feature" expression that evaluates to
> > > >       "false".
> > > >
> > > > In this example, there is no ancestor node (except docroot) that is
> not
> > > an
> > > > NP-container. The "mandatory" term and sec. 7.7.5 implies that the
> > > > warning is correct. Sec. 8.1 implies the ancestor data node has to
> exist
> > > for
> > > > min-elements to be enforced. Is the docroot the ancestor node in this
> > > > example?
> > > >
> > > > The transparent nature of NP-containers has always confused people.
> > > > It is not that obvious that they are so very different than all other
> > > node
> > > > types.
> > > >
> > > >
> > > > Andy
> > >
>

--001a11c02ec4364a910533bfb60a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I ran a test on a module with these=
 2 statements:

=C2=A0 container top {
=C2=A0 =C2=A0 list mand-list {
=C2=A0 =C2=A0 =C2=A0 key name;<=
/div>
=C2=A0 =C2=A0 =C2=A0 min-elements 1;
=C2=A0 =C2=A0 =C2=
=A0 leaf name { type string; }
=C2=A0 =C2=A0 =C2=A0 leaf-list vla=
n-id { type uint32; }
=C2=A0 =C2=A0 }
=C2=A0 }


=C2=A0 choice top-ch {
=C2=A0 =C2=
=A0 default A;
=C2=A0 =C2=A0 case A {
=C2=A0 =C2=A0 =C2=
=A0 list mand-list {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 key name;
<=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 min-elements 1;
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 leaf name { type string; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 leaf-list vlan-id { type uint32; }
=C2=A0 =C2=A0 =C2=A0 }
<=
div>=C2=A0 =C2=A0 }
=C2=A0 }


<=
/div>
yangdump-pro gives a warning about container top is mandatory, bu=
t pyang is silent.
Both compilers give an error about the mandato=
ry node in a default case.

IMO YANG is inconsisten=
t here. Both constructs result in exactly the same mandatory list,
but 1 is an error and the other is not.


Andy


On Thu, May 26, 2016 at 6:51 AM, Martin Bjorklund <mbj@t=
ail-f.com> wrote:
Andy Bie=
rman <andy@yumaworks.com> w=
rote:

> On Thu, May 26, 2016 at 6:26 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

>

> > Andy Bierman <andy@yumaw=
orks.com> wrote:

> > > Hi,

> > >

> > > Our compiler generates a "top-level mandatory" war=
ning for something

> > > like this:

> > >

> > >=C2=A0 =C2=A0 container top {

> > >=C2=A0 =C2=A0 =C2=A0 list foo {

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0min-elements 1;

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

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

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

> > >

> > > A customer is saying this is incorrect.=C2=A0 RFC6020bis is =
confusing on this

> > > issue.

> > >

> > >

> > > Terms::

> > >

> > >=C2=A0 =C2=A0 o=C2=A0 mandatory node: A mandatory node is one=
 of:

> > >

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A leaf, choice, anydata, o=
r anyxml node with a "mandatory"

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 statement with the value &=
quot;true".

> > >

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A list or leaf-list node w=
ith a "min-elements" statement with a

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value greater than zero.
> > >

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 A container node without a=
 "presence" statement, which has at

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 least one mandatory node a=
s a child.

> >

> > With this definition, I think it is clear that 'top' is a=
 "mandatory

> > node".=C2=A0 What is confusing about this?

> >

> >

> >

> This is clear



Ok.



> but 7.7.5 is not clear that the docroot is an ancestor data

> node.



You're right.=C2=A0 There is similar text in 7.6.1, 7.6.5, 7.7.2, 7.7.5=
,

7.9.4.=C2=A0 Of these, 7.7.5 and 7.9.4 doesn't handle the "docroot=
" case.



So I suggest we align these sections.=C2=A0 Specifically:



OLD in 7.7.5 and 7.9.4:



=C2=A0 =C2=A0o=C2=A0 If this ancestor is a case node, the constraint is enf=
orced if any

=C2=A0 =C2=A0 =C2=A0 other node from the case exists.



=C2=A0 =C2=A0o=C2=A0 Otherwise, it is enforced if the ancestor node exists.=




NEW in 7.7.5 and 7.9.4:



=C2=A0 =C2=A0o=C2=A0 If no such ancestor exists in the schema tree, the con=
straint is

=C2=A0 =C2=A0 =C2=A0 enforced.



=C2=A0 =C2=A0o=C2=A0 Otherwise, if this ancestor is a case node, the constr=
aint is

=C2=A0 =C2=A0 =C2=A0 enforced if any other node from the case exists.



=C2=A0 =C2=A0o=C2=A0 Otherwise, it is enforced if the ancestor node exists.=






Do you think this addresses the issue?





/martin









> > > 7.7.5.=C2=A0 The min-elements Statement

> > >

> > >=C2=A0 =C2=A0 The "min-elements" statement, which i=
s optional, takes as an argument

> > >=C2=A0 =C2=A0 a non-negative integer that puts a constraint o=
n valid list entries.

> > >=C2=A0 =C2=A0 A valid leaf-list or list MUST have at least mi=
n-elements entries.

> > >

> > >=C2=A0 =C2=A0 If no "min-elements" statement is pre=
sent, it defaults to zero.

> > >

> > >=C2=A0 *=C2=A0 The behavior of the constraint depends on the =
type of the leaf-list's

> > >=C2=A0 =C2=A0 or list's closest ancestor node in the sche=
ma tree that is not a non-

> > >=C2=A0 =C2=A0 presence-container (see Section 7.5.1):

> > > *

> > >=C2=A0 =C2=A0 o=C2=A0 If this ancestor is a case node, the co=
nstraint is enforced if any

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0other node from the case exists.
> > >

> > >=C2=A0 =C2=A0 o=C2=A0 Otherwise, it is enforced if the ancest=
or node exists.

> > >

> > >

> > > 8.1:

> > >

> > >=C2=A0 =C2=A0o=C2=A0 The "mandatory" constraint is =
enforced for leafs and choices,

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0unless the node or any of its ance=
stors has a "when" condition or

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"if-feature" expression =
that evaluates to "false".

> > >

> > >=C2=A0 =C2=A0 o=C2=A0 The "min-elements" and "=
max-elements" constraints are enforced for

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0lists and leaf-lists, unless the n=
ode or any of its ancestors has

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0a "when" condition or &q=
uot;if-feature" expression that evaluates to

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0"false".

> > >

> > > In this example, there is no ancestor node (except docroot) =
that is not

> > an

> > > NP-container. The "mandatory" term and sec. 7.7.5 =
implies that the

> > > warning is correct. Sec. 8.1 implies the ancestor data node =
has to exist

> > for

> > > min-elements to be enforced. Is the docroot the ancestor nod=
e in this

> > > example?

> > >

> > > The transparent nature of NP-containers has always confused =
people.

> > > It is not that obvious that they are so very different than =
all other

> > node

> > > types.

> > >

> > >

> > > Andy

> >





--001a11c02ec4364a910533bfb60a--


From nobody Thu May 26 17:53:47 2016
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 0396912B008 for ; Thu, 26 May 2016 17:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, 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 Z-iY-qvYIZLS for ; Thu, 26 May 2016 17:53:43 -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 77FF812D9EC for ; Thu, 26 May 2016 17:53:43 -0700 (PDT)
From: Alex Campbell 
To: "Ing-Wher (Helen) Chen" 
Thread-Topic: [netmod] update on "rdns" URN for enterprise YANG models
Thread-Index: AdGXJqT2atwqDO1sS7m+/GLgZx0D2AAPsN6AAAEKSAAAEGZBAAC512KAAAQnzAAAKonEAAcZFxLS
Date: Fri, 27 May 2016 00:53:41 +0000
Message-ID: <1464310422122.33255@Aviatnet.com>
References:  <20160415152317.GB95324@elstar.local>  <20160415234236.GC95761@elstar.local>  <20160419182250.GA3771@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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 May 2016 00:53:45 -0000

=0A=
> From: netmod  on behalf of Ing-Wher (Helen) Chen=
 =0A=
> Sent: Thursday, 21 April 2016 2:40 a.m.=0A=
> To: Juergen Schoenwaelder=0A=
> Cc: netmod@ietf.org=0A=
> Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models=0A=
> =0A=
> > -----Original Message-----=0A=
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=0A=
> > university.de]=0A=
> > Sent: Tuesday, April 19, 2016 2:23 PM=0A=
> > To: Ing-Wher (Helen) Chen =0A=
> > Cc: netmod@ietf.org=0A=
> > Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models=
=0A=
> >=0A=
> > On Tue, Apr 19, 2016 at 04:23:51PM +0000, Ing-Wher (Helen) Chen wrote:=
=0A=
> > > I'm not an expert on XML namespaces and I'm a little confused by some=
=0A=
> > > of the questions, so I apologize if my response below does not quite=
=0A=
> > > answer the questions.  I'd like to point out that the request for=0A=
> > > "rdns" URN is not to prevent the use of URLs. The request for "rdns"=
=0A=
> > > URN is to allow an enterprise to easily create a URN namespace, if th=
e=0A=
> > > enterprise happens to prefer to use URN as a YANG module namespace.  =
I=0A=
> > > also think that the problems that arise when a YANG module uses a URN=
=0A=
> > > based on an enterprise's domain name are the same problems that arise=
=0A=
> > > when a YANG module uses a URL based on an enterprise's domain name.=
=0A=
> > > (Of course, this is not an excuse to fix the problems that should be=
=0A=
> > > fixed.)=0A=
> >=0A=
> > You write "happen to prefer to use URN" - why?=0A=
=0A=
> draft-chen-rdns-urn Section 4 =0A=
> discusses why an enterprise might prefer to use URN over URL.  URL provid=
es=0A=
> resource access mechanism, which might mislead a customer to request that=
=0A=
> the YANG module be accessible at a specific location.  It's true that the=
 device=0A=
> does not care that the YANG module is not at a particular URL, but I can =
still=0A=
> imagine getting a bug requesting that the YANG module be accessible at th=
e URL.=0A=
=0A=
URLs are frequently used as namespaces in XML, without referring to a parti=
cular resource (and most of them are HTTP URLs that return generic error-40=
4 pages).=0A=
Does this proposal suggest that YANG namespaces should be treated different=
ly from XML namespaces?=0A=
=0A=
> Thanks,=0A=
> Helen=0A=
=0A=


From nobody Fri May 27 03:57:07 2016
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 559A912D957 for ; Fri, 27 May 2016 03:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level: 
X-Spam-Status: No, score=-15.947 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=-1.426, 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 cppFO_ia_Pdp for ; Fri, 27 May 2016 03:56:59 -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 1A81712D94C for ; Fri, 27 May 2016 03:56:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1678; q=dns/txt; s=iport; t=1464346619; x=1465556219; h=to:from:subject:message-id:date:mime-version; bh=UxylJwefo7faagPMZr6Yyxm6wfvi2FAVzkKpez1IXyg=; b=g4jyRLJicyrV1qC7jQXVhVdFr44P0XPWonfsTmcdiX3Ju9IDDLuEfrIO XLsIM8gfsDFrPpbwFg8fDufpHDlP/YfzUjG0Kps4JKtFS4DQpG8Jcut4q OLOZSA+L7E7mGs74XXrX3M/x+vEkOeWdQNXgiM1bI+7l6XsGpfEzkTI+Y 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgCXJ0hX/xbLJq1chA8rUrR2gmqCD?= =?us-ascii?q?wENgXgih2QUAQEBAQEBAWUnhDozdAE+Al8NCAEBiCsOolSPYpFJAQEBBwEBAQE?= =?us-ascii?q?eBYYngXYIig6CWQWYN44giUGFW49MHgEBQoNvOjIBigcBAQE?=
X-IronPort-AV: E=Sophos;i="5.26,373,1459814400";  d="scan'208,217";a="677409024"
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; 27 May 2016 10:56:45 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4RAuiTb007304 for ; Fri, 27 May 2016 10:56:44 GMT
To: NETMOD Working Group 
From: Benoit Claise 
Message-ID: <7156655b-270d-1022-dc13-fbeb7e74088e@cisco.com>
Date: Fri, 27 May 2016 12:56:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------C88BE339CE936FE97CFA9564"
Archived-At: 
Subject: [netmod] IETF Hackathon in Berlin: YANG/NETCONF/RESTCONF
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 May 2016 10:57:04 -0000

This is a multi-part message in MIME format.
--------------C88BE339CE936FE97CFA9564
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

If you start planning your trip to the Berlin IETF now, you might 
consider participating to the IETF Hackathon.
We had some good success at thelast IETF 
, and we 
want to repeat the experience.

See https://www.ietf.org/hackathon/96-hackathon.html for the detail, and 
let me know which YANG/NETCONF/RESTCONF projects you want to work on.

Regards, Benoit





--------------C88BE339CE936FE97CFA9564
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
Dear all,

    
If you start planning your trip to the Berlin IETF now, you might
      consider participating to the IETF Hackathon. 

      We had some good success at the
        last IETF, and we want to repeat the experience.

    

    
See https://www.ietf.org/hackathon/96-hackathon.html for the
      detail, and let me know which YANG/NETCONF/RESTCONF projects you
      want to work on.

    
Regards, Benoit

    

    


    

    


    

    


    

  


--------------C88BE339CE936FE97CFA9564--


From nobody Fri May 27 04:19:19 2016
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 3B7E512DB52 for ; Fri, 27 May 2016 04:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 TXu1KkRMqtPB for ; Fri, 27 May 2016 04:19:11 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CC01412DBA5 for ; Fri, 27 May 2016 04:19:10 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C3431AE018A; Fri, 27 May 2016 13:19:08 +0200 (CEST)
Date: Fri, 27 May 2016 13:19:29 +0200 (CEST)
Message-Id: <20160527.131929.1812148086072125780.mbj@tail-f.com>
To: worley@ariadne.com
From: Martin Bjorklund 
In-Reply-To: <87mvndfql5.fsf@hobgoblin.ariadne.com>
References: <20160523.154309.848500367505009627.mbj@tail-f.com> <877feyrdz9.fsf@hobgoblin.ariadne.com> <87mvndfql5.fsf@hobgoblin.ariadne.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 May 2016 11:19:17 -0000

Hi,

worley@ariadne.com (Dale R. Worley) wrote:
> Martin Bjorklund  wrote on Mon, 23 May 2016 15:43:09 +0200 (CEST):
> > worley@ariadne.com (Dale R. Worley) wrote:
> 
> Almost all of these points I'm happy with the authors fixing in the
> manner they suggest.  The points where I have further comment are:
> 
> > > The incompatibilities should be marked whether the old, incompatible
> > > usage always causes an error "at compile time", "at run time", or
> > > changed behavior.
> > 
> > Ok, but I'd like to avoid the term "compile-time" here.
> 
> True...  The distinction I'm looking for is "Incompatible usage will
> cause an error report before the software is put into operation."
> vs. "Incompatible usage will cause an error report when the software is
> in operation." vs. "Incompatible usage will cause a difference in
> behavior without an error report."

The spec defines what is legal YANG.  How this is enforced by tools
must be up to the tools, right?

> > How about:
> > 
> >    The following changes are not backwards compatible with YANG version
> >    1:
> > 
> >    o  Changed the rules for the interpretation of escaped characters in
> >       double quoted strings.  This is an backwards incompatible change
> >       from YANG version 1.  A module that uses a character sequence that
> >       is now illegal must change the string to match the new rules.  See
> >       Section 6.1.3 for details.
> > 
> >    o  An unquoted string cannot contain any single or double quote
> >       characters.  This is an backwards incompatible change from YANG
> >       version 1.  A module that uses such quote characters must change
> >       the string to match the new rules.  See Section 6.1.3 for details.
> 
> I assume that the first two situations will cause an error report before
> the module is put into production.
> 
> >    o  Made noncharacters illegal in the built-in type "string".  This
> >       change affects the run-time behavior of YANG-based protocols.
> 
> What happens if you attempt to use a noncharacter in a string?

This depends on the protocol.  noncharacters are illegal.  Maybe in
protocol A you can't even encode noncharacters, but in protocol B
you'll get a protocol error from the other side if you send
noncharacters.

> > >    o  leaf: A data node that exists in at most one instance in the data
> > >       tree.  A leaf has a value but no child nodes.
> > > 
> > > I'm not sure that this is correct; a leaf schema node inside a list
> > > schema node can have many instances in a data tree.  The real
> > > criterion is that it has a value but no child nodes.
> > 
> > Would "one instance per parent node" work?
> 
> I think that's correct.  The case I would expect to be tricky is be a
> leaf contained in a list, but the XML for lists wraps an element around
> each list member, so each leaf has "one instance per parent node".

Maybe "one instance per parent instance"?  Put into context:

  - container: An interior data node that exists in at most one
    instance per parent instance in the data tree. 

etc.

> It might be worth inserting a definition of "node" as shorthand for
> "data node", as there seems to be no definition of "node" alone, but it
> is commonly used to mean "data node".  In particular, the reader needs
> to be fully aware that "node" is a node in the schema tree, not an
> instantiation thereof.

But saying that "node" means "data node" is not correct.  Sometimes
the text talk about "schema nodes" etc.  I think it is better to
qualify the usage of "node" where necessary to avoid the ambiguity.

> > > It would be useful to insert a note somewhere that all data is either
> > > "configuration" or "state" data.  It's hard to learn that now, because
> > > the terms "configuration data" and "state data" are defined only by
> > > reference to RFC 6241.
> > 
> > But this is not strictly correct.  For example RPC input is neither
> > config nor state.  Section 3 has:
> > 
> >   o data tree: An instantiated tree of any data modeled with YANG,
> >     e.g., configuration data, state data, combined configuration and
> >     state data, RPC or action input, RPC or action output, or
> >     notification.
> 
> Section 4.1 contains a similar statement.
> 
> I think the problem I'm having is with the first sentences of 4.2.3:
> 
>    YANG can model state data, as well as configuration data, based on
>    the "config" statement.
> 
> At first read, this suggests that data is partitioned into
> "configuration data" and "state data".  What's really happening is that
> there are various sorts of data, but some contexts admit a mixture of
> configuration and state data, so the data model definitions of those
> contexts requires that individual data items can be flagged as
> configuration vs. data.  Maybe starting 4.2.3 like this would work:
> 
>    In some contexts, data modeled by YANG can contain mixtures of state
>    data and configuration data, based on the "config" statement.  When a
>    node is tagged with "config false", its subhierarchy is flagged as
>    state data.

I think that this might be a bit confusing (which contexts?  what
exacyly is this mixture?) and too detailed for this introductory
section.   I would perfer to keep the original text.

> > > - section 4.2.7
> > > 
> > >    YANG allows the data model to segregate incompatible nodes into
> > >    distinct choices using the "choice" and "case" statements.  The
> > >    "choice" statement contains a set of "case" statements that define
> > >    sets of schema nodes that cannot appear together.  Each "case" may
> > >    contain multiple nodes, but each node may appear in only one "case"
> > >    under a "choice".
> > > 
> > >    When a node from one case is created in the data tree, all nodes from
> > >    all other cases are implicitly deleted.  The server handles the
> > >    enforcement of the constraint, preventing incompatibilities from
> > >    existing in the configuration.
> > > 
> > >    The choice and case nodes appear only in the schema tree but not in
> > >    the data tree.  The additional levels of hierarchy are not needed
> > >    beyond the conceptual schema.
> > > 
> > > This description reads very oddly.  AFAICT, "choice" simply defines a
> > > union type, where each alternative is a container (usually called a
> > > structure or record).  Or rather, it's conceptually a container, but
> > > in an XML instance of data, there is no start-end tags for the
> > > structure as a whole (paralleling the lack of start-end tags for lists
> > > as a whole).  Once you state that, it's clear why there are "sets of
> > > schema nodes that cannot appear together".
> > 
> > I'm worried that if we describe "case" as a special kind of
> > "container" it will be pretty confusing.
> 
> Perhaps so.  But it seems to me that it needs to be pointed out that the
> "choice" and "case" are not materialized as XML nodes themselves; you
> can only tell which case is present by the fact that one or more of its
> elements are present.  Hmmm...  The third paragraph says that, more or
> less.  I think the second paragraph would be clearer if the third
> paragraph was moved before it, and some text added:
> 
>    The choice and case nodes appear only in the schema tree but not in
>    the data tree.  The additional levels of hierarchy are not needed
>    beyond the conceptual schema.  >>The presence of a case is indicated by
>    the presence of one or more of the nodes within it.<<
> 
>    When a node from one case is created in the data tree, all nodes from
>    all other cases are implicitly deleted.  The server handles the
>    enforcement of the constraint, preventing incompatibilities from
>    existing in the configuration.

Ok.

> > > - section 4.2.8
> > > 
> > > It would help to give a general discussion of augmenting.  If one
> > > module augments another, is the augmented data definition part of the
> > > data structures defined by augmenting module or the augmented one?
> > > 
> > > If I've got it right, this module:
> > > 
> > >    module /system/login/user {
> > >      namespace "urn:user";
> > >      prefix "user";
> > > 
> > >      list user {
> > >        key "name";
> > >        leaf name {
> > >          type string;
> > >        }
> > >        leaf full-name {
> > >          type string;
> > >        }
> > >        leaf class {
> > >          type string;
> > >        }
> > >      }
> > >    }
> > > 
> > > gives this as the XML encoding of a typical data tree:
> > > 
> > >      
> > >        alicew
> > >        Alice N. Wonderland
> > >        drop-out
> > >        1024
> > >      
> > 
> > Did you mean:
> > 
> >       
> >         alicew
> >         Alice N. Wonderland
> >         drop-out
> >       
> > 
> > ?
> 
> Yes, I made a mistake there.  (I must have.)
> 
> > > whereas the *existence* (in some sense) of this module:
> > > 
> > >    module /system/login/user-augmenter {
> > >      namespace "urn:user-extension";
> > >      prefix "ext";
> > > 
> > >      augment /system/login/user {
> > >        when "class != 'wheel'";
> > >        leaf uid {
> > >          type uint16 {
> > >            range "1000 .. 30000";
> > >          }
> > >        }
> > >      }
> > >    }
> > > 
> > > changes the encoding of the data tree to:
> > > 
> > >      
> > >        alicew
> > >        Alice N. Wonderland
> > >        drop-out
> > >        1024
> > >      
> > > 
> > > What is it that triggers this action-at-a-distance?
> > 
> > The fact that the server implements both modules.
> 
> It might be helpful to state that explicitly.  Could we add to the
> second paragraph of 4.2.8 this:
> 
>    (( The "augment" statement defines the location in the data model
>    hierarchy where new nodes are inserted, and the "when" statement
>    defines the conditions when the new nodes are valid. ))  When a
>    server implements a module containing an "augment" statement, that
>    implies that the server's implementation of the augmented module
>    contains the additional nodes.

Ok.

> > > - section 5.1.2
> > > 
> > >    YANG allows modeling of data in multiple hierarchies, where data may
> > >    have more than one top-level node.  Models that have multiple top-
> > >    level nodes are sometimes convenient, and are supported by YANG.
> > > 
> > > Any single module seems to define only one data structure, the one
> > > whose elements are the items listed in the module, and Yang doesn't
> > > seem to provide for any sort of "model" definition other than a
> > > module.  Or are the nodes at the top level within the module all
> > > usable as independent data structures?
> > 
> > The term "data structure" isn't used in the document.  YANG allows
> > a module to define more than one subtree.
> 
> OK, I think I see where I was confused.  I think that would have been
> avoided if the 5.1.2 started:
> 
>    YANG allows modeling of data in multiple hierarchies.  Each top-level
>    data node in a module defines an independent hierarchy.  Models that
>    have ...

What does "independent" imply?  They are not necessarily semantically
independent.  Maybe s/independent/separate/ ? 

> > >    NETCONF is capable of carrying any XML content as the payload in the
> > >     and  elements.  The top-level nodes of YANG modules
> > >    are encoded as child elements, in any order, within these elements.
> > > 
> > > This isn't very clear.  AFAICT from the example:
> > > 
> > >    NETCONF  and  elements each contain sequences of
> > >    instances of top-level nodes of the appropriate YANG module.
> > 
> > I am not sure that this proposed text is more clear, maybe b/c I don't
> > see what in the original text is unclear.
> 
> See the preceding item for what I think the problem is.
> 
> > > Given that this example is about a particular module, it would help if
> > > the module namespace and prefix was used correctly in the XML example.
> > 
> > I think the example uses the XML namespace correctly.
> 
> What I was noticing is that the module statement starts:
> 
>      module example-config {
>        yang-version 1.1;
>        namespace "urn:example:config";
>        prefix "co";
> 
>        container system { ... }
>        ...
> 
> And the XML starts:
> 
>                 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
>           xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
>        
>          
>            
>          
>          
>            
>              
>              ...
> 
> But it seemed to me that the recommended style for the XML has the
> specified prefix "co" used on the data nodes defined in the module:
> 
>            ...
>            
>              
>              ...
> 
> Looking again at 7.1.4 and the examples, it seems that the style of the
> examples is to use an XMLNS prefix only when a data node is from a
> different namespace than the top-level node containing it, i.e., data
> nodes with imported definitions.  I was expecting to see prefixes used
> even for non-imported data nodes.  But reading 7.1.4 suggests that I am
> incorrect there.

We don't make any recommendation on using explicit prefixes or default
namespace.

> > > - section 5.2
> > > 
> > >    YANG modules and submodules are typically stored in files, one module
> > >    or submodule per file.
> > > 
> > > This might be clearer as "... one module or submodule statement per
> > > file."
> > 
> > How is "one module per file" interpreted differently than "one module
> > statement per file"?
> 
> The problem is that "module" is ambiguous.  One meaning is the
> collection of all data definitions that are usable in the NETCONF
> operations.  The other is the contents of the module statement.  In a
> sense, module (1) = module (2) plus zero or more submodules.

Ok, I see what you mean.  This makes sense.  I'll change to "one
module or submodule statement".

> See this in 4.2.1:
> 
>    A module may be divided into submodules, based on the needs of the
>    module owner.  The external view remains that of a single module,
>    regardless of the presence or size of its submodules.
> 
> So one could read the current sentence as meaning that a file could
> contain a module (1) statement and all of the submodule statements that
> are included by the module (1) statement, and so the contents of the
> file as a whole constitutes a module (2).  The question is, does one
> module (1) go in a file, or one module (2) go in a file?
> 
> > >    XML namespaces for private modules are assigned by the organization
> > >    owning the module without a central registry.  Namespace URIs MUST be
> > >    chosen so they cannot collide with standard or other enterprise
> > >    namespaces, for example by using the enterprise or organization name
> > >    in the namespace.
> > > 
> > > I don't see the use of "without a central registry"; haven't you
> > > already said the module is is private?  (Or is "without a central
> > > registry" a term of art?)
> > 
> > It could be that all namespaces had to be registered with IANA for
> > example.
> 
> I guess I consider that namespaces registered with IANA or another
> organization are the uncommon case.  But perhaps in network management
> the reverse is the case.

The text simply says that a central registry is not needed.  It seems
you agree with this.

> > > - section 5.5
> > > 
> > > This section talks a great deal about why scoping is done, but isn't
> > > specifically clear what the rules are.  (Traditionally, the rule is
> > > stated as either what range of source text a particular definition is
> > > visible in, or given an identifier use, how the matching definition is
> > > found.)
> > > 
> > >    Scoped definitions MUST NOT shadow definitions at a higher scope.  A
> > >    type or grouping cannot be defined if a higher level in the schema
> > >    hierarchy has a definition with a matching identifier.
> > > 
> > > I think the second sentence is confusing, because (to me) the term
> > > "schema hierarchy" implies the data tree structure, whereas the
> > > scoping rule seems to be intended to be entirely lexical.  In either
> > > case, this needs to be clarified.
> > 
> > The first sentence says:
> > 
> >   Typedefs and groupings may appear nested under many YANG statements,
> >   allowing these to be lexically scoped by the hierarchy under which
> >   they appear.
> > 
> > Maybe it would help to move paragraph 2 and 3 to the end, so that the
> > motivational text is at the end of the section?
> 
> It looks like current paragraphs 1, 4, and 5 are prescriptive, and 2 and
> 3 are motivational.  Putting 1, 4, and 5 together should make them
> clearer.  But since paragraph 2 starts with "Scoping...", it really
> needs to be after 1.  So, yes, moving 2 and 3 to the end seems like the
> clearest order.  Does it make sense to you to put all of the motivation
> at the end of this section?

I prefer to have motivational text before the rules ("why" before
"how").  Hmm.  The preferred order is "what", "why", "how", and that
is really the order we currently have (1 is "what", 2 + 3 is "why" and
4 +5 is "how").

But obviously this was confusing to you, so we probably need to make
some clarification.

Since the problem was with the term "schema hierarchy", maybe we could
change this to "statement hierarchy" instead, to stress the fact that
it is lexical scoping?

[sorry for missing your original point]

> > > - section 5.6.5
> > > 
> > > I suspect that if a server implements module A, and A imports B, the
> > > server is not required to implement B.  (Even if A references
> > > groupings in B.)  The answer to that should probably be stated
> > > explicitly.
> > 
> > It is not so simple.  The rest of the text defines the rules for when
> > the server is required to implement B.
> 
> Yes, I was wrong there.  (I can't see why I made that mistake.)
> 
> > > Is this the correct way to specify multiple revisions of this module?
> > > Or is this an informal notation for the two module definitions:
> > > 
> > >      module b {
> > >        yang-version 1.1;
> > >        namespace "urn:example:b";
> > >        prefix "b";
> > > 
> > >        revision 2015-04-04;
> > >        revision 2015-01-01;
> > > 
> > >        typedef myenum {
> > >          type enumeration {
> > >            enum zero; // added in 2015-01-01
> > >            enum one;  // added in 2015-04-04
> > >          }
> > >        }
> > > 
> > >        container x {  // added in 2015-01-01
> > >          container y; // added in 2015-04-04
> > >        }
> > >      }
> > > 
> > >      module b {
> > >        yang-version 1.1;
> > >        namespace "urn:example:b";
> > >        prefix "b";
> > > 
> > >        revision 2015-01-01;
> > > 
> > >        typedef myenum {
> > >          type enumeration {
> > >            enum zero; // added in 2015-01-01
> > >          }
> > >        }
> > > 
> > >        container x {  // added in 2015-01-01
> > >        }
> > >      }
> > > 
> > > If it is the latter, it would help the new reader to explain the
> > > convention (as no example of a multi-revision module is given in the
> > > document).
> > 
> > The comments are not required.  There is no correct (mandated) way to
> > specify which changes are done in a new revision.
> 
> What I was concerned with is what does the above module statement do?
> If I understand correctly, it defines the 2015-04-04 revision of b, and
> also tells us that a 2015-01-01 revision exists, but does not define
> that revision.  Implicitly, there must be a .yang file somewhere
> containing the module statement that defines the 2015-01-01 revision of
> b.
> 
> But despite that the text talks about the 2015-01-01 revision ('can
> implement revision "2015-01-01" or "2015-04-04" of module "b"'), that
> file is not included in the example, which is not what I expected, which
> led me to wonder if the 2015-01-01 revision was somehow also defined by
> the presented "module b" statement.  I would have had less trouble with
> the example if the definition of the earlier revision of b was also
> given.

Ok, I see what you mean.  This makes sense.  I'll add 

  module b {
    yang-version 1.1;
    namespace "urn:example:b";
    prefix "b";

    revision 2015-01-01;

    typedef myenum {
      type enumeration {
        enum zero;
      }
    }

    container x {
    }
  }

and

  module c {
    yang-version 1.1;
    namespace "urn:example:c";
    prefix "c";

    revision 2015-02-02;

    typedef bar {
      ...
    }
  }


to the example.


> > > - section 6
> > > 
> > >    YANG modules use the UTF-8 [RFC3629] character encoding.
> > > 
> > > Better to say that YANG modules use the Unicode character set and are
> > > stored in files using the UTF-8 character encoding.
> > 
> > Do you mean:
> > 
> > OLD:
> > 
> >    YANG modules use the UTF-8 [RFC3629] character encoding.
> > 
> >    Legal characters in YANG modules are the Unicode and ISO/IEC 10646
> >    [ISO.10646] characters, including tab, carriage return, and line feed
> >    but excluding the other C0 control characters, the surrogate blocks,
> >    and the noncharacters.  The character syntax is formally defined by
> >    the rule "yang-char" in Section 14.
> > 
> > NEW:
> > 
> >    Legal characters in YANG modules are the Unicode and ISO/IEC 10646
> >    [ISO.10646] characters, including tab, carriage return, and line feed
> >    but excluding the other C0 control characters, the surrogate blocks,
> >    and the noncharacters.  The character syntax is formally defined by
> >    the rule "yang-char" in Section 14.
> > 
> >    YANG modules and submodules are stored in files using the UTF-8
> >    [RFC3629] character encoding.
> 
> Yes, that's right.

Ok, fixed.

> > > This might be a good place to talk about line-breaks in Yang source
> > > files.  It looks from section 14 that line-breaks MUST be either CRLF
> > > or LF.
> > > 
> > > It is worth noting (either here or in 6.1.3) how line-breaks inside
> > > quoted strings are transcribed into the string's value.  As now
> > > written, it seems that the line-break is transcribed identically to
> > > how it is represented in the source.  That means (1) If the source is
> > > recoded with the other type of line break, the semantics of the Yang
> > > code change; and (2) if the source uses line-breaks of one type (CRLF
> > > or LF), only that type can be directly transcribed into string values.
> > > (But regardless of the source line-breaks, an LF can be transcribed
> > > into a double-quoted string with "\n".  But a CRLF cannot be
> > > transcribed into a double-quoted string with escape sequences.  Was
> > > that intended, or was "\r" intended to be legal?)
> 
> Don't forget this.

Adding "\r" would be backwards incompatible with YANG 1.  You can
always get the same effect by using single quoted strings.

> > > - section 6.1
> > > 
> > >    This section details the rules for recognizing tokens from an input
> > >    stream.
> > > 
> > > Generally, language definitions intersperse the narrative text with
> > > the relevant grammar definitions.  Yang's statement grammar is simple
> > > enough that one doesn't need to see the context-free part of the
> > > grammar to understand the narrative for statements.  But when reading
> > > about tokenization, not having the grammar presented at the same time
> > > is quite a burden.  I'd recommend duplicating the relevant productions
> > > from section 14 into the subsections of section 6.
> > > 
> > > There is some sort of exposition problem.  The result of
> > > "tokenization" is that the sequence of characters of the source is
> > > converted into a sequence of "tokens".  Then some subset of the tokens
> > > is discarded as being non-significant (e.g., whitespace and comments),
> > > and the remainder is parsed with a context-free grammar.  Here I can't
> > > figure out what the set of tokens is.  Looking at the grammar in
> > > section 14, it seems to be a context-free grammar on characters.  But
> > > that implies that there is no separate tokenization phase.
> > > 
> > > An example that shows the problems:
> > > 
> > >    mod:ext
> > > 
> > > Is this one token, which is also an extension keyword, or is it a
> > > sequence of three tokens?
> > 
> > The text says:
> > 
> >   A token in YANG is either a keyword, a string, a semicolon (";"), or
> >   braces ("{" or "}").
> > 
> > and:
> > 
> >   A keyword is [...] or a prefix identifier, followed by a colon
> >   (":"), followed by a language extension keyword.
> > 
> > So "mod:ext" is one token.
> 
> Certainly it can be one token.  My question is how do verify that it is
> not a string?  I think that may be the origin of my confusion here is
> that I haven't spotted a clear syntax for unquoted string.  In most
> programming languages, mod:ext would be parsed as an identifier, a
> colon, and an identifier.  In YANG, identifiers are usually tokenized as
> strings, so I ask whether YANG tokenizes it as a string, a colon, and a
> string.
> 
> Looking at the beginning of 6.1.3, it doesn't appear that an unquoted
> string is forbidden from containing a colon.
> 
> I think that the underlying problem is that I'm not clear on what gets
> tokenized as an unquoted string.

Note that this is legal YANG:

   leaf type {
     type string;
   }
     
I think there are two ways to look at this.  Either we describe the
tokenizer as being context-dependent, or we describe the "argument" in
a "statement" to be a "string or keyword".

In the latter case maybe we can do:

OLD:

  If a string contains any space, tab, or newline characters, a single
  or double quote character, a semicolon (";"), braces ("{" or "}"),
  or comment sequences ("//", "/*", or "*/"), then it MUST be enclosed
  within double or single quotes.

NEW:

  An unquoted string is any sequence of characters that does not start
  with a double or single quote character, is not a keyword, and does
  not contain any space, tab, or newline characters, a single or
  double quote character, a semicolon (";"), braces ("{" or "}"), or
  comment sequences ("//", "/*", or "*/").

In section 6.3 we must also do:

OLD:

   The argument is a string, as defined in Section 6.1.2.

NEW:

   The argument is a string or a keyword, as defined in Section 6.1.2.



> > > -- it must be an unquoted string.
> > > 
> > >    If a double-quoted string contains a line break followed by space or
> > >    tab characters that are used to indent the text according to the
> > >    layout in the YANG file, this leading whitespace is stripped from the
> > >    string, up to and including the column of the double quote character,
> > >    or to the first non-whitespace character, whichever occurs first.  In
> > >    this process, a tab character is treated as 8 space characters.
> > > 
> > > This description isn't quite careful enough.  Better:
> > > 
> > >    If a double-quoted string contains a line break followed by space or
> > >    tab characters, an initial part of this whitespace is removed from the
> > >    string.  The amount removed is the longest prefix whose width is no
> > >    larger than the width of the prefix of Yang source line containing
> > >    the opening double quote character of the string to and including the
> > >    opening double quote character.  For this purpose, the width of a
> > >    tab character is 8 and the width of any other character is 1.
> > > 
> > > This does assume that all tabs are considered to have width 8, that
> > > is, tabs do not have the usual semantics of "advance to the next
> > > column that is divisible by 8".  That will sometimes cause unexpected
> > > results, e.g., if some source lines start with SPC TAB.  (Consider
> > > that whitespace before a line break is removed, which suggests the
> > > intention is that the value of the string should depend only on its
> > > visual appearance.)
> > > 
> > > Also, we're using the convention that "whitespace" does NOT include CR
> > > or LF, which is not always how the term is used.  Perhaps a definition
> > > of "whitespace" should be put in section 3.
> > > 
> > > There is also the special case:
> > > 
> > >    SPC " LF
> > >    TAB x "
> > > 
> > > Is the initial TAB of the second line to be removed or not?  There is
> > > no whitespace removal in the second line that will exactly reach the
> > > opening double quote.  As I've written it, the TAB is not removed.
> 
> Don't forget this ugly special case.

So, let's follow the rules.  We need to trim to the column of the
double quote character (2).  The second line starts with "space or
tab" so we do whitespace trimming, while treating the tab as 8
spaces.  So from 8 spaces we subtract 2, and get the resulting string
of 6 characters:

  LF SPC SPC SPC SPC SPC SPC x

> > >    Within a double-quoted string (enclosed within " "), a backslash
> > >    character introduces a special character, which depends on the
> > >    character that immediately follows the backslash:
> > > 
> > > s/introduces a special character/introduces a representation of a
> > > special character/
> > 
> > Hmm.  I think the original text is correct.  In the string "x\ny", the
> > backslash introduces the LF character into the string.  What is the
> > representation of LF that it would introduce?
> 
> I would call the character pair \n a "representation" of LF, and the
> first character of that pair, \, "introduces" the representation, in the
> sense "to make (something) known by formal announcement or
> recommendation", because it is the distinctive first character of the
> representation.  There may be an ambiguity in that "introduce" can also
> be used to mean "to add (something) to a system, a mixture, or a
> container", in this case, "to put a newline character into the
> string".

Ok, this makes sense.  I'll do the substituion you suggested

s/introduces a special character/introduces a representation of a
special character/


> > > - section 7.7.2
> > > 
> > > It appears to be assumed that the server's behavior is the same if (1)
> > > a leaf-list node is specified with zero values, and (2) if the
> > > leaf-list node is absent and has no default values.
> > > 
> > >    Otherwise, if the leaf-list's type has
> > >    a default value, and the leaf-list does not have a "min-elements"
> > >    statement with a value greater than or equal to one, then the leaf-
> > >    list's default value is the type's default value.  In all other
> > >    cases, the leaf-list does not have any default values.
> > > 
> > > I think it would help to s/the type's default value/one instance of
> > > the type's default value/.
> > 
> > I don't understand why this is better?
> 
> If I have an integer leaf, then values of the leaf are integers and it's
> proper to say that the default value of the leaf is 1.  But if I have an
> integer leaf-list, the values of the leaf-list are sequences of
> integers, and it's not quite proper to say that the default value of the
> leaf-list is the integer 1; properly said, the default value is a
> sequence containing one integer, which integer is 1 -- a sequence
> containing one item is not the same as the one item.

Ok; I read your propsal as "an instance of" rather than "one instance
of".  I'll make this change.

> > > Is the final condition correct?  E.g., if the leaf-list's type has a
> > > default value, and it has a min-elements with value 2, then the
> > > leaf-list has no default values
> > 
> > Correct.
> > 
> > > -- which is invalid.
> > 
> > I don't understand what you mean?  An exmaple is this:
> > 
> >   typedef foo {
> >     type int32;
> >     default 42;
> >   }
> > 
> >   leaf-list bar {
> >     type foo;
> >     min-elements 1;
> >   }
> > 
> > In this example, "bar" doesn't have a default value - since
> > min-elements means that the user MUST provide at least one value, and
> > the default value is only used if no value has been provided.
> 
> Let me run though the cases and you can check that I understand them
> correctly:
> 
>    leaf-list bar {
>      type foo;
>    }
>    -or-
>    leaf-list bar {
>      type foo;
>      min-elements 0;
>    }
> 
> The default value is one instance of 42.  If the data tree doesn't
> supply a value, the effect is the same as 42.
> 
>    leaf-list bar {
>      type foo;
>      min-elements 1;
>    }
> 
> There is no default value.  If the data tree doesn't supply a value,
> then no values are implied.  But that violates the restriction, so the
> data tree must supply one or more values -- if there are no values, that
> violates the restriction and the data tree is invalid.
> 
> Am I correct?

Yes.

> > > - section 7.7.7.1
> > > 
> > >    The entries in the list are sorted according to an order determined
> > >    by the system.  The "description" string for the list may suggest an
> > >    order to the server implementor.  If not, an implementation is free
> > >    to sort the entries in the most appropriate order.
> > > 
> > > This is mealy-mouthed about what is required and what is recommended.
> > > Better would be to omit "If not, an implementation is free to sort the
> > > entries in the most appropriate order."
> > 
> > I think the last sentence makes it clear that there you cannot assume
> > anything about the order, e.g., that a list that has an int32 as the
> > key is sorted in numerical order.
> 
> I guess what is bothering me is "appropriate", which to me implies that
> there is some standard of appropriateness.  I think I would prefer "to
> sort the entries in any order".

Ok.

> Actually, there is a somewhat subtle problem:  If I say "the system can
> sort them any way it wants", I am asserting that *there is a sorting
> order*.  Which means that if value A is put before value B at one time,
> then if values A and B are in the list at some other time, A will
> precede B.

The next sentences says:

  An implementation SHOULD use the same order for the same data,
  regardless of how the data were created.  Using a deterministic
  order will make comparisons possible using simple tools like "diff".

> I think the way to remove that implication is to replace "sort" with
> "order" -- a change which you devised for 7.7.7.2, I see:

Ok.  (To me, this means the same thing, and the repeated usage of
"order" makes the text a bit clumsy: "The entries in the list are
ordered according to an order defined by the user." -- but if you
think that the usage of "sort" is problematic, it is fine with me to
avoid that word.)

>     The entries in the list are ordered as determined by the system.
>     The "description" string for the list may suggest an order to the
>     server implementor.  But an implementation is free to sort the
>     entries in any other manner.
> 
> > > - section 7.7.7.2
> > > 
> > >    The entries in the list are sorted according to an order defined by
> > >    the user.  This order is controlled by using special XML attributes
> > >    in the  request.
> > > 
> > > Actually, the entries aren't "sorted", as there is no requirement that
> > > any particular set of values always has a particular order; the user
> > > can insert 1, 2, 3 at one time, and 3, 2, 1 at another.  The correct
> > > meaning is splicing these two sentences:
> > > 
> > >    The user orders entries in the list by using special XML attributes
> > >    in the  request.
> > 
> > I prefer to keep the second sentence, and actually modify it to be:
> > 
> >   In NETCONF, this order is controlled by using special XML attributes
> >   in the  request.
> 
> Ah, yes, of course that only applies in NETCONF.
> 
> > Would it help to s/sorted/ordered/ in the first sentence?
> 
> Yes, that is a definite improvement.
> 
> > > - section 7.9.5.  XML Encoding Rules
> > > 
> > >    The choice and case nodes are not visible in XML.
> > > 
> > > Use this sort of statement for lists and leaf-lists, which have no
> > > visible XML for the lists as a whole.
> > 
> > The current text says:
> > 
> >   A list is encoded as a series of XML elements, one for each entry in
> >   the list.
> > 
> > I think this text is clear.  I think it might be a bit confusing to
> > say that a list node is not visible in the XML - it is visible, per
> > entry.
> 
> My difficulty is that by default, I would expect that XML representing a
> "list of things" would have a pattern like
> 
>     
>         thing
>         thing
>         thing
>     
> 
> or perhaps 
> 
>     
>         ...
>         ...
>         ...
>     
>        
> whereas Yang uses
> 
>     ...
>     ...
>     ...
> 
> that is, there is an element for each list item, but not one for the
> list as a whole.  I don't know why I expect there to be an XML element
> that wraps the whole list, I suspect it is from my background in
> programming language theory.  OTOH, YANG seems to use the opposite
> convention of often avoiding XML elements to wrap aggregate types as a
> whole, and only having XML elements for the component data items.
> (Although containers have enwrapping XML elements.)
> 
> Perhaps this revision would work:
> 
>    A list is encoded as a series of XML elements, one for each entry in
>    the list.  There is no XML element surrounding the list as a whole.

Ok.

> > > - section 7.10
> > > 
> > >    The "anydata" statement is used to represent an unknown set of nodes
> > >    that can be modelled with YANG, except anyxml, ...
> > > 
> > > What is the practical consequence of this restriction?  It's not at
> > > all clear to me which chunks of XML could be modelled with Yang and
> > > which could not.
> > 
> > In practice, this means that if you see an instance of anydata, there
> > is a YANG model behind that chunk somewhere, although you might not
> > know what it is.  In an implementation it means you can use your
> > normal parser (which maybe doesn't handle mixed content and processing
> > instructions etc).
> 
> Ah, yes.  That last sentence is the practical consequence, and yes, it's
> directly implied by the text in the draft.
> 
> > > - section 7.12
> > > 
> > >    A grouping is like a "structure" or a "record" in conventional
> > >    programming languages.
> > > 
> > > Add, "... though no grouping node exists in the XML."
> > 
> > Since we try to decouple the defintion of the language from the
> > encodings, I'd prefer to not add this.
> 
> Yes...  What I'm talking about is actually the XML encoding of a uses
> statement.  7.13.3 specifies by omission that the XML for the set of
> nodes in the grouping is not wrapped in a "grouping" element.
>  
> > > - section 7.18
> > > 
> > > It would help to insert a discussion of the global purpose and use of
> > > identities.  In particular, what things can refer to them?  It looks
> > > like only identityref leafs can do so, but I could easily be wrong.
> > > Also, more discussion in the example (7.18.3) would be helpful.
> > > 
> > >    The "identity" statement is used to define a new globally unique,
> > >    abstract, and untyped identity.  Its only purpose is to denote its
> > >    name, semantics, and existence.
> > > 
> > > The two uses of "its" in the second sentence are ambiguous.  I think
> > > you mean "The statement's only purpose is to denote the identity's
> > > name, semantics, and existence."
> > 
> > No, rather "The identity's only purpose...".  The point is that this
> > just an abstract concept.
> 
> OK, but I think you may want to replace the first "Its" with "The
> identity's".

Ok.

> > > - section 7.21.4
> > > 
> > >    The "reference" statement takes as an argument a string ...
> > > 
> > > Perhaps s/a string/a human-readable string/.
> > 
> > "string" refers to the YANG token "string".  The same wording is used
> > across the document for all arguments.
> 
> I was thinking that it is a string, but in this particular case, it is
> supposed to be human-readable, whereas strings in other contexts aren't
> expected to be.

Ok.  Maybe:

OLD:

  The "reference" statement takes as an argument a string that is used
  to specify a textual cross-reference to an external document,

NEW:

  The "reference" statement takes as an argument a string that is used
  to specify a human-readable cross-reference to an external document,


> > > - section 7.21.5
> > > 
> > > Note that if a data definition has both an "if-feature" and a "when",
> > > then the "if-feature" is tested first.
> > > 
> > >    If the XPath expression references any node that also has associated
> > >    "when" statements, these "when" expressions MUST be evaluated first.
> > >    There MUST NOT be any circular dependencies in these "when"
> > >    expressions.
> > > 
> > > I think this could be better phrased:
> > > 
> > >    If the XPath expression references any node that also has
> > >    associated "when" statements, then the "when" expressions of the
> > >    referenced nodes MUST be evaluated first.  There MUST NOT be any
> > >    circular dependencies among "when" expressions.
> > 
> > Ok to the last sentence.  Do you think that the word "these" in the
> > first sentence is ambigious?
> 
> I must have thought it was unclear when I read it, otherwise I would not
> have suggested changing it.  But reading it again, I think that there is
> no ambiguity.  Perhaps it would be a little clearer to use 'those "when"
> expressions' rather than 'these "when" expressions'.  (I can't explain
> clearly why "those" seems less ambiguous than "these".)

Ok, as a non-native english speaker I trust you that "those" is better.

> > > - section 9.9
> > > 
> > >    The leafref type is used to declare a constraint on the value space
> > >    of a leaf, based on a reference to a set of leaf instances in the
> > >    data tree.  The "path" substatement (Section 9.9.2) selects a set of
> > >    leaf instances, and the leafref value space is the set of values of
> > >    these leaf instances.
> > > 
> > > The first sentence isn't quite right.  Perhaps:
> > > 
> > >    The value space of a leaf with leafref type is one of the values of
> > >    a set of leaf instances in the data tree.  The "path" substatement
> > >    (Section 9.9.2) selects the set of leaf instances, and the leafref
> > >    value space is the set of values of these leaf instances.
> > 
> > The point is that "leafref" introduces a constraint on valid data.
> > In for example the candidate configuration of NETCONF, it is ok if a
> > leafref leaf points to something that doesn't exist.  However it must
> > exist at commit-time.  See below.
> 
> Let me think this through...  Really, the leafref *type* has the same
> set of values as the type of the nodes its path selects (let's call it
> the base type), but it also has an attached constraint (which must be
> satisfied at the times specified in section 8).  In particular, you do
> not expect the constraint to be satisfied within the data tree of an
> RPC.

Yes.

> By implication, the leafref's value is considered to be a pointer to a
> particular leaf instance, the one with the matching value.  But that
> idea is not embedded in the Yang semantics of leafref types in any way
> (other than the output of the deref function), so the fact that there
> might be more than one matching leaf instance does not matter.
> 
> As stated in 9.9.4 and 9.9.5, the lexical representations of its values
> are the same as those of the referenced nodes.
> 
> How is the leafref's value compared to the values of the referenced
> nodes?  I can see that question getting ugly for the more complex types
> (e.g., anyxml)

You can't have a leafref to an anyxml node; just to a leaf or
leaf-list.

> which do not have canonical forms.  I suspect the
> intention is that values are equal if they have the same canonical form

No, the idea is that they are equal if their *value* is equal,
regardless of the lexical representation.

> -- and that only base types with canonical forms are allowed.
> 
> If I'm reading correctly, the constraint is only applied to
> configuration leafs which have require-instance=true.  Any other leafref
> leaf has no constraint (though its values are required to be compatible
> with the base type).  I'm not sure I'm reading this correctly,
> though.

This is correct.

> But look at the second paragraph of section 9.9:
> 
>    If the leaf with the leafref type represents configuration data, and
>    the "require-instance" property (Section 9.9.3) is "true", the leaf
>    it refers to MUST also represent configuration.  Such a leaf puts a
>    constraint on valid data.  All such nodes MUST reference existing
>    leaf instances or leafs with default values in use (see Section 7.6.1
>    and Section 7.7.2) for the data to be valid.  This constraint is
>    enforced according to the rules in Section 8.
> 
> The second sentence starts "Such a leaf puts a constraint ...".  But
> "such a leaf" must mean "the leaf with the leafref type represents
> configuration data, and the "require-instance" property (Section 9.9.3)
> is "true"".  I suspect that is not the intended meaning.
> 
> In 9.9.2,
> 
>    The "path" expression evaluates to a node set consisting of zero,
>    one, or more nodes.  If the leaf with the leafref type represents
>    configuration data, this node set MUST be non-empty.
> 
> This appears to be a constraint that applies even if
> require-instance=false.  Is that correct?  If so, it represents a
> constraint that is independent of the main constraint (that there is a
> leaf with a matching value), because that constraint is only effective
> if require-instance=true.  That probably should be mentioned in 9.9
> along with the other constraint.

Note that I started a ML thread for this issue
("leafref value space and constraint").

See more below.

> > > - section 9.9.3
> > > 
> > >    If "require-instance" is "true", it means that the instance being
> > >    referred MUST exist for the data to be valid.  This constraint is
> > >    enforced according to the rules in Section 8.
> > > 
> > >    If "require-instance" is "false", it means that the instance being
> > >    referred MAY exist in valid data.
> > > 
> > > What does "the instance being referred" mean?  Perhaps you meant "the
> > > instance being referred to"?
> > 
> > Yes.
> 
> I think this could be made clearer, because it's not quite right to say
> that "the XXX does not exist" -- if it doesn't exist, there is no "the
> XXX".  Perhaps,
> 
>     If "require-instance" is "true", it means that the value of the
>     leafref or instance-identifier leaf must equal the value of one of
>     the leafs in the set that the "path" expression evaluates to.  This
>     constraint is enforced according to the rules in Section 8.
>  
>     If "require-instance" is "false", it means that the value of the
>     leafref or instance-identifier leaf is not constrained in this way.
> 
> Though this constraint only applies if the leafref leaf is configuration
> data (per section 9.9), which limitation needs to be stated in this text
> also.
> 
> There seem to be significant differences between the application of
> require-instance to leafref types and instance-identifier types.  The
> general idea is similar, but the specific semantics are different to the
> point that the instance-identifier case might require a seperate
> statement.

I think the semantics is the same - in both cases you have a reference
to some other node.  The syntax is quite different, obviously.

> If I understand correctly, require-instance is a restriction, and so can
> be applied to a derived type which itself has a require-instance
> restriction.  Generally, that sort of restriction requires that the new
> restriction is compatible with the old one.  E.g., in 9.2.4:
> 
>    If a range restriction is applied to an already
>    range-restricted type, the new restriction MUST be equal or more
>    limiting, that is raising the lower bounds, reducing the upper
>    bounds, removing explicit values or ranges, or splitting ranges into
>    multiple ranges with intermediate gaps.
> 
> In the case of require-instance, the new restriction should presumably
> have the same value as that of the base type.  OTOH, that adds no
> expressive power, so perhaps applying a require-instance restriction to
> a derived type can be forbidden.  Or perhaps it is allowed to add
> require-instance=true to a base type with require-instance=false?  That
> override does make the type definition more restrictive, and so is
> compatible with the general idea of restrictions on derived types.

Yes; however, at least with the proposed changes, the *value space* is
the same, regardless of the value of "require-instance".  But setting
this changes the semantic constraints.  I agree that it is a bit
non-intuitive to allow relaxing of such a constraint, but this is how
it is done in YANG 1, so changing this would be backwards incompatible.

> OK, now back to what you said:
> 
> > Right; so what we want to say is:
> > 
> >   - the value space is the same as the value space of the referred
> >     leaf
> > 
> >   - there is an additional constraint if require-instance is true that
> >     the referred to leaf instance must exist
> > 
> > How about
> > 
> > OLD:
> > 
> >    The leafref type is used to declare a constraint on the value space
> >    of a leaf, based on a reference to a set of leaf instances in the
> >    data tree.  The "path" substatement (Section 9.9.2) selects a set of
> >    leaf instances, and the leafref value space is the set of values of
> >    these leaf instances.
> > 
> >    If the leaf with the leafref type represents configuration data, and
> >    the "require-instance" property (Section 9.9.3) is "true", the leaf
> >    it refers to MUST also represent configuration.  Such a leaf puts a
> >    constraint on valid data.  All such nodes MUST reference existing
> >    leaf instances or leafs with default values in use (see Section 7.6.1
> >    and Section 7.7.2) for the data to be valid.  This constraint is
> >    enforced according to the rules in Section 8.
> > 
> > NEW:
> > 
> >    The leafref type is used to declare a constraint on the value space
> >    of a leaf, based on a reference to a set of leaf instances in the
> >    data tree.  The "path" substatement (Section 9.9.2) is used to refer
> >    to another leaf node.  The leafref value space is the value space of
> >    this leaf node.
> > 
> >    If the "require-instance" property is "true", there MUST exist an
> >    instance, or a leaf with a default value in use (see Section 7.6.1
> >    and Section 7.7.2), of the leaf being referred to with the same value
> >    as the leafref value in a valid data tree.
> > 
> >    If the leaf with the leafref type represents configuration data, and
> >    the "require-instance" property (Section 9.9.3) is "true", the leaf
> >    it refers to MUST also represent configuration.
> 
> I think the first paragraph needs to also say that the leafref type is
> sort of a derived type of the type of the leaf node (which is in the
> schema).

The current proposed text is:

   The leafref type is restricted to the value space of some leaf or
   leaf-list node in the schema tree and optionally further restricted
   by corresponding instance nodes in the data tree.  The "path"
   substatement (Section 9.9.2) is used to identify the referred leaf or
   leaf-list node in the schema tree.  The value space of the referring
   node is the value space of the referred node.

   If the "require-instance" property (Section 9.9.3) is "true", there
   MUST exist an node in the data tree, or a node with a default value
   in use (see Section 7.6.1 and Section 7.7.2), of the referred schema
   tree leaf or leaf-list node with the same value as the leafref value
   in a valid data tree.

> "If the "require-instance" property is "true", there MUST exist ..." is
> really "If the "require-instance" property is "true", the constraint is
> that there MUST exist ...".
> 
> For section 9.9.6, I think "an existing address of an interface" was
> probably meant to be "the address of an existing interface".  Also,
> shouldn't there be require-instance restrictions in the example Yang
> code?
> 
>      container default-address {
>        leaf ifname {
>          type leafref {
>            path "../../interface/name";
> >>>	   require-instance true;

This is not necessary b/c the default is "true".

>          }
>        }
>        leaf address {
>          type leafref {
>            path "../../interface[name = current()/../ifname]"
>               + "/address/ip";
> >>>	   require-instance true;
>          }
>        }
>      }
> 
> > This needs to be verified on the ML (I'll start a separate thread for
> > this).
> 
> Yes...  I get the feeling that I still don't have an accurate
> understanding of what is intended.
> 
> > >    In the XML encoding, a value representing a union data type is
> > >    validated consecutively against each member type, in the order they
> > >    are specified in the "type" statement, until a match is found.  The
> > >    type that matched will be the type of the value for the node that was
> > >    validated.
> > > 
> > > I think a distinction needs to be made here between generating XML and
> > > interpreting XML:
> > > 
> > >    When generating an XML encoding, a value is encoded according to
> > >    the rules of the member type to which the value belongs.  When
> > >    interpreting an XML encoding, a value is validated consecutively
> > >    against each member type, in the order they are specified in the
> > >    "type" statement, until a match is found.  The type that matched
> > >    will be the type of the value for the node that was validated, and
> > >    the encoding is interpreted according to the rules for that type.
> > 
> > Yes, better, but I don't understand what value the last part of the
> > last sentence adds?
> 
> It makes explicit how the value is to be extracted from the encoding.

Fine.

> > > - section 10.3.1
> > > 
> > >    If the first argument node is of type leafref, the function returns a
> > >    node set that contains the nodes that the leafref refers to.
> > > 
> > > I *think* that this means the set of nodes that the leafref's XPath
> > > selects, but a plausible alternative is the subset of those nodes
> > > which have the same value as the leafref does.  This hinges on the
> > > meaning of "the leafref refers to a node", which isn't defined
> > > unambiguously in section 9.9.
> > 
> > It is the latter.  Howabout:
> > 
> > NEW:
> > 
> >    If the first argument node is of type leafref, the function returns
> >    a node set that contains the nodes that the leafref refers to.
> >    Specifically, this set contains the nodes selected by the leafref's
> >    "path" statement (Section 9.9.2) that has the same value as the
> >    first argument node.
> 
> Yes.  (Although "that has the same value" should be "that have the same
> value".)

Fixed.

> > >    instance-identifier-specification =
> > >                          [require-instance-stmt]
> > > 
> > > Why is require-instance-stmt in [...]?  The only use of
> > > instance-identifier-specification is in type-body-stmts, and the only
> > > use of type-body-stmts is in type-stmt, where it is in [...].  Compare
> > > with numerical-restrictions:
> > > 
> > >    numerical-restrictions = range-stmt
> > > 
> > > --
> > > 
> > >    binary-specification = [length-stmt]
> > 
> > You're right that it isn't necessary.  However, imo it is more clear;
> > in an instance-identifier spec require-instance is optional, but the
> > only numerical-restriction is range.
> 
> As far as I can see, numerical-restrictions, decimal64-specification,
> and numerical-restrictions are to be used similarly, as they are
> alternatives of type-body-statements.  But there seems to be no
> uniformity as to whether one of these alternatives can be empty:
> 
>    numerical-restrictions = range-stmt
> 
>    instance-identifier-specification =
>                          [require-instance-stmt]
> 
>    decimal64-specification = ;; these stmts can appear in any order
>                              fraction-digits-stmt
>                              [range-stmt]
> 
> It seems to me that whatever reasoning applies to whether range-stmt is
> optional within numerical-restrictions applies to require-instance-stmt
> within instance-identifier-specification.

You're right.  By this logic we should do:

OLD:

    numerical-restrictions = range-stmt

NEW:

    numerical-restrictions = [range-stmt]

> > > Similarly.
> > > 
> > >    quoted-string       = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)
> > > 
> > >    string              = < an unquoted string as returned by >
> > >                          < the scanner, that matches the rule >
> > >                          < yang-string >
> > > 
> > > The handling of "string" is hard to follow and/or inexact.  First, we
> > > need a term for the "value" of a string written in Yang source, so we
> > > can say
> > > 
> > >    prefix-arg-str      = < a string whose ??? matches the rule >
> > >                          < prefix-arg >
> > > 
> > > The text that is now used is not too difficult to understand, but it's
> > > inexact and makes it hard to write specifications about how the value
> > > is determined.
> > 
> > It's not clear to me which problem you want to solve, and also it's
> > not clear exactly what you propose.
> 
> I think the problem is that I don't see the rule for extracting unquoted
> strings from the Yang source.  Certainly, not all yang-string's can be
> written directly in the source as unquoted strings, not even all those
> that satisfy the constraint of 6.1.3, "If a string contains any space,
> tab, or newline characters, a single or double quote character, a
> semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*",
> or "*/"), then it MUST be enclosed within double or single quotes."
> 
> E.g., the null string matches yang-string, but it can't be written as an
> unquoted string at all (else tokenizing any source would be ambiguous).
> Similarly, mod:ext matches yang-string and is not required to be quoted
> by 6.1.3, but it seems that those characters in the source are not
> intended to be tokenized as a string.
> 
> > > (Also, there seem to be too many <...>, dividing the narrative text
> > > into two parts.  The natural way to write it would be:
> > > 
> > >    prefix-arg-str      = < a string whose ??? matches the rule
> > >                            prefix-arg >
> > 
> > Agreed, but LF isn't allowed in prose-val in ABNF (see RFC 5234).
> 
> Ah, I hadn't known that <...> was a defined usage.
> 
> > > We need a production that tells exactly the syntax of "an unquoted
> > > string as return by the scanner".
> > > 
> > > We also need productions for quoted strings.  I can reconstruct these:
> > > 
> > >    quoted-string       = (single-quoted-string / double-quoted-string)
> > >    		         *(optsep "+" optsep
> > >                              (single-quoted-string / double-quoted-string))
> > > 
> > >    single-quoted-string = SQUOTE *(yang-char excluding "'") SQUOTE
> > > 
> > > (I don't know a good way to exclude one character from a character set
> > > in ABNF.)
> > > 
> > >    double-quoted-string = DQUOTE *dq-char DQUOTE
> > > 
> > >    dq-char = yang-char excluding BACKSLASH and DQUOTE /
> > >              BACKSLASH ( "n" / "t" / DQUOTE / BACKSLASH )
> > > 
> > > Verify that "optsep" is what is allowed to appear around "+".
> > > 
> > > Needs a comment pointing to Section 6.1.3 as telling how to interpret
> > > quoted-strings.
> 
> The current ABNF doesn't allow for "+" for joining quoted strings.
> Also, it doesn't show that \" can be included in a double quoted string
> to include a literal ", and allows the string contents to continue --
> the current ABNF "DQUOTE string DQUOTE" matches "abcd\", despite that
> the latter is not a proper double-quoted string.

Note that the prose text (within <...>) says "a string that
matches...".  That string can be any YANG token string, for example
one of:

   "hello"
   "he" + "llo"


/martin


From nobody Fri May 27 10:35:26 2016
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 6C33012DBE6 for ; Fri, 27 May 2016 10:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 1HdMsn3x4tjR for ; Fri, 27 May 2016 10:35:15 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0098.outbound.protection.outlook.com [104.47.1.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CAC012DC19 for ; Fri, 27 May 2016 10:34:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=o74Q2C1rN3EhJQmfQjFfZIS0faU34nj7et/BjN94eX4=; b=NIpY2OB7n8ShpRDfbWQCJX5+Sxmhjpo9AsNMEPNLaPsOdSADO5f56jGmOnm+SoJpJE9jMyWYzrvdrWxbju6blkcVhUlVZLxN0rHWj48EdFpEHWv5S8DR+rXi/EXoWmpZgCZw/0szX9aIeSN1cm7RKxzsf5e2SgoO0LRPZI2rDH4=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com;
Received: from pc6 (109.145.193.232) by DB5PR07MB1621.eurprd07.prod.outlook.com (10.166.12.148) with Microsoft SMTP Server (TLS) id 15.1.501.7; Fri, 27 May 2016 17:34:24 +0000
Message-ID: <008201d1b83d$72f91f60$4001a8c0@gateway.2wire.net>
From: t.petch 
To: , Martin Bjorklund 
References: <20160523.161038.800274078120441332.mbj@tail-f.com>
Date: Fri, 27 May 2016 18:30:13 +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: [109.145.193.232]
X-ClientProxiedBy: DB3PR08CA0041.eurprd08.prod.outlook.com (10.161.51.179) To DB5PR07MB1621.eurprd07.prod.outlook.com (10.166.12.148)
X-MS-Office365-Filtering-Correlation-Id: 1c866ae4-de06-4367-7577-08d38655255b
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 2:YzDv3i2U59xGzRNkQZpbR9AOg35ejxU4KolA8YW7mC108o+oCPFFA6vrTsCr82qFrE9t9QQgnJWcYhYYiDtZJ3YqgJdI2I04lw2aq1dYoAxFbFEijGylsLVGTFq2j13088X4OmnEyaqj/wr4ziiHqECXMa6TEUWMKSaHFlq19E1r9uK5xdnhODqJ3P0m0Orn; 3:t8SVeMVGT4DUkIAs1PqnfJQDvbtRuX1K/yRIze7pOUHV6BSSpRx0js80KeyTsIjGO0rU9gfnWAWI71Qe3uJDp+5hQEMlI2aGO2yJaGH9wiI95D0djf5WpQ6bW7VY5sUL; 25:3Gy64CFlh794KgVcCtjNwWGK8aAwQrL4TFPo1vESIOp7HiRHUj3t9Cuup3tDPyJzl9yz4pB0FB0NsaxG5VALOiyIXnDUu6hKrZnpLg32E9OVOflPHgxVNs7Kfbl/GnNjSV1nlexl9ktkIRmChr+ICx78LTh8lqztRJeCVd+DCEjIPt380ksAS/GDt4iFLvB/m9imhollVGe6ZSsdXRGkTfOTwJBJ62iteFyTUIVnEBNuXL8j7bE2wpiVVaz1W/jRyVhPesFRRAV+1sfcIwLtBD9Pon2/WOYz5/vmtvZdUOkjYQo9wWyQVmgH0LuR3Xz/LeX5sc842Qo3FkYuBr+0U995X479z+Oboj1ES6/tqP+NGpgBL+JBt7V/hvnv1Q62mR1QEesPzNKbV+1TF5iEl0qlUNullOWNVviRrCc+x/Q=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1621;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB5PR07MB1621; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1621; 
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 4:yWydiu+viKf8+12qwRhbouducoZLePUngIrEu2KMhLdjnPiSYTsxlQxwUT/g8EaREKWkZR1pBs96kkvfWxNe6Qrw1orqM06geh1HYSrPRqQ81EjlspWXZQzpphtHuOULM/JyZZEr+MJ2wZ8OSU5sCJNT5B5nZj08qIBAwGJdp/8ln/0R9UthTM7SitvWPuvEFIz140w4+OAgSlVYjNK74CKaHPhLbEwTSxtewoINoWvNHxJ3UUohOvUBc5LnWVf2kBYmzZGFqGEuhfYTucWlBTu6ZyK1tSHAwyjDH6/VoQW+TnizhmC6do1WzXOu6Y6pl0t6Q+xNtfTdcss0m2x5dH1Bvsc8b0p2dNSnJHDyaW+GF0IDx33OIfOSPWWxASiE
X-Forefront-PRVS: 09555FB1AD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(51444003)(377454003)(13464003)(81816999)(230700001)(50466002)(47776003)(44736004)(5004730100002)(42186005)(44716002)(62236002)(66066001)(561944003)(19580395003)(19580405001)(81686999)(9686002)(76176999)(586003)(6116002)(50986999)(3846002)(33646002)(50226002)(8676002)(77096005)(4326007)(84392002)(92566002)(1456003)(81166006)(61296003)(23756003)(116806002)(5008740100001)(2906002)(5001770100001)(189998001)(1556002)(86362001)(15975445007)(14496001)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1621; H:pc6; FPR:; SPF:None; MLV:nov;  PTR:InfoNoRecords; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB5PR07MB1621; 23:CISFVGjTShovLMEg3zsHt4OMKQ/rtxvnF5EhLsj?= =?iso-8859-1?Q?PznncwIJ5tXi1rqXBsvTS7g7zLVvmtZQdhOrVvlJc/6S+b0ejr/AhMNM0Q?= =?iso-8859-1?Q?mb9Ei+zpyRr0dZkqKAWendNXtTU1sNJ0E/E70AGLP5us7XcBlN0TRHqAFN?= =?iso-8859-1?Q?CAU9NdAkggaRUoOs6pvMKtuIBZ9FX+qXroVgshy+u2pPPnIJqqwD9dStQd?= =?iso-8859-1?Q?reXtIJJ27cF8BoNiihyKpdwukc6+o8KeZYNLRSzVcYFhluu6lzPuxD3WAk?= =?iso-8859-1?Q?Rb0loZ67J4s8ftZlx3B/vx7ye4Opwz/7nwnitZ+ZYnldhkWaBIH/vl0HLC?= =?iso-8859-1?Q?H68cGG5InRkmmucBgvT2CIWZs0GC80Ihe6nyJYvJ/WjZai6n5//SJC1xiO?= =?iso-8859-1?Q?HrONCbScNbTRy4zZmbzcG9d8zmS1gSyqzZgaNwnCGs17zdmtQrQHlJlzqb?= =?iso-8859-1?Q?+6uVs3RKkyMhnq/3HNOPC1qP4aB3jJEJ7E9OpLnzMEP6AVBWAkqSD9FJf9?= =?iso-8859-1?Q?T7yiO+Go7T/1xP0PN+9i10dtV57jig1bq2PCPQ5IvtfN0dRJBO6XrJ2qV0?= =?iso-8859-1?Q?I6a8ZBzHSxIjN5DUtsNyd1VttroOtFE8jkQPtENNii526jILfq1oMCM+R3?= =?iso-8859-1?Q?sKAtKY3dEFDXNh/vV7uWBIZbOcaQ1/zamWBaDfTczSQ2YtdHUltsagSghp?= =?iso-8859-1?Q?lKbiou2Tb4WUkYSRzsVFi4PcrftrJwm4/ufjvkB5VuODAyGVn7CObR8zWU?= =?iso-8859-1?Q?lxRe6gKeWA1YT73+RVJPykBRdNcqtwzIlYzRvue1ZD/m+9Zn2yiyKhqjZw?= =?iso-8859-1?Q?7eO3tzfAncwuxaTDvwTPuwP9LhR0MKWCtImwfbh6p6mhbScpsZ5RSe2+bM?= =?iso-8859-1?Q?XUx0GMhbspt+M3eny5DnkZSOsSJCgF0A3n2YYInzIFFippOjwJ1Zd05XEd?= =?iso-8859-1?Q?QMRJN6fm54xEESNfgOztkQQhTV0A6t0pSwEEqhLRKzoiILDEpSxKqdT7N1?= =?iso-8859-1?Q?HpHyZ3LXkAg9bSzEcr/aW9MbDi1GjhNk8bU1u00lwns1LdonUjHIoU3lxn?= =?iso-8859-1?Q?Iig1ODRGl+6/WfXTDJOnGrxtfIX4uQQbrjURS6ZwBC2ORY2GXznuHQY2XN?= =?iso-8859-1?Q?nBKB+4MIaqWDke1/AR922/MlUu4WCP9GerLI0HDXVXLVF/mUfhlrTetT81?= =?iso-8859-1?Q?y2w6ZxC2FQWvR74idlLolyE9OvMTj8qcJdhYdmdY6Ql2erhpKNmF0f4ve5?= =?iso-8859-1?Q?z9LXvNR10oNLxr3K8eGl05pm5AIhjecDF4TAMFw=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 5:pG3mQxHUQ7rRn6o+GWVu3VCvtTNgmk/ZkKdBITBrBpztTLyQNugu5t2hkj4OxZ6F1dtbHpDAfAxNQk8MudBqz0IwZ8PCamR+my8sqqwBcAszpTN/g4DXB3dK5suWsbUwD0JIXDQwkFCHVqJgpEGs7w==; 24:zMfEpYtWpVKpFqS4K1IbD1GVNglNyeUlwRToWtVboAFRWUnPoOlThWzvBaUh3mz+VpNQq+byo/qQ6SnUisE972IPjyyomyb80yafiAiaqko=; 7:MV4ricNkkPmtd1q7syxZ5dpf2ZgIUMhyEE4htivBFAoZkxp2cxfnwK9331v3sPO/4uCrSBpfcHU40x6i8MDD+jhVy+WR4BtpmIrsL9ZIVYHehFsLjuYuautWyhfr1l8ieWoKXB1GHjPjhHoCsbPlo0HHQMDqjpyestkT/lNWyG0oSfIrGn9r0FiL4NWrNpD3
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2016 17:34:24.4589 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1621
Archived-At: 
Cc: worley@ariadne.com
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 May 2016 17:35:25 -0000

----- Original Message -----
From: "Martin Bjorklund" 
To: 
Sent: Monday, May 23, 2016 3:10 PM
>
> This comment from the Gen-ART review deserves it's own thread.
>
> gen-art> - section 9.9
> gen-art>
> gen-art>    The leafref type is used to declare a constraint on the
value space
> gen-art>    of a leaf, based on a reference to a set of leaf instances
in the
> gen-art>    data tree.  The "path" substatement (Section 9.9.2)
selects a set of
> gen-art>    leaf instances, and the leafref value space is the set of
values of
> gen-art>    these leaf instances.
> gen-art>
> gen-art> The first sentence isn't quite right.  Perhaps:
> gen-art>
> gen-art>    The value space of a leaf with leafref type is one of the
values of
> gen-art>    a set of leaf instances in the data tree.  The "path"
substatement
> gen-art>    (Section 9.9.2) selects the set of leaf instances, and the
leafref
> gen-art>    value space is the set of values of these leaf instances.
> gen-art>
> gen-art> - section 9.9.3
> gen-art>
> gen-art>    If "require-instance" is "true", it means that the
instance being
> gen-art>    referred MUST exist for the data to be valid.  This
constraint is
> gen-art>    enforced according to the rules in Section 8.
> gen-art>
> gen-art>    If "require-instance" is "false", it means that the
instance being
> gen-art>    referred MAY exist in valid data.
> gen-art>
> [...]
> gen-art> Also, I think the second paragraph means that if
require-instance is
> gen-art> false, the referred-to instance need not exist.  But it's not
clear to
> gen-art> me what that would mean -- if there are no instances
referenced by the
> gen-art> XPath expression, then the set of value values of the leafref
would be
> gen-art> empty and the leafref would necessarily be invalid. ...  I
think these
> gen-art> paragraphs need to be expanded in some way.
>
> mbj> Right; so what we want to say is:
> mbj>
> mbj>   - the value space is the same as the value space of the
referred
> mbj>     leaf
> mbj>
> mbj>   - there is an additional constraint if require-instance is true
that
> mbj>     the referred to leaf instance must exist
> mbj>
> mbj> How about
> mbj>
> mbj> OLD:
> mbj>
> mbj>    The leafref type is used to declare a constraint on the value
space
> mbj>    of a leaf, based on a reference to a set of leaf instances in
the
> mbj>    data tree.  The "path" substatement (Section 9.9.2) selects a
set of
> mbj>    leaf instances, and the leafref value space is the set of
values of
> mbj>    these leaf instances.
> mbj>
> mbj>    If the leaf with the leafref type represents configuration
data, and
> mbj>    the "require-instance" property (Section 9.9.3) is "true", the
leaf
> mbj>    it refers to MUST also represent configuration.  Such a leaf
puts a
> mbj>    constraint on valid data.  All such nodes MUST reference
existing
> mbj>    leaf instances or leafs with default values in use (see
Section 7.6.1
> mbj>    and Section 7.7.2) for the data to be valid.  This constraint
is
> mbj>    enforced according to the rules in Section 8.
> mbj>
> mbj> NEW:
> mbj>
> mbj>    The leafref type is used to declare a constraint on the value
space
> mbj>    of a leaf, based on a reference to a set of leaf instances in
the
> mbj>    data tree.  The "path" substatement (Section 9.9.2) is used to
refer
> mbj>    to another leaf node.  The leafref value space is the value
space of
> mbj>    this leaf node.
> mbj>
> mbj>    If the "require-instance" property is "true", there MUST exist
an
> mbj>    instance, or a leaf with a default value in use (see Section
7.6.1
> mbj>    and Section 7.7.2), of the leaf being referred to with the
same value
> mbj>    as the leafref value in a valid data tree.
> mbj>
> mbj>    If the leaf with the leafref type represents configuration
data, and
> mbj>    the "require-instance" property (Section 9.9.3) is "true", the
leaf
> mbj>    it refers to MUST also represent configuration.
>
> Does anyone have comments on this proposal?

yes!

I realise that the discussion is moving on, and corner cases are
appearing, but I think that the NEW paragraph is still a tough read.  I
rearrange the words  - more or less  -and get

NEW

The leafref type is used to declare a constraint on the value space of a
leaf.

The "path" substatement (Section 9.9.2) which MUST be present references
another leaf node. The value space of this other leaf node defines a set
of values, which may be empty (e.g. when the leaf node is not present in
the data tree).

If the "require-instance" property is "true", then the value of the leaf
with the leafref type MUST exist in the set of values; the set of value
includes leafs with have a default value in use (see Section 7.6.1  and
Section 7.7.2)

 If the leaf with the leafref type represents configuration data, and
the "require-instance" property (Section 9.9.3) is "true", then the
target of the "path" substatement MUST also represent configuration
data.

Tom Petch

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


From nobody Fri May 27 12:30:49 2016
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 3E7D212D52C for ; Fri, 27 May 2016 12:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 UBbFIpbOpORv for ; Fri, 27 May 2016 12:30:46 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 26C5812D79D for ; Fri, 27 May 2016 12:30:46 -0700 (PDT)
Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 66C95BE073DCA; Fri, 27 May 2016 19:30:41 +0000 (GMT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u4RJUihS012605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 May 2016 19:30:44 GMT
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u4RJUhSs007178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 May 2016 19:30:44 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.2]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 27 May 2016 15:30:44 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: "EXT Clyde Wildes (cwildes)" , "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt
Thread-Index: AQHRqwEIoPXkjp2l/k2OqqhnpwdmNZ+yjKoAgBqvymA=
Date: Fri, 27 May 2016 19:30:43 +0000
Message-ID: 
References: <20160510211427.390.80951.idtracker@ietfa.amsl.com> <3BC3991A-615F-47CE-A567-721C8272404E@cisco.com>
In-Reply-To: <3BC3991A-615F-47CE-A567-721C8272404E@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 May 2016 19:30:49 -0000

Hi Clyde,

I was a bit surprised to see the receiver/server side config in here (log-i=
nput-transports).  That seems to be a somewhat significant change in scope.=
  I thought the focus of this was more on the generation & distribution.  D=
o many implementations have functionality that maps to this log-input-trans=
ports ?   In any case the pyang tree has log-input-transports but it doesn'=
t seem to be down in the actual model itself.  But I'd be inclined to just =
remove this from the model.  Maybe Mahesh has some thoughts here (I didn't =
see a posting about this in the mailing list).

I agree there are multiple implementations of console, buffer and session l=
ogs.  But maybe 'terminal' should be removed or an if-feature ?  I'm not su=
re that one is so widespread (not in JUNOS, not in SR OS).

Buffer-limit-messages and having multiple log buffers are both supported by=
 Nokia SR OS. I would think that both of those would have support in other =
logging implementations as well.  I'm not sure if Tom P. was really conclud=
ing that there are no implementations of these in his email.  Do we have mu=
ltiple examples of implementations that limit log buffers using bytes ?

Buffer-limit-messages would be easy to do as an augmentation but making the=
 log-buffer a list is probably something we should just do from the start. =
 That is also consistent with all the other types of actions (except consol=
e of course). The use case for multiple log buffers is that you might sort/=
filter different types of log events into different circular buffers (i.e. =
have one for really critical log events, etc) for viewing on the node.

Regards,
Jason

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT Clyde Wildes=
 (cwildes)
Sent: Tuesday, May 10, 2016 17:23
To: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt

Hi,

This update to the draft-ietf-netmod-syslog-model-08 incorporates the chang=
es listed below based on feedback received.

An additional revision to this draft will be necessary to finalize TLS conf=
iguration leaves once the ietf-tls-client-server-model that the NETCONF WG =
plans to spin out of the netconf-server-model draft is available.

Changes from feedback from Mahesh J:
- added support for configuring a syslog server

Changes from feedback from Tom P.:
- removed four features for log action leaves console, buffer, terminal and=
 session since they are implemented by multiple vendors. Lack of support fo=
r these actions can be indicated using a deviation.
- removed feature buffer-limit-messages since implementation by any vendor =
is unknown
- renamed feature terminal-facility-user-logging-config to terminal-facilit=
y-device-logging to shorten the name and to clarify
- renamed feature session-facility-user-logging-config to session-facility-=
user-logging to shorten the name
- renamed feature selector-sevop-config to feature select-sev-compare to sh=
orten the name
- renamed feature selector-match-config to feature select-match to shorten =
the name
- renamed feature structured-data-config to feature structured-data to shor=
ten the name
- renamed feature signed-messages-config to feature signed-messages to shor=
ten the name
- removed the log-buffer list and name from log-action buffer since impleme=
ntation by any vendor is unknown
- removed the word draft from section 1
- updated the copyright dates and the revision dates in the models
- moved the example to an Appendix
- removed e-mail addresses from the acknowledgement section

Changes from feedback from Benoit:
- rename module vendor-syslog-types to module vendor-syslog-types-example


Thanks,

Kiran and Clyde




On 5/10/16, 2:14 PM, "netmod on behalf of internet-drafts@ietf.org"  wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts directo=
ries.
>This draft is a work item of the NETCONF Data Modeling Language of the IET=
F.
>
>        Title           : SYSLOG YANG Model
>        Authors         : Clyde Wildes
>                          Kiran Koushik
>	Filename        : draft-ietf-netmod-syslog-model-08.txt
>	Pages           : 35
>	Date            : 2016-05-10
>
>Abstract:
>   This document describes a data model for the Syslog protocol which is
>   used to convey event notification messages.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-08
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-syslog-model-08
>
>
>Please note that it may take a couple of minutes from the time of=20
>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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


From nobody Sat May 28 04:41:20 2016
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 C123112D1B9 for ; Sat, 28 May 2016 04:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 ldCiqpGFV-Bj for ; Sat, 28 May 2016 04:41:16 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F6512D0BF for ; Sat, 28 May 2016 04:41:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tTeMs4F62u3GxRV53lfNJKAFaDkYjzJkYHCNW/xUmHY=; b=JpwTnT8Rjf8lztRRRT/DRtKzVvphB3RWoJQzJhd5Mfq4jYO/uGtkPAOaR8aSHrZqQDqr48yXn9f5FqKVbBO7CIZT+4Tm3OH/10ai8aFHZPB1fyNZK3aLsTRrW2qZh/hRI6WaMbMJ9eyYIv1N5s7PUWsMSd0Fi6yAjamOKEYefFI=
Authentication-Results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=btconnect.com;
Received: from pc6 (109.145.193.232) by HE1PR07MB1627.eurprd07.prod.outlook.com (10.166.124.23) with Microsoft SMTP Server (TLS) id 15.1.506.9; Sat, 28 May 2016 11:40:52 +0000
Message-ID: <002101d1b8d5$3a24f360$4001a8c0@gateway.2wire.net>
From: t.petch 
To: "Sterne, Jason (Nokia - CA)" , "EXT Clyde Wildes (cwildes)" , 
References: <20160510211427.390.80951.idtracker@ietfa.amsl.com> <3BC3991A-615F-47CE-A567-721C8272404E@cisco.com> 
Date: Sat, 28 May 2016 12:36:42 +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: [109.145.193.232]
X-ClientProxiedBy: DB5PR01CA0055.eurprd01.prod.exchangelabs.com (10.163.24.23) To HE1PR07MB1627.eurprd07.prod.outlook.com (10.166.124.23)
X-MS-Office365-Filtering-Correlation-Id: f56cef2f-7cb6-4f79-ed17-08d386ececce
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1627; 2:8E8eEUst+I2Sas/jq4b7fFmexafwcmaCGtoWCoSZtecQS8RFXwrbr8N6+a+q5GNHqMfj6e9NN1xzaPLBQuOJSRSBfIZMy+kLRFJhTDVWONTdKW9VZxoXPUoZg9ru4M6oFfiYZf9piqT/RFrJWb+4ytqFOKTTfMTrqHJRryJytYVRMhpCDnYpxAr+wpiL96yD; 3:iYMeMkBFTTMV+uFeRUgygfG//dbH2Vw3HivVYNTILFAl2OzG/PDm7GbE9ksbLBIFKOFzpk8DF9oTzMv+mk/lhLTPapC7KK/SG+1S5j3ITcTss+UflohIEX+2oHFMokbt; 25:6uGMoJQSnGTS/2V80yJpIBfpVFtYhCeATmUppznBVkpIGF+7xTG1wIFhggx3MipNLW+8poEX/i9OHA9Ypm88t6DM9vcevROxDqxNRGbS/SV+BY8koEHWsvlHy50d7m2nCCRaIsjzMx/qRkn7zPI8f7jwWO61d7Zn2wl09h0/KXFvPD3sjti2DXYYMQ4BGVAc7g9uhaE/3J7XZrhEI2F/ayiTXF8zDtxdxvdVyprTGE2FVINDe17ZNOvgHO6U6qz5b/pzdQ9P4F+w1Kg6dpxzg3S+0PpCeYhZNAvbRxU3ULAyGBqsq2s+4iFBRLhPG0xGNonQaMJzQj2cWK8JIhoRRifVQ1P7j++lRhW/aYaKwstqyxrrBqJ3YZV5I17hsNYCuAK4Tt0VGs3Gexk1Lh50fwvr/r3NafCUkY/4+IjI5HU=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1627;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(120809045254105)(82608151540597); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR07MB1627; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1627; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1627; 4:jBu1zA0SW10zRDvJSbJ7tRCW0PbeHeNzZyJHOw7RyfH7RMZvgjKsIziZA25bu8twNpuI812HWucewk6Sj63iJ/jI03481YravD3B/qdx25QzRZj3zZe7x0lgoA+5l1vrQEtdNYp6XlzPrcxr92bWkp0UnHoz8eYoBO2M2SIpFvT0EliFRtD5gN59DdZs4nXoiUCdgsCr918fLfxozbNpHjFNAw4aUaUwXRGYKFkui/8o1sLH0/veVGlVUU7QvCoKYsjyZd6HCn5jpyVY7zbj/+k/FDG9JUHSJGM6kfq7cipZaRFDi5YD7qJp03EMfz86FQ8jqnZZPI2444w64fdM9i7S2+RyKMKHv/rKRP7yydhYc7+t3x/O2V+PPaxCOF3be0KWdJYhUDAjd3j7gLxpeBNk6603nPZejKVz+PQ5ecnB45sFVVeYIrQCrJBaNYxfM+baX8KDIOnJix0lChtU9BjPbkJjbxdybeBsXxQ3WSw=
X-Forefront-PRVS: 09565527D6
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(377424004)(377454003)(24454002)(13464003)(230700001)(86362001)(81686999)(81816999)(62236002)(76176999)(44716002)(47776003)(116806002)(50986999)(1556002)(61296003)(3846002)(42186005)(6116002)(50466002)(44736004)(33646002)(14496001)(189998001)(230783001)(107886002)(2906002)(586003)(9686002)(23756003)(15975445007)(81166006)(84392002)(5004730100002)(5008740100001)(19580395003)(19580405001)(77096005)(92566002)(66066001)(5001770100001)(50226002)(8676002)(1456003)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1627; H:pc6; FPR:; SPF:None; MLV:nov;  PTR:InfoNoRecords; LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR07MB1627; 23:FiRTzqvh4lH0Smpk0+8U+qMPZjEChFqTlkQuCBL?= =?iso-8859-1?Q?DRnYI+xJPuSIZd9MFLgSlVzr/Gj/0AKolRqF/teyBbcITF7tai5BMbxEE9?= =?iso-8859-1?Q?2wV7IREDHv2TWL8cmklNy80thIvyspubfWDKUdfLYcGZ4/CxK/7FgwKvuf?= =?iso-8859-1?Q?RkUezHtQ4ATA70GpsJZ85xI1TZoONGFwxQO0WlX0oFHoQAVuFxl/mTJ7hz?= =?iso-8859-1?Q?ks2WQh5dRoCVWbuoJwxeLOm5JIB471G/P6zUdsABzEe2ajHbfZYm3fQVaL?= =?iso-8859-1?Q?UPn1nzlmdCrHV1rua533UZX8PJqOqcKxYEOF1bLdj7lsKjIwQuQroTDwlk?= =?iso-8859-1?Q?fITRhXvQeouuto/4u4b2uRkjFfJoQuTg10Uj1uHGCUQZNoWspwL5ynv5n1?= =?iso-8859-1?Q?3fAL1plsWkcF54FEKwkqrMiBRNQvqCAHHmQHP9GvjOq08yocqbQrUolIar?= =?iso-8859-1?Q?3GRFhGcHYucvQyE5C7joTxej8dnipsdYUhOqMtOH88gecv3Rn8r5OTAFHc?= =?iso-8859-1?Q?FuzAapsTGXKlM1JCwiDRwzsb/uRenjPmUftdMtdnj/LgDE1LgqyFnA1VwF?= =?iso-8859-1?Q?olmFGpfoCmCI9O6yAAx4gu00uJLCJeOAIk+gbonk9q8vPcZkX8aCMp3t73?= =?iso-8859-1?Q?0RX0kMqjwO95/j3EnS7edJ/QamI+92xSlYqu5m/mdCWyJktqlLH6BAg6eR?= =?iso-8859-1?Q?yVi9x5flb3Thy2soYzl8u9DI+WJP+eVZazcWmqoCEQRKqhQZUnbonKsgaf?= =?iso-8859-1?Q?TSRDh5SAb6WulJF/qViaDbP0yxLVDyVQN8tLOviHwWm5KuigObAWNZyv4+?= =?iso-8859-1?Q?OTwshav6Fi4wqm87OphYicbXTVaZKh5xJWi0rEceCNP+mIBofXFsD0Susn?= =?iso-8859-1?Q?HT7buzELN06qUE7KHcrvcs0K00zDWkzoDF2gYkLCm3FB8Gj1DLKQmuVZCN?= =?iso-8859-1?Q?eHalpLN2taRj9KvHhYrSf76GPcnasC3NX0KfHC4T7DJEsuF/zb4W90mtzP?= =?iso-8859-1?Q?Kc015e01AplW/zXu6Yt/6Qq5YYqPmEBasQhZBt0dSpmnzOm+bwDa/LDr4N?= =?iso-8859-1?Q?+bOF2Sw5ZL9BoJYSwzXrDzckxJ/gcffEBqw6GRwlK4kztixmvb99ZS/+a/?= =?iso-8859-1?Q?RSCDWONmRey53ipLxU2PqlpXLT9M75yQbGnDdQhdoej+MSxZ0CFYMTE+/H?= =?iso-8859-1?Q?tu6I9VtFk3JHmUGa4n25Ebp98g1XxC1q1Slbf6WuugFWZdA/EeJTw36TWL?= =?iso-8859-1?Q?mYhZ+/g5gNJDgesQTjh/hMmzmmNECge17jPUFJgNagXbK++tC5fk2sfRhj?= =?iso-8859-1?Q?r4=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1627; 5:sNnII042UHDCtnojwe6VyyhvGqtBdCmgvlnG5FoTq9XrZZzb/111MXcN1zDsdq3u5ogH3zEXYnZTi7XfrHdotlhv2Hbtqh5Pb8ZsfrYQa4rRqDrXWzQLoslyg2SN3A257pw3A0tcns60fRgjnetPfw==; 24:LsZJjKJhBtkOE7XRpgC7spMvzAPQpDSXdEEQTOmEJyGU7JbOnOmNQ2urGSyBRjSpTXIdM9/YBSizhvNrGWzC9MszsYSui52yRNf4gpFsLVE=; 7:WGM8CbsgYAsRul5K0n1+YwnzmTBzLg4PoEbscfC5wCHvoFPzjvqDJ0AU9JSLssONCkVTXWqD0Vx1TwhT2ZoyNROrg8V6cIK8EoWNls5uU1m3Ivoca9fQDO8QKATQrZPWVJA1vhhH/twg9aAbW6h064bxsrbFytuvO+g4wNH4gN1fpumvTl2vNRYGrIyhqit7
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2016 11:40:52.8072 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1627
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 May 2016 11:41:20 -0000


Tom Petch


----- Original Message -----
From: "Sterne, Jason (Nokia - CA)" 
Sent: Friday, May 27, 2016 8:30 PM

> Hi Clyde,
>
> I was a bit surprised to see the receiver/server side config in here
(log-input-transports).  That seems to be a somewhat significant change
in scope.  I thought the focus of this was more on the generation &
distribution.  Do many implementations have functionality that maps to
this log-input-transports ?   In any case the pyang tree has
log-input-transports but it doesn't seem to be down in the actual model
itself.  But I'd be inclined to just remove this from the model.  Maybe
Mahesh has some thoughts here (I didn't see a posting about this in the
mailing list).
>
> I agree there are multiple implementations of console, buffer and
session logs.  But maybe 'terminal' should be removed or an if-feature ?
I'm not sure that one is so widespread (not in JUNOS, not in SR OS).
>
> Buffer-limit-messages and having multiple log buffers are both
supported by Nokia SR OS. I would think that both of those would have
support in other logging implementations as well.  I'm not sure if Tom
P. was really concluding that there are no implementations of these in
his email.  Do we have multiple examples of implementations that limit
log buffers using bytes ?
>

My comment was more on the complexity that results from having so many
options.  Other models are worse - some of the routing ones I find
unintelligible as a result - but I raised the issue on this model
because it is being discussed on this list where (almost) all the
expertise in these matters resides to see if anyone else would bite.

I believe we will regret this complexity some years down the line but
see no way of forestalling this:-(

I don't have direct knowledge of whether or not this feature is
widespread.

Tom Petch

> Buffer-limit-messages would be easy to do as an augmentation but
making the log-buffer a list is probably something we should just do
from the start.  That is also consistent with all the other types of
actions (except console of course). The use case for multiple log
buffers is that you might sort/filter different types of log events into
different circular buffers (i.e. have one for really critical log
events, etc) for viewing on the node.
>
> Regards,
> Jason
>
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT Clyde
Wildes (cwildes)
> Sent: Tuesday, May 10, 2016 17:23
> To: netmod@ietf.org
> Subject: Re: [netmod] I-D Action:
draft-ietf-netmod-syslog-model-08.txt
>
> Hi,
>
> This update to the draft-ietf-netmod-syslog-model-08 incorporates the
changes listed below based on feedback received.
>
> An additional revision to this draft will be necessary to finalize TLS
configuration leaves once the ietf-tls-client-server-model that the
NETCONF WG plans to spin out of the netconf-server-model draft is
available.
>
> Changes from feedback from Mahesh J:
> - added support for configuring a syslog server
>
> Changes from feedback from Tom P.:
> - removed four features for log action leaves console, buffer,
terminal and session since they are implemented by multiple vendors.
Lack of support for these actions can be indicated using a deviation.
> - removed feature buffer-limit-messages since implementation by any
vendor is unknown
> - renamed feature terminal-facility-user-logging-config to
terminal-facility-device-logging to shorten the name and to clarify
> - renamed feature session-facility-user-logging-config to
session-facility-user-logging to shorten the name
> - renamed feature selector-sevop-config to feature select-sev-compare
to shorten the name
> - renamed feature selector-match-config to feature select-match to
shorten the name
> - renamed feature structured-data-config to feature structured-data to
shorten the name
> - renamed feature signed-messages-config to feature signed-messages to
shorten the name
> - removed the log-buffer list and name from log-action buffer since im
plementation by any vendor is unknown
> - removed the word draft from section 1
> - updated the copyright dates and the revision dates in the models
> - moved the example to an Appendix
> - removed e-mail addresses from the acknowledgement section
>
> Changes from feedback from Benoit:
> - rename module vendor-syslog-types to module
vendor-syslog-types-example
>
>
> Thanks,
>
> Kiran and Clyde
>
>
>
>
> On 5/10/16, 2:14 PM, "netmod on behalf of 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           : SYSLOG YANG Model
> >        Authors         : Clyde Wildes
> >                          Kiran Koushik
> > Filename        : draft-ietf-netmod-syslog-model-08.txt
> > Pages           : 35
> > Date            : 2016-05-10
> >
> >Abstract:
> >   This document describes a data model for the Syslog protocol which
is
> >   used to convey event notification messages.
> >
> >
> >The IETF datatracker status page for this draft is:
> >https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/
> >
> >There's also a htmlized version available at:
> >https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-08
> >
> >A diff from the previous version is available at:
> >https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-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/
> >
> >_______________________________________________
> >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 Sat May 28 09:22:04 2016
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 460C212B011 for ; Sat, 28 May 2016 09:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=unavailable 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 X7B2Xt7Hq6UJ for ; Sat, 28 May 2016 09:22:02 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D474512B00F for ; Sat, 28 May 2016 09:22:01 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9B97BA85 for ; Sat, 28 May 2016 18:22:00 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id c9-Y_Ppk_l23 for ; Sat, 28 May 2016 18:21:58 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sat, 28 May 2016 18:21:59 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A48B20050 for ; Sat, 28 May 2016 18:21:59 +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 Js2GWAg3ntn6 for ; Sat, 28 May 2016 18:21:57 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C88862004E for ; Sat, 28 May 2016 18:21:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C218C3AF8D4E; Sat, 28 May 2016 18:21:57 +0200 (CEST)
Resent-From: Juergen Schoenwaelder 
Resent-Date: Sat, 28 May 2016 18:21:57 +0200
Resent-Message-ID: <20160528162157.GB17067@elstar.local>
Resent-To: netmod@ietf.org
Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS01.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server (TLS) id 14.3.279.2; Sat, 28 May 2016 18:21:40 +0200
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47])	by hermes.jacobs-university.de (Postfix) with ESMTP id 4029920051	for ; Sat, 28 May 2016 18:21:40 +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 rXN3f7isXbTh; Sat, 28 May 2016 18:21:38 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133])	by hermes.jacobs-university.de (Postfix) with ESMTP id 9C7AE2004E;	Sat, 28 May 2016 18:21:37 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501)	id 16A763AF8D2A; Sat, 28 May 2016 18:21:36 +0200 (CEST)
Date: Sat, 28 May 2016 18:21:36 +0200
From: Juergen Schoenwaelder 
To: "Acee Lindem (acee)" 
Message-ID: <20160528162136.GA17067@elstar.local>
References:     <20160527172652.GB15690@elstar.local>  <20160528133152.GB16880@elstar.local> 
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
X-MS-Exchange-Organization-AuthSource: SHUBCAS01.jacobs.jacobs-university.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0
MIME-Version: 1.0
Archived-At: 
Cc: "netmod-chairs@ietf.org" 
Subject: Re: [netmod] "A YANG Data Model for Routing Management" Modifications
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 May 2016 16:22:03 -0000

On Sat, May 28, 2016 at 02:17:27PM +0000, Acee Lindem (acee) wrote:
> 
> 
> On 5/28/16, 9:31 AM, "Juergen Schoenwaelder"
>  wrote:
> 
> >On Fri, May 27, 2016 at 09:14:23PM +0000, Acee Lindem (acee) wrote:
> >> Hi Lada, Juergen,
> >> 
> >> On 5/27/16, 1:26 PM, "Juergen Schoenwaelder"
> >>  wrote:
> >> 
> >> >On Fri, May 27, 2016 at 11:42:08AM +0200, Ladislav Lhotka wrote:
> >> >> Hi Acee,
> >> >> 
> >> >> I have a couple of questions:
> >> >> 
> >> >> 1. I changed "routing-protocol" -> "control-plane-protocol" (this is
> >> >>    already in GitHub). As for identities, I introduced a new base
> >> >>    identity "control-plane-protocol", and derived "routing-protocol"
> >> >>    from it. So the idea is that routing protocols will still use
> >> >>    "routing-protocol" as their base. Is it OK?
> >> 
> >> We would like to have a single list rather than multiple lists. By
> >> generalizing “control-plane-protocols” we have one list per device, LNE,
> >> or NI. That is the goal.
> >> 
> >> >>
> >> >
> >> >So what is a routing protocol and what is a control plane protocol?
> >> 
> >> A routing protocol is a RIB client. A control plane protocol is more
> >> general.
> >
> >A RIB client?
> 
> A protocol that installs routes in one of the AF RIBs.
> 
> 
> > 
> >> >Or
> >> >what turns a control plane protocol into a routing protocol? Will this
> >> >distinction make network management simpler?
> >> 
> >> It will give us a place to put control plane protocols.
> >>
> >
> >I do not see yet why this is the scope of this effort. Perhaps I do not
> >understand what is proposed here:
> >
> >a) a change of the identity routing-protocol
> >
> >b) a change of the container routing-protocols
> >
> >c) a change of the list routing-protocol
> 
> 
> d) All of the above
>

Then this does not make sense to me. You apparently propose to
change

   +--rw routing
   |  +--rw router-id?
   |  +--rw routing-protocols
   |  +--rw routing-protocol* [type name]
   |
   |
   +--rw ribs
      +--rw rib* [name]

to

   +--rw routing
   |  +--rw router-id?
   |  +--rw control-plane-protocols
   |  +--rw control-plane-protocol* [type name]
   |
   |
   +--rw ribs
      +--rw rib* [name]

and I think this is wrong since there are control plane protocols that
have nothing to do with routing and I also do not think the WG is
chartered to provide a model or infrastructure for arbitrary
control-plane data models. Perhaps you propose something else but then
please make it clear what is expected to be changed so that I can
understand.

/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 Sat May 28 15:57:15 2016
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 DE6F012D0A7 for ; Sat, 28 May 2016 15:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_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 1vjL30rBCOs0 for ; Sat, 28 May 2016 15:57:10 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 6456912D099 for ; Sat, 28 May 2016 15:57:10 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id b124so52623357pfb.0 for ; Sat, 28 May 2016 15:57:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=efPklwBaDnC+oSxPT46fxmgpqSXQZMFDtK7GRQIYmMo=; b=rkYv2dcVxAEvT9mOKZIKof/mmpeBbCZ5L+viywCPDXzJgirne0xiA5CcWPtW9sLFJn da3+jjGsjQHJaKKumjQJPCW3UcXaHR9xq1fa2lfcFTMINXsr7hQDnkHwDsillSPwJy1q s9NkBdWHn2fC4+3whuJTnyDuCvrBrubA/5QRWQpPdr9G3zCbC38L4LYg5gl/vCuD2bZQ oQd4naSCGma2tsXBuom9yqTsuHpD4zNCzHE0QcJFIb/gkw05n6uhZn+SUwSXobPBug8i wkNiAK6Y1Cp6fNHEcb1/OWHbpuvOhpdmPNpV/tpsaSuYptAXWJ7sSpTELoMW+1LK6BH0 Dd4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=efPklwBaDnC+oSxPT46fxmgpqSXQZMFDtK7GRQIYmMo=; b=fbTxVzhfhoizUytm7Vwo+O1Djw4nwWqfuNlBqRl7qX7S8A2n+/HYllA9xvS2ZPCx/0 dm8cD2h+BkNpZJ4YrZLwAE4h5fxsVRK2aiwefj8RQ7MlcQxVFekK2G7TiY/Topwk64Cl 9WgGs5auh7kvG1FfRxWkUIdq0MujnBNQe8b7GHZQvOcGGojhbGePOcVytXvCvmErK1va fkGtd7b6hXQ0uzzB2+xtNj4fWYEGKNgeywZ+ERzOQdtwy+bjCajzNi39lgudGsQu5vqL Zs+DGSguxuv+RsDaCz2Dzr2R6r5YgLyh7Bs0Xsf16EpT97A5KC6vvb1mSkPCmWWzDKn/ aV7g==
X-Gm-Message-State: ALyK8tIoqvTYLMydwIMAyicLHDM+HD2K4BpJUv+ija/8BLb1eBIOoI2bZLy2pr8yx4oHBA==
X-Received: by 10.98.43.209 with SMTP id r200mr33876263pfr.24.1464476229818; Sat, 28 May 2016 15:57:09 -0700 (PDT)
Received: from [192.168.1.150] (108-247-125-249.lightspeed.sntcca.sbcglobal.net. [108.247.125.249]) by smtp.gmail.com with ESMTPSA id f191sm22869518pfa.26.2016.05.28.15.57.08 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 May 2016 15:57:08 -0700 (PDT)
References: <20160510211427.390.80951.idtracker@ietfa.amsl.com> <3BC3991A-615F-47CE-A567-721C8272404E@cisco.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <3BC3991A-615F-47CE-A567-721C8272404E@cisco.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-03D3D212-AB0D-4F32-B7D9-211912F6EBA8
Content-Transfer-Encoding: 7bit
Message-Id: <09AD09EF-537B-452B-88AB-7A43257D407F@gmail.com>
X-Mailer: iPad Mail (13E238)
From: Mahesh Jethanandani 
Date: Sat, 28 May 2016 15:57:07 -0700
To: "Clyde Wildes (cwildes)" 
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 May 2016 22:57:14 -0000

--Apple-Mail-03D3D212-AB0D-4F32-B7D9-211912F6EBA8
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable





> On May 10, 2016, at 2:22 PM, Clyde Wildes (cwildes)  wr=
ote:
>=20
> Hi,
>=20
> This update to the draft-ietf-netmod-syslog-model-08 incorporates the chan=
ges listed below based on feedback received.
>=20
> An additional revision to this draft will be necessary to finalize TLS con=
figuration leaves once the ietf-tls-client-server-model that the NETCONF WG p=
lans to spin out of the netconf-server-model draft is available.
>=20
> Changes from feedback from Mahesh J:
> - added support for configuring a syslog server

Did I? Sorry, if there was a miscommunication. I thought the rational that n=
etworks devices are rarely configured as syslog servers made sense. I will l=
et the WG decide if they want to keep syslog server configuration.=20

We were discussing ssh server and client configuration and the desire to inc=
lude that as part of the work (being done by Kent and others in NETCONF WG).=


Cheers

Mahesh Jethanandani
mjethanandani@gmail.com

>=20
> Changes from feedback from Tom P.:
> - removed four features for log action leaves console, buffer, terminal an=
d session since they are implemented by multiple vendors. Lack of support fo=
r these actions can be indicated using a deviation.
> - removed feature buffer-limit-messages since implementation by any vendor=
 is unknown
> - renamed feature terminal-facility-user-logging-config to terminal-facili=
ty-device-logging to shorten the name and to clarify
> - renamed feature session-facility-user-logging-config to session-facility=
-user-logging to shorten the name
> - renamed feature selector-sevop-config to feature select-sev-compare to s=
horten the name
> - renamed feature selector-match-config to feature select-match to shorten=
 the name
> - renamed feature structured-data-config to feature structured-data to sho=
rten the name
> - renamed feature signed-messages-config to feature signed-messages to sho=
rten the name
> - removed the log-buffer list and name from log-action buffer since implem=
entation by any vendor is unknown
> - removed the word draft from section 1
> - updated the copyright dates and the revision dates in the models
> - moved the example to an Appendix
> - removed e-mail addresses from the acknowledgement section
>=20
> Changes from feedback from Benoit:
> - rename module vendor-syslog-types to module vendor-syslog-types-example
>=20
>=20
> Thanks,
>=20
> Kiran and Clyde
>=20
>=20
>=20
>=20
>> On 5/10/16, 2:14 PM, "netmod on behalf of internet-drafts@ietf.org"  wrote:
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>> This draft is a work item of the NETCONF Data Modeling Language of the IE=
TF.
>>=20
>>       Title           : SYSLOG YANG Model
>>       Authors         : Clyde Wildes
>>                         Kiran Koushik
>>    Filename        : draft-ietf-netmod-syslog-model-08.txt
>>    Pages           : 35
>>    Date            : 2016-05-10
>>=20
>> Abstract:
>>  This document describes a data model for the Syslog protocol which is
>>  used to convey event notification messages.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/
>>=20
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-08
>>=20
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-syslog-model-08
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of submiss=
ion
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> 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

--Apple-Mail-03D3D212-AB0D-4F32-B7D9-211912F6EBA8
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable






On May 10, 2=
016, at 2:22 PM, Clyde Wildes (cwildes) <cwildes@cisco.com> wrote:

Hi,

This update to the draft-ie=
tf-netmod-syslog-model-08 incorporates the changes listed below based on fee=
dback received.

An additional revision to t=
his draft will be necessary to finalize TLS configuration leaves once the ie=
tf-tls-client-server-model that the NETCONF WG plans to spin out of the netc=
onf-server-model draft is available.

Change=
s from feedback from Mahesh J:
- added support for configuri=
ng a syslog server

Did I? Sorry,=
 if there was a miscommunication. I thought the rational that networks devic=
es are rarely configured as syslog servers made sense. I will let the WG dec=
ide if they want to keep syslog server configuration. 

We were discussing ssh server and client configuration and the des=
ire to include that as part of the work (being done by Kent and others in NE=
TCONF WG).

Cheers

Mahesh Jethanandani=

=



Changes from f=
eedback from Tom P.:
- removed four features for log action l=
eaves console, buffer, terminal and session since they are implemented by mu=
ltiple vendors. Lack of support for these actions can be indicated using a d=
eviation.
- removed feature buffer-limit-messages since impl=
ementation by any vendor is unknown
- renamed feature termin=
al-facility-user-logging-config to terminal-facility-device-logging to short=
en the name and to clarify
- renamed feature session-facilit=
y-user-logging-config to session-facility-user-logging to shorten the name
- renamed feature selector-sevop-config to feature select-sev=
-compare to shorten the name
- renamed feature selector-matc=
h-config to feature select-match to shorten the name
- renam=
ed feature structured-data-config to feature structured-data to shorten the n=
ame
- renamed feature signed-messages-config to feature sign=
ed-messages to shorten the name
- removed the log-buffer lis=
t and name from log-action buffer since implementation by any vendor is unkn=
own
- removed the word draft from section 1
=
- updated the copyright dates and the revision dates in the models- moved the example to an Appendix
- removed e-mail a=
ddresses from the acknowledgement section

C=
hanges from feedback from Benoit:
- rename module vendor-sys=
log-types to module vendor-syslog-types-example

<=
span>
Thanks,

Kiran and Cly=
de




On 5/10/16, 2:14 PM, "netmod on behalf of internet-drafts@ietf.org" <netmod-bounces@ietf.org on behalf of 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 Lang=
uage of the IETF.

    &nbs=
p;  Title          &n=
bsp;: SYSLOG YANG Model
       Authors     &nbs=
p;   : Clyde Wildes
           &n=
bsp;            =
 Kiran Koushik
 &=
nbsp;  Filename        : draft-ietf-=
netmod-syslog-model-08.txt
=
    Pages         &n=
bsp; : 35
  =
;  Date           &nb=
sp;: 2016-05-10

Abstract:
  This document describes a dat=
a model for the Syslog protocol which is
  used to convey event notification messages.=



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr=
aft-ietf-netmod-syslog-model/

There's=
 also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-0=
8

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


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

Internet-Drafts ar=
e also available by anonymous FTP at:
ftp://ftp.i=
etf.org/internet-drafts/

____________=
___________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod<=
/span>
_______________________________________________=

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

--Apple-Mail-03D3D212-AB0D-4F32-B7D9-211912F6EBA8--


From nobody Mon May 30 00:26:12 2016
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 D5BB412B009 for ; Mon, 30 May 2016 00:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 RlZaGsSGXewS for ; Mon, 30 May 2016 00:26:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E1712B02C for ; Mon, 30 May 2016 00:26:06 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:10b3:51b0:595a:8861] (unknown [IPv6:2001:718:1a02:1:10b3:51b0:595a:8861]) by mail.nic.cz (Postfix) with ESMTPSA id B91C3600C0; Mon, 30 May 2016 09:26:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464593164; bh=eNSSXtf7mJ0srU44irkS8sAzcnzvazI4OJ5UA2XxzEM=; h=From:Date:To; b=hyQaQnpB2FAd9BZSBS2u8+DI95kAGxbE8c8MPYLDHeZ6ZdF9wPPrEjiMtqXZVwl0c WTQZR8ujj6zId96kQLShZvBCJZ1vk+X32WUxbBUF0lWEhDqfKBFJqNAPNDAqz9d7OQ +B3bIJnUVX8n8pWGKX5nXSCjt07X4zbJHDryLy58=
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=us-ascii
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <008201d1b83d$72f91f60$4001a8c0@gateway.2wire.net>
Date: Mon, 30 May 2016 09:26:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CD8009E-E3BE-409D-8439-53876375CEF7@nic.cz>
References: <20160523.161038.800274078120441332.mbj@tail-f.com> <008201d1b83d$72f91f60$4001a8c0@gateway.2wire.net>
To: "t.petch" 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: worley@ariadne.com, netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 07:26:11 -0000

> On 27 May 2016, at 19:30, t.petch  wrote:
>=20
>=20
> ----- Original Message -----
> From: "Martin Bjorklund" 
> To: 
> Sent: Monday, May 23, 2016 3:10 PM
>>=20
>> This comment from the Gen-ART review deserves it's own thread.
>>=20
>> gen-art> - section 9.9
>> gen-art>
>> gen-art>    The leafref type is used to declare a constraint on the
> value space
>> gen-art>    of a leaf, based on a reference to a set of leaf =
instances
> in the
>> gen-art>    data tree.  The "path" substatement (Section 9.9.2)
> selects a set of
>> gen-art>    leaf instances, and the leafref value space is the set of
> values of
>> gen-art>    these leaf instances.
>> gen-art>
>> gen-art> The first sentence isn't quite right.  Perhaps:
>> gen-art>
>> gen-art>    The value space of a leaf with leafref type is one of the
> values of
>> gen-art>    a set of leaf instances in the data tree.  The "path"
> substatement
>> gen-art>    (Section 9.9.2) selects the set of leaf instances, and =
the
> leafref
>> gen-art>    value space is the set of values of these leaf instances.
>> gen-art>
>> gen-art> - section 9.9.3
>> gen-art>
>> gen-art>    If "require-instance" is "true", it means that the
> instance being
>> gen-art>    referred MUST exist for the data to be valid.  This
> constraint is
>> gen-art>    enforced according to the rules in Section 8.
>> gen-art>
>> gen-art>    If "require-instance" is "false", it means that the
> instance being
>> gen-art>    referred MAY exist in valid data.
>> gen-art>
>> [...]
>> gen-art> Also, I think the second paragraph means that if
> require-instance is
>> gen-art> false, the referred-to instance need not exist.  But it's =
not
> clear to
>> gen-art> me what that would mean -- if there are no instances
> referenced by the
>> gen-art> XPath expression, then the set of value values of the =
leafref
> would be
>> gen-art> empty and the leafref would necessarily be invalid. ...  I
> think these
>> gen-art> paragraphs need to be expanded in some way.
>>=20
>> mbj> Right; so what we want to say is:
>> mbj>
>> mbj>   - the value space is the same as the value space of the
> referred
>> mbj>     leaf
>> mbj>
>> mbj>   - there is an additional constraint if require-instance is =
true
> that
>> mbj>     the referred to leaf instance must exist
>> mbj>
>> mbj> How about
>> mbj>
>> mbj> OLD:
>> mbj>
>> mbj>    The leafref type is used to declare a constraint on the value
> space
>> mbj>    of a leaf, based on a reference to a set of leaf instances in
> the
>> mbj>    data tree.  The "path" substatement (Section 9.9.2) selects a
> set of
>> mbj>    leaf instances, and the leafref value space is the set of
> values of
>> mbj>    these leaf instances.
>> mbj>
>> mbj>    If the leaf with the leafref type represents configuration
> data, and
>> mbj>    the "require-instance" property (Section 9.9.3) is "true", =
the
> leaf
>> mbj>    it refers to MUST also represent configuration.  Such a leaf
> puts a
>> mbj>    constraint on valid data.  All such nodes MUST reference
> existing
>> mbj>    leaf instances or leafs with default values in use (see
> Section 7.6.1
>> mbj>    and Section 7.7.2) for the data to be valid.  This constraint
> is
>> mbj>    enforced according to the rules in Section 8.
>> mbj>
>> mbj> NEW:
>> mbj>
>> mbj>    The leafref type is used to declare a constraint on the value
> space
>> mbj>    of a leaf, based on a reference to a set of leaf instances in
> the
>> mbj>    data tree.  The "path" substatement (Section 9.9.2) is used =
to
> refer
>> mbj>    to another leaf node.  The leafref value space is the value
> space of
>> mbj>    this leaf node.
>> mbj>
>> mbj>    If the "require-instance" property is "true", there MUST =
exist
> an
>> mbj>    instance, or a leaf with a default value in use (see Section
> 7.6.1
>> mbj>    and Section 7.7.2), of the leaf being referred to with the
> same value
>> mbj>    as the leafref value in a valid data tree.
>> mbj>
>> mbj>    If the leaf with the leafref type represents configuration
> data, and
>> mbj>    the "require-instance" property (Section 9.9.3) is "true", =
the
> leaf
>> mbj>    it refers to MUST also represent configuration.
>>=20
>> Does anyone have comments on this proposal?
>=20
> yes!
>=20
> I realise that the discussion is moving on, and corner cases are
> appearing, but I think that the NEW paragraph is still a tough read.  =
I
> rearrange the words  - more or less  -and get
>=20
> NEW
>=20
> The leafref type is used to declare a constraint on the value space of =
a
> leaf.
>=20
> The "path" substatement (Section 9.9.2) which MUST be present =
references
> another leaf node. The value space of this other leaf node defines a =
set
> of values, which may be empty (e.g. when the leaf node is not present =
in
> the data tree).
>=20
> If the "require-instance" property is "true", then the value of the =
leaf
> with the leafref type MUST exist in the set of values; the set of =
value
> includes leafs with have a default value in use (see Section 7.6.1  =
and
> Section 7.7.2)

I think this not correct. Unlike RFC 6020, the "path" argument is now =
used for two different purposes:

1. It is evaluated as an XPath expression against an instance document =
(datastore), which results in a node set. If "require-instance" is true, =
then at least one node in that node set must have the same value as the =
leaf with leafref type. This is the original 6020 meaning.

2. It also implicitly refers to a leaf node in the schema, and the =
*type* of this other leaf node determines the type and set of valid =
values for the leaf with learef type. This is independent of the =
"require-instance" value and any datastore content. However, any =
semantic constraints that may apply to the other leaf (such as "must" =
statements) are not taken into account.    =20

Lada

>=20
> If the leaf with the leafref type represents configuration data, and
> the "require-instance" property (Section 9.9.3) is "true", then the
> target of the "path" substatement MUST also represent configuration
> data.
>=20
> Tom Petch
>=20
>> /martin
>>=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: E74E8C0C





From nobody Mon May 30 00:42:58 2016
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 6760B12D173 for ; Mon, 30 May 2016 00:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 D_kwLLlV5Zp5 for ; Mon, 30 May 2016 00:42:55 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F08D612D16F for ; Mon, 30 May 2016 00:42:54 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id D64B41AE030A; Mon, 30 May 2016 09:42:52 +0200 (CEST)
Date: Mon, 30 May 2016 09:43:14 +0200 (CEST)
Message-Id: <20160530.094314.230957185006325635.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <4CD8009E-E3BE-409D-8439-53876375CEF7@nic.cz>
References: <20160523.161038.800274078120441332.mbj@tail-f.com> <008201d1b83d$72f91f60$4001a8c0@gateway.2wire.net> <4CD8009E-E3BE-409D-8439-53876375CEF7@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: worley@ariadne.com, netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 07:42:57 -0000

Ladislav Lhotka  wrote:
> 
> > On 27 May 2016, at 19:30, t.petch  wrote:
> > 
> > 
> > ----- Original Message -----
> > From: "Martin Bjorklund" 
> > To: 
> > Sent: Monday, May 23, 2016 3:10 PM
> >> 
> >> This comment from the Gen-ART review deserves it's own thread.
> >> 
> >> gen-art> - section 9.9
> >> gen-art>
> >> gen-art>    The leafref type is used to declare a constraint on the
> > value space
> >> gen-art>    of a leaf, based on a reference to a set of leaf instances
> > in the
> >> gen-art>    data tree.  The "path" substatement (Section 9.9.2)
> > selects a set of
> >> gen-art>    leaf instances, and the leafref value space is the set of
> > values of
> >> gen-art>    these leaf instances.
> >> gen-art>
> >> gen-art> The first sentence isn't quite right.  Perhaps:
> >> gen-art>
> >> gen-art>    The value space of a leaf with leafref type is one of the
> > values of
> >> gen-art>    a set of leaf instances in the data tree.  The "path"
> > substatement
> >> gen-art>    (Section 9.9.2) selects the set of leaf instances, and the
> > leafref
> >> gen-art>    value space is the set of values of these leaf instances.
> >> gen-art>
> >> gen-art> - section 9.9.3
> >> gen-art>
> >> gen-art>    If "require-instance" is "true", it means that the
> > instance being
> >> gen-art>    referred MUST exist for the data to be valid.  This
> > constraint is
> >> gen-art>    enforced according to the rules in Section 8.
> >> gen-art>
> >> gen-art>    If "require-instance" is "false", it means that the
> > instance being
> >> gen-art>    referred MAY exist in valid data.
> >> gen-art>
> >> [...]
> >> gen-art> Also, I think the second paragraph means that if
> > require-instance is
> >> gen-art> false, the referred-to instance need not exist.  But it's not
> > clear to
> >> gen-art> me what that would mean -- if there are no instances
> > referenced by the
> >> gen-art> XPath expression, then the set of value values of the leafref
> > would be
> >> gen-art> empty and the leafref would necessarily be invalid. ...  I
> > think these
> >> gen-art> paragraphs need to be expanded in some way.
> >> 
> >> mbj> Right; so what we want to say is:
> >> mbj>
> >> mbj>   - the value space is the same as the value space of the
> > referred
> >> mbj>     leaf
> >> mbj>
> >> mbj>   - there is an additional constraint if require-instance is true
> > that
> >> mbj>     the referred to leaf instance must exist
> >> mbj>
> >> mbj> How about
> >> mbj>
> >> mbj> OLD:
> >> mbj>
> >> mbj>    The leafref type is used to declare a constraint on the value
> > space
> >> mbj>    of a leaf, based on a reference to a set of leaf instances in
> > the
> >> mbj>    data tree.  The "path" substatement (Section 9.9.2) selects a
> > set of
> >> mbj>    leaf instances, and the leafref value space is the set of
> > values of
> >> mbj>    these leaf instances.
> >> mbj>
> >> mbj>    If the leaf with the leafref type represents configuration
> > data, and
> >> mbj>    the "require-instance" property (Section 9.9.3) is "true", the
> > leaf
> >> mbj>    it refers to MUST also represent configuration.  Such a leaf
> > puts a
> >> mbj>    constraint on valid data.  All such nodes MUST reference
> > existing
> >> mbj>    leaf instances or leafs with default values in use (see
> > Section 7.6.1
> >> mbj>    and Section 7.7.2) for the data to be valid.  This constraint
> > is
> >> mbj>    enforced according to the rules in Section 8.
> >> mbj>
> >> mbj> NEW:
> >> mbj>
> >> mbj>    The leafref type is used to declare a constraint on the value
> > space
> >> mbj>    of a leaf, based on a reference to a set of leaf instances in
> > the
> >> mbj>    data tree.  The "path" substatement (Section 9.9.2) is used to
> > refer
> >> mbj>    to another leaf node.  The leafref value space is the value
> > space of
> >> mbj>    this leaf node.
> >> mbj>
> >> mbj>    If the "require-instance" property is "true", there MUST exist
> > an
> >> mbj>    instance, or a leaf with a default value in use (see Section
> > 7.6.1
> >> mbj>    and Section 7.7.2), of the leaf being referred to with the
> > same value
> >> mbj>    as the leafref value in a valid data tree.
> >> mbj>
> >> mbj>    If the leaf with the leafref type represents configuration
> > data, and
> >> mbj>    the "require-instance" property (Section 9.9.3) is "true", the
> > leaf
> >> mbj>    it refers to MUST also represent configuration.
> >> 
> >> Does anyone have comments on this proposal?
> > 
> > yes!
> > 
> > I realise that the discussion is moving on, and corner cases are
> > appearing, but I think that the NEW paragraph is still a tough read.
> > I
> > rearrange the words  - more or less  -and get
> > 
> > NEW
> > 
> > The leafref type is used to declare a constraint on the value space of
> > a
> > leaf.
> > 
> > The "path" substatement (Section 9.9.2) which MUST be present
> > references
> > another leaf node. The value space of this other leaf node defines a
> > set
> > of values, which may be empty (e.g. when the leaf node is not present
> > in
> > the data tree).
> > 
> > If the "require-instance" property is "true", then the value of the
> > leaf
> > with the leafref type MUST exist in the set of values; the set of
> > value
> > includes leafs with have a default value in use (see Section 7.6.1 and
> > Section 7.7.2)
> 
> I think this not correct.

I agree.  Tom, note that the proposal has gone through a couple of
iterations already.  The latest proposal is in
https://mailarchive.ietf.org/arch/msg/netmod/V3-S4enTYpWM24Ws5DWYpEKIq3I


> Unlike RFC 6020, the "path" argument is now
> used for two different purposes:
> 
> 1. It is evaluated as an XPath expression against an instance document
> (datastore), which results in a node set. If "require-instance" is
> true, then at least one node in that node set must have the same value
> as the leaf with leafref type. This is the original 6020 meaning.

Maybe.  6020 also says:

   If the leaf with the leafref type represents configuration data, the
   leaf it refers to MUST also represent configuration.  Such a leaf
   puts a constraint on valid data.  All leafref nodes MUST reference
   existing leaf instances or leafs with default values in use (see
   Section 7.6.1) for the data to be valid.  This constraint is enforced
   according to the rules in Section 8.

which indicates that the intention is that the constraint is *only*
enforced in "valid data".

I think that this is a bug in 6020.

I'm pretty sure that no implementation has implemented this the way it
is described.  Specifically, I think that implementations that support
the candidate datastore allows "non-existing" leafrefs in the
candidate.


/martin

> 2. It also implicitly refers to a leaf node in the schema, and the
> *type* of this other leaf node determines the type and set of valid
> values for the leaf with learef type. This is independent of the
> "require-instance" value and any datastore content. However, any
> semantic constraints that may apply to the other leaf (such as "must"
> statements) are not taken into account.
> 
> Lada
> 
> > 
> > If the leaf with the leafref type represents configuration data, and
> > the "require-instance" property (Section 9.9.3) is "true", then the
> > target of the "path" substatement MUST also represent configuration
> > data.
> > 
> > Tom Petch
> > 
> >> /martin
> >> 
> >> _______________________________________________
> >> 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: E74E8C0C
> 
> 
> 
> 


From nobody Mon May 30 01:05:24 2016
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 9679312D179 for ; Mon, 30 May 2016 01:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 ZldPvAZKhcIx for ; Mon, 30 May 2016 01:05:18 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BAF12D16B for ; Mon, 30 May 2016 01:05:16 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:10b3:51b0:595a:8861] (unknown [IPv6:2001:718:1a02:1:10b3:51b0:595a:8861]) by mail.nic.cz (Postfix) with ESMTPSA id A81BE600E4; Mon, 30 May 2016 10:05:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464595514; bh=mPcJn4ZjQtWfdC6jc5mrz6tAGg02w0WB39PXP84u3u4=; h=From:Date:To; b=fDojt8NR55qVxZNTVvohCvkSFKcwACKpvxWQB2nrYb3QulotSg6b3JWYAT8mR5M8b x4JGI7YTxn3l7+V42SFjlkW61wD7kkVZaN7/rWdwAllg/ZmeUduQZBVuzCpypkPO/4 yp7ye1+USSENPlFdg1R5c1DCUne/kYOO6Q3mBm8k=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160530.094314.230957185006325635.mbj@tail-f.com>
Date: Mon, 30 May 2016 10:05:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <419C08EB-7591-4D0F-A19B-C258FC6A155B@nic.cz>
References: <20160523.161038.800274078120441332.mbj@tail-f.com> <008201d1b83d$72f91f60$4001a8c0@gateway.2wire.net> <4CD8009E-E3BE-409D-8439-53876375CEF7@nic.cz> <20160530.094314.230957185006325635.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: worley@ariadne.com, NETMOD WG 
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 08:05:22 -0000

> On 30 May 2016, at 09:43, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 27 May 2016, at 19:30, t.petch  wrote:
>>>=20
>>>=20
>>> ----- Original Message -----
>>> From: "Martin Bjorklund" 
>>> To: 
>>> Sent: Monday, May 23, 2016 3:10 PM
>>>>=20
>>>> This comment from the Gen-ART review deserves it's own thread.
>>>>=20
>>>> gen-art> - section 9.9
>>>> gen-art>
>>>> gen-art>    The leafref type is used to declare a constraint on the
>>> value space
>>>> gen-art>    of a leaf, based on a reference to a set of leaf =
instances
>>> in the
>>>> gen-art>    data tree.  The "path" substatement (Section 9.9.2)
>>> selects a set of
>>>> gen-art>    leaf instances, and the leafref value space is the set =
of
>>> values of
>>>> gen-art>    these leaf instances.
>>>> gen-art>
>>>> gen-art> The first sentence isn't quite right.  Perhaps:
>>>> gen-art>
>>>> gen-art>    The value space of a leaf with leafref type is one of =
the
>>> values of
>>>> gen-art>    a set of leaf instances in the data tree.  The "path"
>>> substatement
>>>> gen-art>    (Section 9.9.2) selects the set of leaf instances, and =
the
>>> leafref
>>>> gen-art>    value space is the set of values of these leaf =
instances.
>>>> gen-art>
>>>> gen-art> - section 9.9.3
>>>> gen-art>
>>>> gen-art>    If "require-instance" is "true", it means that the
>>> instance being
>>>> gen-art>    referred MUST exist for the data to be valid.  This
>>> constraint is
>>>> gen-art>    enforced according to the rules in Section 8.
>>>> gen-art>
>>>> gen-art>    If "require-instance" is "false", it means that the
>>> instance being
>>>> gen-art>    referred MAY exist in valid data.
>>>> gen-art>
>>>> [...]
>>>> gen-art> Also, I think the second paragraph means that if
>>> require-instance is
>>>> gen-art> false, the referred-to instance need not exist.  But it's =
not
>>> clear to
>>>> gen-art> me what that would mean -- if there are no instances
>>> referenced by the
>>>> gen-art> XPath expression, then the set of value values of the =
leafref
>>> would be
>>>> gen-art> empty and the leafref would necessarily be invalid. ...  I
>>> think these
>>>> gen-art> paragraphs need to be expanded in some way.
>>>>=20
>>>> mbj> Right; so what we want to say is:
>>>> mbj>
>>>> mbj>   - the value space is the same as the value space of the
>>> referred
>>>> mbj>     leaf
>>>> mbj>
>>>> mbj>   - there is an additional constraint if require-instance is =
true
>>> that
>>>> mbj>     the referred to leaf instance must exist
>>>> mbj>
>>>> mbj> How about
>>>> mbj>
>>>> mbj> OLD:
>>>> mbj>
>>>> mbj>    The leafref type is used to declare a constraint on the =
value
>>> space
>>>> mbj>    of a leaf, based on a reference to a set of leaf instances =
in
>>> the
>>>> mbj>    data tree.  The "path" substatement (Section 9.9.2) selects =
a
>>> set of
>>>> mbj>    leaf instances, and the leafref value space is the set of
>>> values of
>>>> mbj>    these leaf instances.
>>>> mbj>
>>>> mbj>    If the leaf with the leafref type represents configuration
>>> data, and
>>>> mbj>    the "require-instance" property (Section 9.9.3) is "true", =
the
>>> leaf
>>>> mbj>    it refers to MUST also represent configuration.  Such a =
leaf
>>> puts a
>>>> mbj>    constraint on valid data.  All such nodes MUST reference
>>> existing
>>>> mbj>    leaf instances or leafs with default values in use (see
>>> Section 7.6.1
>>>> mbj>    and Section 7.7.2) for the data to be valid.  This =
constraint
>>> is
>>>> mbj>    enforced according to the rules in Section 8.
>>>> mbj>
>>>> mbj> NEW:
>>>> mbj>
>>>> mbj>    The leafref type is used to declare a constraint on the =
value
>>> space
>>>> mbj>    of a leaf, based on a reference to a set of leaf instances =
in
>>> the
>>>> mbj>    data tree.  The "path" substatement (Section 9.9.2) is used =
to
>>> refer
>>>> mbj>    to another leaf node.  The leafref value space is the value
>>> space of
>>>> mbj>    this leaf node.
>>>> mbj>
>>>> mbj>    If the "require-instance" property is "true", there MUST =
exist
>>> an
>>>> mbj>    instance, or a leaf with a default value in use (see =
Section
>>> 7.6.1
>>>> mbj>    and Section 7.7.2), of the leaf being referred to with the
>>> same value
>>>> mbj>    as the leafref value in a valid data tree.
>>>> mbj>
>>>> mbj>    If the leaf with the leafref type represents configuration
>>> data, and
>>>> mbj>    the "require-instance" property (Section 9.9.3) is "true", =
the
>>> leaf
>>>> mbj>    it refers to MUST also represent configuration.
>>>>=20
>>>> Does anyone have comments on this proposal?
>>>=20
>>> yes!
>>>=20
>>> I realise that the discussion is moving on, and corner cases are
>>> appearing, but I think that the NEW paragraph is still a tough read.
>>> I
>>> rearrange the words  - more or less  -and get
>>>=20
>>> NEW
>>>=20
>>> The leafref type is used to declare a constraint on the value space =
of
>>> a
>>> leaf.
>>>=20
>>> The "path" substatement (Section 9.9.2) which MUST be present
>>> references
>>> another leaf node. The value space of this other leaf node defines a
>>> set
>>> of values, which may be empty (e.g. when the leaf node is not =
present
>>> in
>>> the data tree).
>>>=20
>>> If the "require-instance" property is "true", then the value of the
>>> leaf
>>> with the leafref type MUST exist in the set of values; the set of
>>> value
>>> includes leafs with have a default value in use (see Section 7.6.1 =
and
>>> Section 7.7.2)
>>=20
>> I think this not correct.
>=20
> I agree.  Tom, note that the proposal has gone through a couple of
> iterations already.  The latest proposal is in
> =
https://mailarchive.ietf.org/arch/msg/netmod/V3-S4enTYpWM24Ws5DWYpEKIq3I
>=20
>=20
>> Unlike RFC 6020, the "path" argument is now
>> used for two different purposes:
>>=20
>> 1. It is evaluated as an XPath expression against an instance =
document
>> (datastore), which results in a node set. If "require-instance" is
>> true, then at least one node in that node set must have the same =
value
>> as the leaf with leafref type. This is the original 6020 meaning.
>=20
> Maybe.  6020 also says:
>=20
>   If the leaf with the leafref type represents configuration data, the
>   leaf it refers to MUST also represent configuration.  Such a leaf
>   puts a constraint on valid data.  All leafref nodes MUST reference
>   existing leaf instances or leafs with default values in use (see
>   Section 7.6.1) for the data to be valid.  This constraint is =
enforced
>   according to the rules in Section 8.
>=20
> which indicates that the intention is that the constraint is *only*
> enforced in "valid data".
>=20
> I think that this is a bug in 6020.

Hmm, I agree the second sentence in the original formulation was =
unclear, but I've always thought it meant simply "Such a leaf introduces =
a semantic constraint", and that's also how it is handled in DSDL (see =
sec. 12.10 in RFC 6110).

Note that the phrase "put/declare a constraint on valid data" is used in =
other places in 6020bis. If the meaning is different from the above, =
then I am confused. =20

>=20
> I'm pretty sure that no implementation has implemented this the way it
> is described.  Specifically, I think that implementations that support
> the candidate datastore allows "non-existing" leafrefs in the
> candidate.

Isn't it what sec. 8.3.3 in RFC 6020 prescribes?

   If the datastore is , the constraint enforcement is =
delayed
   until a  or  operation.

Lada

>=20
>=20
> /martin
>=20
>> 2. It also implicitly refers to a leaf node in the schema, and the
>> *type* of this other leaf node determines the type and set of valid
>> values for the leaf with learef type. This is independent of the
>> "require-instance" value and any datastore content. However, any
>> semantic constraints that may apply to the other leaf (such as "must"
>> statements) are not taken into account.
>>=20
>> Lada
>>=20
>>>=20
>>> If the leaf with the leafref type represents configuration data, and
>>> the "require-instance" property (Section 9.9.3) is "true", then the
>>> target of the "path" substatement MUST also represent configuration
>>> data.
>>>=20
>>> Tom Petch
>>>=20
>>>> /martin
>>>>=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
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Mon May 30 01:14:31 2016
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 1D96F12D17D for ; Mon, 30 May 2016 01:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 br0BSvU0ovfx for ; Mon, 30 May 2016 01:14:27 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EFE9D12D191 for ; Mon, 30 May 2016 01:14:26 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 8EF921AE043F; Mon, 30 May 2016 10:14:23 +0200 (CEST)
Date: Mon, 30 May 2016 10:14:44 +0200 (CEST)
Message-Id: <20160530.101444.331230892284587762.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <419C08EB-7591-4D0F-A19B-C258FC6A155B@nic.cz>
References: <4CD8009E-E3BE-409D-8439-53876375CEF7@nic.cz> <20160530.094314.230957185006325635.mbj@tail-f.com> <419C08EB-7591-4D0F-A19B-C258FC6A155B@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: worley@ariadne.com, netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 08:14:29 -0000

Ladislav Lhotka  wrote:
> 
> > On 30 May 2016, at 09:43, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> 
> >>> On 27 May 2016, at 19:30, t.petch  wrote:
> >>> 
> >>> 
> >>> ----- Original Message -----
> >>> From: "Martin Bjorklund" 
> >>> To: 
> >>> Sent: Monday, May 23, 2016 3:10 PM
> >>>> 
> >>>> This comment from the Gen-ART review deserves it's own thread.
> >>>> 
> >>>> gen-art> - section 9.9
> >>>> gen-art>
> >>>> gen-art>    The leafref type is used to declare a constraint on the
> >>> value space
> >>>> gen-art>    of a leaf, based on a reference to a set of leaf instances
> >>> in the
> >>>> gen-art>    data tree.  The "path" substatement (Section 9.9.2)
> >>> selects a set of
> >>>> gen-art>    leaf instances, and the leafref value space is the set of
> >>> values of
> >>>> gen-art>    these leaf instances.
> >>>> gen-art>
> >>>> gen-art> The first sentence isn't quite right.  Perhaps:
> >>>> gen-art>
> >>>> gen-art>    The value space of a leaf with leafref type is one of the
> >>> values of
> >>>> gen-art>    a set of leaf instances in the data tree.  The "path"
> >>> substatement
> >>>> gen-art>    (Section 9.9.2) selects the set of leaf instances, and the
> >>> leafref
> >>>> gen-art>    value space is the set of values of these leaf instances.
> >>>> gen-art>
> >>>> gen-art> - section 9.9.3
> >>>> gen-art>
> >>>> gen-art>    If "require-instance" is "true", it means that the
> >>> instance being
> >>>> gen-art>    referred MUST exist for the data to be valid.  This
> >>> constraint is
> >>>> gen-art>    enforced according to the rules in Section 8.
> >>>> gen-art>
> >>>> gen-art>    If "require-instance" is "false", it means that the
> >>> instance being
> >>>> gen-art>    referred MAY exist in valid data.
> >>>> gen-art>
> >>>> [...]
> >>>> gen-art> Also, I think the second paragraph means that if
> >>> require-instance is
> >>>> gen-art> false, the referred-to instance need not exist.  But it's not
> >>> clear to
> >>>> gen-art> me what that would mean -- if there are no instances
> >>> referenced by the
> >>>> gen-art> XPath expression, then the set of value values of the leafref
> >>> would be
> >>>> gen-art> empty and the leafref would necessarily be invalid. ...  I
> >>> think these
> >>>> gen-art> paragraphs need to be expanded in some way.
> >>>> 
> >>>> mbj> Right; so what we want to say is:
> >>>> mbj>
> >>>> mbj>   - the value space is the same as the value space of the
> >>> referred
> >>>> mbj>     leaf
> >>>> mbj>
> >>>> mbj>   - there is an additional constraint if require-instance is true
> >>> that
> >>>> mbj>     the referred to leaf instance must exist
> >>>> mbj>
> >>>> mbj> How about
> >>>> mbj>
> >>>> mbj> OLD:
> >>>> mbj>
> >>>> mbj>    The leafref type is used to declare a constraint on the value
> >>> space
> >>>> mbj>    of a leaf, based on a reference to a set of leaf instances in
> >>> the
> >>>> mbj>    data tree.  The "path" substatement (Section 9.9.2) selects a
> >>> set of
> >>>> mbj>    leaf instances, and the leafref value space is the set of
> >>> values of
> >>>> mbj>    these leaf instances.
> >>>> mbj>
> >>>> mbj>    If the leaf with the leafref type represents configuration
> >>> data, and
> >>>> mbj>    the "require-instance" property (Section 9.9.3) is "true", the
> >>> leaf
> >>>> mbj>    it refers to MUST also represent configuration.  Such a leaf
> >>> puts a
> >>>> mbj>    constraint on valid data.  All such nodes MUST reference
> >>> existing
> >>>> mbj>    leaf instances or leafs with default values in use (see
> >>> Section 7.6.1
> >>>> mbj>    and Section 7.7.2) for the data to be valid.  This constraint
> >>> is
> >>>> mbj>    enforced according to the rules in Section 8.
> >>>> mbj>
> >>>> mbj> NEW:
> >>>> mbj>
> >>>> mbj>    The leafref type is used to declare a constraint on the value
> >>> space
> >>>> mbj>    of a leaf, based on a reference to a set of leaf instances in
> >>> the
> >>>> mbj>    data tree.  The "path" substatement (Section 9.9.2) is used to
> >>> refer
> >>>> mbj>    to another leaf node.  The leafref value space is the value
> >>> space of
> >>>> mbj>    this leaf node.
> >>>> mbj>
> >>>> mbj>    If the "require-instance" property is "true", there MUST exist
> >>> an
> >>>> mbj>    instance, or a leaf with a default value in use (see Section
> >>> 7.6.1
> >>>> mbj>    and Section 7.7.2), of the leaf being referred to with the
> >>> same value
> >>>> mbj>    as the leafref value in a valid data tree.
> >>>> mbj>
> >>>> mbj>    If the leaf with the leafref type represents configuration
> >>> data, and
> >>>> mbj>    the "require-instance" property (Section 9.9.3) is "true", the
> >>> leaf
> >>>> mbj>    it refers to MUST also represent configuration.
> >>>> 
> >>>> Does anyone have comments on this proposal?
> >>> 
> >>> yes!
> >>> 
> >>> I realise that the discussion is moving on, and corner cases are
> >>> appearing, but I think that the NEW paragraph is still a tough read.
> >>> I
> >>> rearrange the words  - more or less  -and get
> >>> 
> >>> NEW
> >>> 
> >>> The leafref type is used to declare a constraint on the value space of
> >>> a
> >>> leaf.
> >>> 
> >>> The "path" substatement (Section 9.9.2) which MUST be present
> >>> references
> >>> another leaf node. The value space of this other leaf node defines a
> >>> set
> >>> of values, which may be empty (e.g. when the leaf node is not present
> >>> in
> >>> the data tree).
> >>> 
> >>> If the "require-instance" property is "true", then the value of the
> >>> leaf
> >>> with the leafref type MUST exist in the set of values; the set of
> >>> value
> >>> includes leafs with have a default value in use (see Section 7.6.1 and
> >>> Section 7.7.2)
> >> 
> >> I think this not correct.
> > 
> > I agree.  Tom, note that the proposal has gone through a couple of
> > iterations already.  The latest proposal is in
> > https://mailarchive.ietf.org/arch/msg/netmod/V3-S4enTYpWM24Ws5DWYpEKIq3I
> > 
> > 
> >> Unlike RFC 6020, the "path" argument is now
> >> used for two different purposes:
> >> 
> >> 1. It is evaluated as an XPath expression against an instance document
> >> (datastore), which results in a node set. If "require-instance" is
> >> true, then at least one node in that node set must have the same value
> >> as the leaf with leafref type. This is the original 6020 meaning.
> > 
> > Maybe.  6020 also says:
> > 
> >   If the leaf with the leafref type represents configuration data, the
> >   leaf it refers to MUST also represent configuration.  Such a leaf
> >   puts a constraint on valid data.  All leafref nodes MUST reference
> >   existing leaf instances or leafs with default values in use (see
> >   Section 7.6.1) for the data to be valid.  This constraint is enforced
> >   according to the rules in Section 8.
> > 
> > which indicates that the intention is that the constraint is *only*
> > enforced in "valid data".
> > 
> > I think that this is a bug in 6020.
> 
> Hmm, I agree the second sentence in the original formulation was
> unclear, but I've always thought it meant simply "Such a leaf
> introduces a semantic constraint", and that's also how it is handled
> in DSDL (see sec. 12.10 in RFC 6110).
> 
> Note that the phrase "put/declare a constraint on valid data" is used
> in other places in 6020bis. If the meaning is different from the
> above, then I am confused.

See below.

> > I'm pretty sure that no implementation has implemented this the way it
> > is described.  Specifically, I think that implementations that support
> > the candidate datastore allows "non-existing" leafrefs in the
> > candidate.
> 
> Isn't it what sec. 8.3.3 in RFC 6020 prescribes?
> 
>    If the datastore is , the constraint enforcement is
>    delayed
>    until a  or  operation.

Right; so the bug in 6020 is this text:

   The "path" substatement (Section 9.9.2) selects a set
   of leaf instances, and the leafref value space is the set of values
   of these leaf instances.


This is not correct for the candidate.  This text means for example
that if there are no target instances in the candidate, the value
space for the leafref would be empty, and it wouldn't be possible to
set the leafref leaf in the candidate.

Hence the proposal to fix this bug in 6020.


/martin


From nobody Mon May 30 01:41:39 2016
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 52C7B12D193 for ; Mon, 30 May 2016 01:41:38 -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 I7mipdzNa90E for ; Mon, 30 May 2016 01:41:36 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B262B12D120 for ; Mon, 30 May 2016 01:41:35 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3DF761CC028D; Mon, 30 May 2016 10:41:37 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de
In-Reply-To: <20160524.121304.799281134866976977.mbj@tail-f.com>
References: <20160524081508.GA9434@elstar.local> <20160524.103329.1771107175898375865.mbj@tail-f.com> <20160524095609.GA9643@elstar.local> <20160524.121304.799281134866976977.mbj@tail-f.com>
User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 30 May 2016 10:41:45 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 08:41:38 -0000

Martin Bjorklund  writes:

> Juergen Schoenwaelder  wrote:
>> On Tue, May 24, 2016 at 10:33:29AM +0200, Martin Bjorklund wrote:
>> > Juergen Schoenwaelder  wrote:
>> > > On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
>> > > 
>> > > [...]
>> > >  
>> > > > This mixes up paths in the data tree with those in the schema tree. The XPath expression in the "path" statement is evaluated in the context of a data tree, but if the result is an empty node set, then "this leaf node" makes no sense.
>> > > > 
>> > > > A specific example:
>> > > > 
>> > > > leaf fooref {
>> > > >   type leafref {
>> > > >     path "../foo";
>> > > >     require-instance false;
>> > > >   }
>> > > > }
>> > > > 
>> > > > leaf foo {
>> > > >   type uint8;
>> > > >   when "../bar < 42";
>> > > > }
>> > > > 
>> > > > leaf bar {   
>> > > >   type uint8;
>> > > >   default 100;
>> > > > }
>> > > > 
>> > > > If there is neither "foo" nor "bar" in the data tree, what is the value space of "fooref"?
>> > > >
>> > > 
>> > > Hm. Is it not both? The path refers to a schema node in order to
>> > > determine the base type (which is the base value set if
>> > > require-instance is false). If require-instance is true, then there is
>> > > an additional constraint that refers to a set of data nodes that
>> > > essentially determine a (possibly empty) subset of the value space.
>> > > 
>> > > If you agree with this, then we essentially have to phrase this
>> > > clearly.
>> > 
>> > Exactly.  My proposal was:
>> > 
>> > OLD:
>> > 
>> >    The leafref type is used to declare a constraint on the value space
>> >    of a leaf, based on a reference to a set of leaf instances in the
>> >    data tree.  The "path" substatement (Section 9.9.2) selects a set of
>> >    leaf instances, and the leafref value space is the set of values of
>> >    these leaf instances.
>> > 
>> >    If the leaf with the leafref type represents configuration data, and
>> >    the "require-instance" property (Section 9.9.3) is "true", the leaf
>> >    it refers to MUST also represent configuration.  Such a leaf puts a
>> >    constraint on valid data.  All such nodes MUST reference existing
>> >    leaf instances or leafs with default values in use (see Section 7.6.1
>> >    and Section 7.7.2) for the data to be valid.  This constraint is
>> >    enforced according to the rules in Section 8.
>> > 
>> > NEW:
>> > 
>> >    The leafref type is used to declare a constraint on the value space
>> >    of a leaf, based on a reference to a set of leaf instances in the
>> >    data tree.  The "path" substatement (Section 9.9.2) is used to refer
>> >    to another leaf node.  The leafref value space is the value space of
>> >    this leaf node.
>> > 
>> >    If the "require-instance" property is "true", there MUST exist an
>> >    instance, or a leaf with a default value in use (see Section 7.6.1
>> >    and Section 7.7.2), of the leaf being referred to with the same value
>> >    as the leafref value in a valid data tree.
>> > 
>> >    If the leaf with the leafref type represents configuration data, and
>> >    the "require-instance" property (Section 9.9.3) is "true", the leaf
>> >    it refers to MUST also represent configuration.
>> > 
>> > 
>> > Please comment and/or suggest improvements to this proposal.
>> >
>> 
>> I will give it a try. I think it is helpful to define referring node
>> and referred node
>
> Ok.
>
>> and I think it is useful to first state the purpose
>> of the leafref type.
>> 
>>   The leafref type is restricted to the value set of some leaf node in
>>   the schema tree and optionally further restricted by corresponding
>>   instance nodes in the data tree. More precisely, the leafref type
>>   declares a constraint on the value space of a leaf node (the
>>   referring leaf node), based on a reference to a another leaf node in
>>   the schema tree (the referred leaf node). The "path" substatement
>>   (Section 9.9.2) is used to identify the referred leaf node in the
>>   schema tree. The value set of the referring leaf node is the value
>>   set of the referred leaf node if the "require-instance" property is
>>   "false".
>
> Maybe remove the second sentence.  Also s/value set/value space/.
> Also the last sentence isn't correct; the value space is always the
> value space of the referred node.
>
>>   If the "require-instance" property is "true", there MUST exist an node
>>   in the data tree, or a node with a default value in use (see Section
>>   7.6.1 and Section 7.7.2), of the referred schema tree leaf node with
>>   the same value as the leafref value in a valid data tree.
>> 
>>   If the referring leaf node represents configuration data, and the
>>   "require-instance" property (Section 9.9.3) is "true", the referred
>>   leaf node MUST also represent configuration.
>
> Also, the text needs to mention leaf-lists.  This gives:
>
>
>   The leafref type is restricted to the value space of some leaf or
>   leaf-list node in the schema tree and optionally further restricted
>   by corresponding instance nodes in the data tree.  The "path"
>   substatement (Section 9.9.2) is used to identify the referred leaf
>   or leaf-list node in the schema tree. The value space of the
>   referring node is the value space of the referred node.

The term "value space" is not defined in 6020bis, but IMO this is not correct.
For example:

  leaf foo {
    type uint8;
    must ". mod 2 = 0";
  }

Arguably, the value space of this leaf consists only of even numbers. If
"bar" is a leafref that refers to "foo", what is its value space? My
understanding is that it is the whole uint8 range, i.e. the value space
of the *type* of "foo".

Lada

>
>   If the "require-instance" property is "true", there MUST exist an
>   node in the data tree, or a node with a default value in use (see
>   Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf
>   or leaf-list node with the same value as the leafref value in a
>   valid data tree.
>
>   If the referring node represents configuration data, and the
>   "require-instance" property (Section 9.9.3) is "true", the referred
>   node MUST also represent configuration.
>
>
>
> /martin

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


From nobody Mon May 30 01:49:17 2016
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 0E3DA12D1A7 for ; Mon, 30 May 2016 01:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 0OCuqhj-ibqT for ; Mon, 30 May 2016 01:49:04 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A23E912D1B7 for ; Mon, 30 May 2016 01:49:04 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id AFE321AE0399; Mon, 30 May 2016 10:49:02 +0200 (CEST)
Date: Mon, 30 May 2016 10:49:24 +0200 (CEST)
Message-Id: <20160530.104924.2094113973837769652.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20160524095609.GA9643@elstar.local> <20160524.121304.799281134866976977.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 08:49:09 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Juergen Schoenwaelder  wrote:
> >> On Tue, May 24, 2016 at 10:33:29AM +0200, Martin Bjorklund wrote:
> >> > Juergen Schoenwaelder  wrote:
> >> > > On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
> >> > > 
> >> > > [...]
> >> > >  
> >> > > > This mixes up paths in the data tree with those in the schema tree. The XPath expression in the "path" statement is evaluated in the context of a data tree, but if the result is an empty node set, then "this leaf node" makes no sense.
> >> > > > 
> >> > > > A specific example:
> >> > > > 
> >> > > > leaf fooref {
> >> > > >   type leafref {
> >> > > >     path "../foo";
> >> > > >     require-instance false;
> >> > > >   }
> >> > > > }
> >> > > > 
> >> > > > leaf foo {
> >> > > >   type uint8;
> >> > > >   when "../bar < 42";
> >> > > > }
> >> > > > 
> >> > > > leaf bar {   
> >> > > >   type uint8;
> >> > > >   default 100;
> >> > > > }
> >> > > > 
> >> > > > If there is neither "foo" nor "bar" in the data tree, what is the value space of "fooref"?
> >> > > >
> >> > > 
> >> > > Hm. Is it not both? The path refers to a schema node in order to
> >> > > determine the base type (which is the base value set if
> >> > > require-instance is false). If require-instance is true, then there is
> >> > > an additional constraint that refers to a set of data nodes that
> >> > > essentially determine a (possibly empty) subset of the value space.
> >> > > 
> >> > > If you agree with this, then we essentially have to phrase this
> >> > > clearly.
> >> > 
> >> > Exactly.  My proposal was:
> >> > 
> >> > OLD:
> >> > 
> >> >    The leafref type is used to declare a constraint on the value space
> >> >    of a leaf, based on a reference to a set of leaf instances in the
> >> >    data tree.  The "path" substatement (Section 9.9.2) selects a set of
> >> >    leaf instances, and the leafref value space is the set of values of
> >> >    these leaf instances.
> >> > 
> >> >    If the leaf with the leafref type represents configuration data, and
> >> >    the "require-instance" property (Section 9.9.3) is "true", the leaf
> >> >    it refers to MUST also represent configuration.  Such a leaf puts a
> >> >    constraint on valid data.  All such nodes MUST reference existing
> >> >    leaf instances or leafs with default values in use (see Section 7.6.1
> >> >    and Section 7.7.2) for the data to be valid.  This constraint is
> >> >    enforced according to the rules in Section 8.
> >> > 
> >> > NEW:
> >> > 
> >> >    The leafref type is used to declare a constraint on the value space
> >> >    of a leaf, based on a reference to a set of leaf instances in the
> >> >    data tree.  The "path" substatement (Section 9.9.2) is used to refer
> >> >    to another leaf node.  The leafref value space is the value space of
> >> >    this leaf node.
> >> > 
> >> >    If the "require-instance" property is "true", there MUST exist an
> >> >    instance, or a leaf with a default value in use (see Section 7.6.1
> >> >    and Section 7.7.2), of the leaf being referred to with the same value
> >> >    as the leafref value in a valid data tree.
> >> > 
> >> >    If the leaf with the leafref type represents configuration data, and
> >> >    the "require-instance" property (Section 9.9.3) is "true", the leaf
> >> >    it refers to MUST also represent configuration.
> >> > 
> >> > 
> >> > Please comment and/or suggest improvements to this proposal.
> >> >
> >> 
> >> I will give it a try. I think it is helpful to define referring node
> >> and referred node
> >
> > Ok.
> >
> >> and I think it is useful to first state the purpose
> >> of the leafref type.
> >> 
> >>   The leafref type is restricted to the value set of some leaf node in
> >>   the schema tree and optionally further restricted by corresponding
> >>   instance nodes in the data tree. More precisely, the leafref type
> >>   declares a constraint on the value space of a leaf node (the
> >>   referring leaf node), based on a reference to a another leaf node in
> >>   the schema tree (the referred leaf node). The "path" substatement
> >>   (Section 9.9.2) is used to identify the referred leaf node in the
> >>   schema tree. The value set of the referring leaf node is the value
> >>   set of the referred leaf node if the "require-instance" property is
> >>   "false".
> >
> > Maybe remove the second sentence.  Also s/value set/value space/.
> > Also the last sentence isn't correct; the value space is always the
> > value space of the referred node.
> >
> >>   If the "require-instance" property is "true", there MUST exist an node
> >>   in the data tree, or a node with a default value in use (see Section
> >>   7.6.1 and Section 7.7.2), of the referred schema tree leaf node with
> >>   the same value as the leafref value in a valid data tree.
> >> 
> >>   If the referring leaf node represents configuration data, and the
> >>   "require-instance" property (Section 9.9.3) is "true", the referred
> >>   leaf node MUST also represent configuration.
> >
> > Also, the text needs to mention leaf-lists.  This gives:
> >
> >
> >   The leafref type is restricted to the value space of some leaf or
> >   leaf-list node in the schema tree and optionally further restricted
> >   by corresponding instance nodes in the data tree.  The "path"
> >   substatement (Section 9.9.2) is used to identify the referred leaf
> >   or leaf-list node in the schema tree. The value space of the
> >   referring node is the value space of the referred node.
> 
> The term "value space" is not defined in 6020bis, but IMO this is not correct.
> For example:
> 
>   leaf foo {
>     type uint8;
>     must ". mod 2 = 0";
>   }
> 
> Arguably, the value space of this leaf consists only of even
> numbers.

No.  The value space is all of uint8.  In the candidate you can have
foo = 43.

The "must" expression adds a constraint.

> If
> "bar" is a leafref that refers to "foo", what is its value space? My
> understanding is that it is the whole uint8 range, i.e. the value space
> of the *type* of "foo".

Yes.


/martin



> 
> Lada
> 
> >
> >   If the "require-instance" property is "true", there MUST exist an
> >   node in the data tree, or a node with a default value in use (see
> >   Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf
> >   or leaf-list node with the same value as the leafref value in a
> >   valid data tree.
> >
> >   If the referring node represents configuration data, and the
> >   "require-instance" property (Section 9.9.3) is "true", the referred
> >   node MUST also represent configuration.
> >
> >
> >
> > /martin
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 


From nobody Mon May 30 01:58:35 2016
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 647D512D19F for ; Mon, 30 May 2016 01:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 78F6NOCvBN3w for ; Mon, 30 May 2016 01:58:32 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DD312D106 for ; Mon, 30 May 2016 01:58:32 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:10b3:51b0:595a:8861] (unknown [IPv6:2001:718:1a02:1:10b3:51b0:595a:8861]) by mail.nic.cz (Postfix) with ESMTPSA id 9554761515; Mon, 30 May 2016 10:58:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464598710; bh=vq576Ai5sNjcoLXI5/M+4p1cvZQDXAr2DGSzjxI+Js4=; h=From:Date:To; b=Gdw7RLwf4GhbOOkh3g0PdAnyDR97ysHH8PgnvDBNKWSo88FIlfBbfPJnLwsLsHm9H XVqt+bx6o/PbSDqPzc06nBUAu8EBCsKtFkO9AYrw0aK6SRhMbT13rqadfEz6VveJ3H fO7yi+5AYE/ROstaJtyIJytno3cye1Q2AKfp64Cs=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160530.104924.2094113973837769652.mbj@tail-f.com>
Date: Mon, 30 May 2016 10:58:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160524095609.GA9643@elstar.local> <20160524.121304.799281134866976977.mbj@tail-f.com>  <20160530.104924.2094113973837769652.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 08:58:34 -0000

> On 30 May 2016, at 10:49, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>>=20
>>> Juergen Schoenwaelder  wrote:
>>>> On Tue, May 24, 2016 at 10:33:29AM +0200, Martin Bjorklund wrote:
>>>>> Juergen Schoenwaelder  =
wrote:
>>>>>> On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
>>>>>>=20
>>>>>> [...]
>>>>>>=20
>>>>>>> This mixes up paths in the data tree with those in the schema =
tree. The XPath expression in the "path" statement is evaluated in the =
context of a data tree, but if the result is an empty node set, then =
"this leaf node" makes no sense.
>>>>>>>=20
>>>>>>> A specific example:
>>>>>>>=20
>>>>>>> leaf fooref {
>>>>>>>  type leafref {
>>>>>>>    path "../foo";
>>>>>>>    require-instance false;
>>>>>>>  }
>>>>>>> }
>>>>>>>=20
>>>>>>> leaf foo {
>>>>>>>  type uint8;
>>>>>>>  when "../bar < 42";
>>>>>>> }
>>>>>>>=20
>>>>>>> leaf bar {  =20
>>>>>>>  type uint8;
>>>>>>>  default 100;
>>>>>>> }
>>>>>>>=20
>>>>>>> If there is neither "foo" nor "bar" in the data tree, what is =
the value space of "fooref"?
>>>>>>>=20
>>>>>>=20
>>>>>> Hm. Is it not both? The path refers to a schema node in order to
>>>>>> determine the base type (which is the base value set if
>>>>>> require-instance is false). If require-instance is true, then =
there is
>>>>>> an additional constraint that refers to a set of data nodes that
>>>>>> essentially determine a (possibly empty) subset of the value =
space.
>>>>>>=20
>>>>>> If you agree with this, then we essentially have to phrase this
>>>>>> clearly.
>>>>>=20
>>>>> Exactly.  My proposal was:
>>>>>=20
>>>>> OLD:
>>>>>=20
>>>>>   The leafref type is used to declare a constraint on the value =
space
>>>>>   of a leaf, based on a reference to a set of leaf instances in =
the
>>>>>   data tree.  The "path" substatement (Section 9.9.2) selects a =
set of
>>>>>   leaf instances, and the leafref value space is the set of values =
of
>>>>>   these leaf instances.
>>>>>=20
>>>>>   If the leaf with the leafref type represents configuration data, =
and
>>>>>   the "require-instance" property (Section 9.9.3) is "true", the =
leaf
>>>>>   it refers to MUST also represent configuration.  Such a leaf =
puts a
>>>>>   constraint on valid data.  All such nodes MUST reference =
existing
>>>>>   leaf instances or leafs with default values in use (see Section =
7.6.1
>>>>>   and Section 7.7.2) for the data to be valid.  This constraint is
>>>>>   enforced according to the rules in Section 8.
>>>>>=20
>>>>> NEW:
>>>>>=20
>>>>>   The leafref type is used to declare a constraint on the value =
space
>>>>>   of a leaf, based on a reference to a set of leaf instances in =
the
>>>>>   data tree.  The "path" substatement (Section 9.9.2) is used to =
refer
>>>>>   to another leaf node.  The leafref value space is the value =
space of
>>>>>   this leaf node.
>>>>>=20
>>>>>   If the "require-instance" property is "true", there MUST exist =
an
>>>>>   instance, or a leaf with a default value in use (see Section =
7.6.1
>>>>>   and Section 7.7.2), of the leaf being referred to with the same =
value
>>>>>   as the leafref value in a valid data tree.
>>>>>=20
>>>>>   If the leaf with the leafref type represents configuration data, =
and
>>>>>   the "require-instance" property (Section 9.9.3) is "true", the =
leaf
>>>>>   it refers to MUST also represent configuration.
>>>>>=20
>>>>>=20
>>>>> Please comment and/or suggest improvements to this proposal.
>>>>>=20
>>>>=20
>>>> I will give it a try. I think it is helpful to define referring =
node
>>>> and referred node
>>>=20
>>> Ok.
>>>=20
>>>> and I think it is useful to first state the purpose
>>>> of the leafref type.
>>>>=20
>>>>  The leafref type is restricted to the value set of some leaf node =
in
>>>>  the schema tree and optionally further restricted by corresponding
>>>>  instance nodes in the data tree. More precisely, the leafref type
>>>>  declares a constraint on the value space of a leaf node (the
>>>>  referring leaf node), based on a reference to a another leaf node =
in
>>>>  the schema tree (the referred leaf node). The "path" substatement
>>>>  (Section 9.9.2) is used to identify the referred leaf node in the
>>>>  schema tree. The value set of the referring leaf node is the value
>>>>  set of the referred leaf node if the "require-instance" property =
is
>>>>  "false".
>>>=20
>>> Maybe remove the second sentence.  Also s/value set/value space/.
>>> Also the last sentence isn't correct; the value space is always the
>>> value space of the referred node.
>>>=20
>>>>  If the "require-instance" property is "true", there MUST exist an =
node
>>>>  in the data tree, or a node with a default value in use (see =
Section
>>>>  7.6.1 and Section 7.7.2), of the referred schema tree leaf node =
with
>>>>  the same value as the leafref value in a valid data tree.
>>>>=20
>>>>  If the referring leaf node represents configuration data, and the
>>>>  "require-instance" property (Section 9.9.3) is "true", the =
referred
>>>>  leaf node MUST also represent configuration.
>>>=20
>>> Also, the text needs to mention leaf-lists.  This gives:
>>>=20
>>>=20
>>>  The leafref type is restricted to the value space of some leaf or
>>>  leaf-list node in the schema tree and optionally further restricted
>>>  by corresponding instance nodes in the data tree.  The "path"
>>>  substatement (Section 9.9.2) is used to identify the referred leaf
>>>  or leaf-list node in the schema tree. The value space of the
>>>  referring node is the value space of the referred node.
>>=20
>> The term "value space" is not defined in 6020bis, but IMO this is not =
correct.
>> For example:
>>=20
>>  leaf foo {
>>    type uint8;
>>    must ". mod 2 =3D 0";
>>  }
>>=20
>> Arguably, the value space of this leaf consists only of even
>> numbers.
>=20
> No.  The value space is all of uint8.  In the candidate you can have
> foo =3D 43.
>=20
> The "must" expression adds a constraint.

Then a definition of "value space" needs to be added to the Terminology =
section. So far, this term has been used in 6020bis only in relation to =
a data type, not a leaf/leaf-list instance.

Lada=20

>=20
>> If
>> "bar" is a leafref that refers to "foo", what is its value space? My
>> understanding is that it is the whole uint8 range, i.e. the value =
space
>> of the *type* of "foo".
>=20
> Yes.
>=20
>=20
> /martin
>=20
>=20
>=20
>>=20
>> Lada
>>=20
>>>=20
>>>  If the "require-instance" property is "true", there MUST exist an
>>>  node in the data tree, or a node with a default value in use (see
>>>  Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf
>>>  or leaf-list node with the same value as the leafref value in a
>>>  valid data tree.
>>>=20
>>>  If the referring node represents configuration data, and the
>>>  "require-instance" property (Section 9.9.3) is "true", the referred
>>>  node MUST also represent configuration.
>>>=20
>>>=20
>>>=20
>>> /martin
>>=20
>> --=20
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Mon May 30 02:09:08 2016
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 E770B12D1A6 for ; Mon, 30 May 2016 02:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 mHEvDbTYNPJh for ; Mon, 30 May 2016 02:09:04 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779B112D120 for ; Mon, 30 May 2016 02:09:04 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:10b3:51b0:595a:8861] (unknown [IPv6:2001:718:1a02:1:10b3:51b0:595a:8861]) by mail.nic.cz (Postfix) with ESMTPSA id 2347C61515; Mon, 30 May 2016 11:09:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464599343; bh=r0x1pKqPESvjLxPch6Ot3GqgeFQBV878/Ch4p2yAklk=; h=From:Date:To; b=XZIBlQEuOPifZlF3HBAQ0u99ZevIuGTgIr9oqM+HnSLqlK7WtaxpcmkA1tqIQQCCA eXMHXyz7UiXI4QviirUZnyRePJXXJxwuBhTQqEl/VVYWmzAQTZT3eCowV4Eevw4XWJ oD50MEEaew9nQy0BgsduzlTeNvLPvRbNDPNEfWiY=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Mon, 30 May 2016 11:09:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160524095609.GA9643@elstar.local> <20160524.121304.799281134866976977.mbj@tail-f.com>  <20160530.104924.2094113973837769652.mbj@tail-f.com> 
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 09:09:07 -0000

> On 30 May 2016, at 10:58, Ladislav Lhotka  wrote:
>=20
>>=20
>> On 30 May 2016, at 10:49, Martin Bjorklund  wrote:
>>=20
>> Ladislav Lhotka  wrote:
>>> Martin Bjorklund  writes:
>>>=20
>>>> Juergen Schoenwaelder  wrote:
>>>>> On Tue, May 24, 2016 at 10:33:29AM +0200, Martin Bjorklund wrote:
>>>>>> Juergen Schoenwaelder  =
wrote:
>>>>>>> On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
>>>>>>>=20
>>>>>>> [...]
>>>>>>>=20
>>>>>>>> This mixes up paths in the data tree with those in the schema =
tree. The XPath expression in the "path" statement is evaluated in the =
context of a data tree, but if the result is an empty node set, then =
"this leaf node" makes no sense.
>>>>>>>>=20
>>>>>>>> A specific example:
>>>>>>>>=20
>>>>>>>> leaf fooref {
>>>>>>>> type leafref {
>>>>>>>>   path "../foo";
>>>>>>>>   require-instance false;
>>>>>>>> }
>>>>>>>> }
>>>>>>>>=20
>>>>>>>> leaf foo {
>>>>>>>> type uint8;
>>>>>>>> when "../bar < 42";
>>>>>>>> }
>>>>>>>>=20
>>>>>>>> leaf bar {  =20
>>>>>>>> type uint8;
>>>>>>>> default 100;
>>>>>>>> }
>>>>>>>>=20
>>>>>>>> If there is neither "foo" nor "bar" in the data tree, what is =
the value space of "fooref"?
>>>>>>>>=20
>>>>>>>=20
>>>>>>> Hm. Is it not both? The path refers to a schema node in order to
>>>>>>> determine the base type (which is the base value set if
>>>>>>> require-instance is false). If require-instance is true, then =
there is
>>>>>>> an additional constraint that refers to a set of data nodes that
>>>>>>> essentially determine a (possibly empty) subset of the value =
space.
>>>>>>>=20
>>>>>>> If you agree with this, then we essentially have to phrase this
>>>>>>> clearly.
>>>>>>=20
>>>>>> Exactly.  My proposal was:
>>>>>>=20
>>>>>> OLD:
>>>>>>=20
>>>>>>  The leafref type is used to declare a constraint on the value =
space
>>>>>>  of a leaf, based on a reference to a set of leaf instances in =
the
>>>>>>  data tree.  The "path" substatement (Section 9.9.2) selects a =
set of
>>>>>>  leaf instances, and the leafref value space is the set of values =
of
>>>>>>  these leaf instances.
>>>>>>=20
>>>>>>  If the leaf with the leafref type represents configuration data, =
and
>>>>>>  the "require-instance" property (Section 9.9.3) is "true", the =
leaf
>>>>>>  it refers to MUST also represent configuration.  Such a leaf =
puts a
>>>>>>  constraint on valid data.  All such nodes MUST reference =
existing
>>>>>>  leaf instances or leafs with default values in use (see Section =
7.6.1
>>>>>>  and Section 7.7.2) for the data to be valid.  This constraint is
>>>>>>  enforced according to the rules in Section 8.
>>>>>>=20
>>>>>> NEW:
>>>>>>=20
>>>>>>  The leafref type is used to declare a constraint on the value =
space
>>>>>>  of a leaf, based on a reference to a set of leaf instances in =
the
>>>>>>  data tree.  The "path" substatement (Section 9.9.2) is used to =
refer
>>>>>>  to another leaf node.  The leafref value space is the value =
space of
>>>>>>  this leaf node.
>>>>>>=20
>>>>>>  If the "require-instance" property is "true", there MUST exist =
an
>>>>>>  instance, or a leaf with a default value in use (see Section =
7.6.1
>>>>>>  and Section 7.7.2), of the leaf being referred to with the same =
value
>>>>>>  as the leafref value in a valid data tree.
>>>>>>=20
>>>>>>  If the leaf with the leafref type represents configuration data, =
and
>>>>>>  the "require-instance" property (Section 9.9.3) is "true", the =
leaf
>>>>>>  it refers to MUST also represent configuration.
>>>>>>=20
>>>>>>=20
>>>>>> Please comment and/or suggest improvements to this proposal.
>>>>>>=20
>>>>>=20
>>>>> I will give it a try. I think it is helpful to define referring =
node
>>>>> and referred node
>>>>=20
>>>> Ok.
>>>>=20
>>>>> and I think it is useful to first state the purpose
>>>>> of the leafref type.
>>>>>=20
>>>>> The leafref type is restricted to the value set of some leaf node =
in
>>>>> the schema tree and optionally further restricted by corresponding
>>>>> instance nodes in the data tree. More precisely, the leafref type
>>>>> declares a constraint on the value space of a leaf node (the
>>>>> referring leaf node), based on a reference to a another leaf node =
in
>>>>> the schema tree (the referred leaf node). The "path" substatement
>>>>> (Section 9.9.2) is used to identify the referred leaf node in the
>>>>> schema tree. The value set of the referring leaf node is the value
>>>>> set of the referred leaf node if the "require-instance" property =
is
>>>>> "false".
>>>>=20
>>>> Maybe remove the second sentence.  Also s/value set/value space/.
>>>> Also the last sentence isn't correct; the value space is always the
>>>> value space of the referred node.
>>>>=20
>>>>> If the "require-instance" property is "true", there MUST exist an =
node
>>>>> in the data tree, or a node with a default value in use (see =
Section
>>>>> 7.6.1 and Section 7.7.2), of the referred schema tree leaf node =
with
>>>>> the same value as the leafref value in a valid data tree.
>>>>>=20
>>>>> If the referring leaf node represents configuration data, and the
>>>>> "require-instance" property (Section 9.9.3) is "true", the =
referred
>>>>> leaf node MUST also represent configuration.
>>>>=20
>>>> Also, the text needs to mention leaf-lists.  This gives:
>>>>=20
>>>>=20
>>>> The leafref type is restricted to the value space of some leaf or
>>>> leaf-list node in the schema tree and optionally further restricted
>>>> by corresponding instance nodes in the data tree.  The "path"
>>>> substatement (Section 9.9.2) is used to identify the referred leaf
>>>> or leaf-list node in the schema tree. The value space of the
>>>> referring node is the value space of the referred node.
>>>=20
>>> The term "value space" is not defined in 6020bis, but IMO this is =
not correct.
>>> For example:
>>>=20
>>> leaf foo {
>>>   type uint8;
>>>   must ". mod 2 =3D 0";
>>> }
>>>=20
>>> Arguably, the value space of this leaf consists only of even
>>> numbers.
>>=20
>> No.  The value space is all of uint8.  In the candidate you can have
>> foo =3D 43.
>>=20
>> The "must" expression adds a constraint.
>=20
> Then a definition of "value space" needs to be added to the =
Terminology section. So far, this term has been used in 6020bis only in =
relation to a data type, not a leaf/leaf-list instance.

Here is a suggestion:

o value space: For a data type, it is the set of values permitted by the =
data type. For a leaf or leaf-list instance, it is the value  space of =
its data type.

Lada

>=20
> Lada=20
>=20
>>=20
>>> If
>>> "bar" is a leafref that refers to "foo", what is its value space? My
>>> understanding is that it is the whole uint8 range, i.e. the value =
space
>>> of the *type* of "foo".
>>=20
>> Yes.
>>=20
>>=20
>> /martin
>>=20
>>=20
>>=20
>>>=20
>>> Lada
>>>=20
>>>>=20
>>>> If the "require-instance" property is "true", there MUST exist an
>>>> node in the data tree, or a node with a default value in use (see
>>>> Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf
>>>> or leaf-list node with the same value as the leafref value in a
>>>> valid data tree.
>>>>=20
>>>> If the referring node represents configuration data, and the
>>>> "require-instance" property (Section 9.9.3) is "true", the referred
>>>> node MUST also represent configuration.
>>>>=20
>>>>=20
>>>>=20
>>>> /martin
>>>=20
>>> --=20
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Mon May 30 03:10:36 2016
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 2820112D0BB for ; Mon, 30 May 2016 03:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 V0JfuaxlPBHG for ; Mon, 30 May 2016 03:10:33 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D677912B077 for ; Mon, 30 May 2016 03:10:32 -0700 (PDT)
Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 592731AE0399; Mon, 30 May 2016 12:10:29 +0200 (CEST)
Date: Mon, 30 May 2016 12:10:50 +0200 (CEST)
Message-Id: <20160530.121050.331732265291028598.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20160530.104924.2094113973837769652.mbj@tail-f.com>  
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 10:10:35 -0000

Ladislav Lhotka  wrote:
> 
> > On 30 May 2016, at 10:58, Ladislav Lhotka  wrote:
> > 
> >> 
> >> On 30 May 2016, at 10:49, Martin Bjorklund  wrote:
> >> 
> >> Ladislav Lhotka  wrote:
> >>> Martin Bjorklund  writes:
> >>> 
> >>>> Juergen Schoenwaelder  wrote:
> >>>>> On Tue, May 24, 2016 at 10:33:29AM +0200, Martin Bjorklund wrote:
> >>>>>> Juergen Schoenwaelder  wrote:
> >>>>>>> On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
> >>>>>>> 
> >>>>>>> [...]
> >>>>>>> 
> >>>>>>>> This mixes up paths in the data tree with those in the schema tree. The XPath expression in the "path" statement is evaluated in the context of a data tree, but if the result is an empty node set, then "this leaf node" makes no sense.
> >>>>>>>> 
> >>>>>>>> A specific example:
> >>>>>>>> 
> >>>>>>>> leaf fooref {
> >>>>>>>> type leafref {
> >>>>>>>>   path "../foo";
> >>>>>>>>   require-instance false;
> >>>>>>>> }
> >>>>>>>> }
> >>>>>>>> 
> >>>>>>>> leaf foo {
> >>>>>>>> type uint8;
> >>>>>>>> when "../bar < 42";
> >>>>>>>> }
> >>>>>>>> 
> >>>>>>>> leaf bar {   
> >>>>>>>> type uint8;
> >>>>>>>> default 100;
> >>>>>>>> }
> >>>>>>>> 
> >>>>>>>> If there is neither "foo" nor "bar" in the data tree, what is the value space of "fooref"?
> >>>>>>>> 
> >>>>>>> 
> >>>>>>> Hm. Is it not both? The path refers to a schema node in order to
> >>>>>>> determine the base type (which is the base value set if
> >>>>>>> require-instance is false). If require-instance is true, then there is
> >>>>>>> an additional constraint that refers to a set of data nodes that
> >>>>>>> essentially determine a (possibly empty) subset of the value space.
> >>>>>>> 
> >>>>>>> If you agree with this, then we essentially have to phrase this
> >>>>>>> clearly.
> >>>>>> 
> >>>>>> Exactly.  My proposal was:
> >>>>>> 
> >>>>>> OLD:
> >>>>>> 
> >>>>>>  The leafref type is used to declare a constraint on the value space
> >>>>>>  of a leaf, based on a reference to a set of leaf instances in the
> >>>>>>  data tree.  The "path" substatement (Section 9.9.2) selects a set of
> >>>>>>  leaf instances, and the leafref value space is the set of values of
> >>>>>>  these leaf instances.
> >>>>>> 
> >>>>>>  If the leaf with the leafref type represents configuration data, and
> >>>>>>  the "require-instance" property (Section 9.9.3) is "true", the leaf
> >>>>>>  it refers to MUST also represent configuration.  Such a leaf puts a
> >>>>>>  constraint on valid data.  All such nodes MUST reference existing
> >>>>>>  leaf instances or leafs with default values in use (see Section 7.6.1
> >>>>>>  and Section 7.7.2) for the data to be valid.  This constraint is
> >>>>>>  enforced according to the rules in Section 8.
> >>>>>> 
> >>>>>> NEW:
> >>>>>> 
> >>>>>>  The leafref type is used to declare a constraint on the value space
> >>>>>>  of a leaf, based on a reference to a set of leaf instances in the
> >>>>>>  data tree.  The "path" substatement (Section 9.9.2) is used to refer
> >>>>>>  to another leaf node.  The leafref value space is the value space of
> >>>>>>  this leaf node.
> >>>>>> 
> >>>>>>  If the "require-instance" property is "true", there MUST exist an
> >>>>>>  instance, or a leaf with a default value in use (see Section 7.6.1
> >>>>>>  and Section 7.7.2), of the leaf being referred to with the same value
> >>>>>>  as the leafref value in a valid data tree.
> >>>>>> 
> >>>>>>  If the leaf with the leafref type represents configuration data, and
> >>>>>>  the "require-instance" property (Section 9.9.3) is "true", the leaf
> >>>>>>  it refers to MUST also represent configuration.
> >>>>>> 
> >>>>>> 
> >>>>>> Please comment and/or suggest improvements to this proposal.
> >>>>>> 
> >>>>> 
> >>>>> I will give it a try. I think it is helpful to define referring node
> >>>>> and referred node
> >>>> 
> >>>> Ok.
> >>>> 
> >>>>> and I think it is useful to first state the purpose
> >>>>> of the leafref type.
> >>>>> 
> >>>>> The leafref type is restricted to the value set of some leaf node in
> >>>>> the schema tree and optionally further restricted by corresponding
> >>>>> instance nodes in the data tree. More precisely, the leafref type
> >>>>> declares a constraint on the value space of a leaf node (the
> >>>>> referring leaf node), based on a reference to a another leaf node in
> >>>>> the schema tree (the referred leaf node). The "path" substatement
> >>>>> (Section 9.9.2) is used to identify the referred leaf node in the
> >>>>> schema tree. The value set of the referring leaf node is the value
> >>>>> set of the referred leaf node if the "require-instance" property is
> >>>>> "false".
> >>>> 
> >>>> Maybe remove the second sentence.  Also s/value set/value space/.
> >>>> Also the last sentence isn't correct; the value space is always the
> >>>> value space of the referred node.
> >>>> 
> >>>>> If the "require-instance" property is "true", there MUST exist an node
> >>>>> in the data tree, or a node with a default value in use (see Section
> >>>>> 7.6.1 and Section 7.7.2), of the referred schema tree leaf node with
> >>>>> the same value as the leafref value in a valid data tree.
> >>>>> 
> >>>>> If the referring leaf node represents configuration data, and the
> >>>>> "require-instance" property (Section 9.9.3) is "true", the referred
> >>>>> leaf node MUST also represent configuration.
> >>>> 
> >>>> Also, the text needs to mention leaf-lists.  This gives:
> >>>> 
> >>>> 
> >>>> The leafref type is restricted to the value space of some leaf or
> >>>> leaf-list node in the schema tree and optionally further restricted
> >>>> by corresponding instance nodes in the data tree.  The "path"
> >>>> substatement (Section 9.9.2) is used to identify the referred leaf
> >>>> or leaf-list node in the schema tree. The value space of the
> >>>> referring node is the value space of the referred node.
> >>> 
> >>> The term "value space" is not defined in 6020bis, but IMO this is not correct.
> >>> For example:
> >>> 
> >>> leaf foo {
> >>>   type uint8;
> >>>   must ". mod 2 = 0";
> >>> }
> >>> 
> >>> Arguably, the value space of this leaf consists only of even
> >>> numbers.
> >> 
> >> No.  The value space is all of uint8.  In the candidate you can have
> >> foo = 43.
> >> 
> >> The "must" expression adds a constraint.
> > 
> > Then a definition of "value space" needs to be added to the Terminology section. So far, this term has been used in 6020bis only in relation to a data type, not a leaf/leaf-list instance.
> 
> Here is a suggestion:
> 
> o value space: For a data type, it is the set of values permitted by
>   the data type. For a leaf or leaf-list instance, it is the value
>   space of its data type.

Ok, but s/instance/node/.


/martin



> 
> Lada
> 
> > 
> > Lada 
> > 
> >> 
> >>> If
> >>> "bar" is a leafref that refers to "foo", what is its value space? My
> >>> understanding is that it is the whole uint8 range, i.e. the value space
> >>> of the *type* of "foo".
> >> 
> >> Yes.
> >> 
> >> 
> >> /martin
> >> 
> >> 
> >> 
> >>> 
> >>> Lada
> >>> 
> >>>> 
> >>>> If the "require-instance" property is "true", there MUST exist an
> >>>> node in the data tree, or a node with a default value in use (see
> >>>> Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf
> >>>> or leaf-list node with the same value as the leafref value in a
> >>>> valid data tree.
> >>>> 
> >>>> If the referring node represents configuration data, and the
> >>>> "require-instance" property (Section 9.9.3) is "true", the referred
> >>>> node MUST also represent configuration.
> >>>> 
> >>>> 
> >>>> 
> >>>> /martin
> >>> 
> >>> -- 
> >>> Ladislav Lhotka, CZ.NIC Labs
> >>> PGP Key ID: E74E8C0C
> > 
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> > 
> > 
> > 
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 


From nobody Mon May 30 03:30:40 2016
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 0470812D1CD for ; Mon, 30 May 2016 03:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.426
X-Spam-Level: 
X-Spam-Status: No, score=-8.426 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=-1.426] 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 RL0Ck4wpLSPP for ; Mon, 30 May 2016 03:30:36 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161EF12D1C1 for ; Mon, 30 May 2016 03:30:35 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:10b3:51b0:595a:8861] (unknown [IPv6:2001:718:1a02:1:10b3:51b0:595a:8861]) by mail.nic.cz (Postfix) with ESMTPSA id F1CFC6085C; Mon, 30 May 2016 12:30:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464604234; bh=8gcXCbLj+JI7SSbaW1XL8ITho78uhXl+DgVEYd4iaQc=; h=From:Date:To; b=mXwftOnkHkOX1q1wqOiNc8gx7tbwlNBf/eRi8XgJx/u/Pmx+Ebo5AIyfLB2hBaHyA uzZsXLmKPY+OcGyHdm0Y1N8Gj2GtfKbZ/mTtwGEjQd8AlKCBlTlUSDeoTJy5C4EO6d yvrOn644Vnlw6tUGNMnA/WUC4SBM5jOeUJ2MUXUI=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160530.121050.331732265291028598.mbj@tail-f.com>
Date: Mon, 30 May 2016 12:30:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <49595323-83BA-4196-A4D3-4D93CB981689@nic.cz>
References: <20160530.104924.2094113973837769652.mbj@tail-f.com>   <20160530.121050.331732265291028598.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] leafref value space and constraint
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 10:30:39 -0000

> On 30 May 2016, at 12:10, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 30 May 2016, at 10:58, Ladislav Lhotka  wrote:
>>>=20
>>>>=20
>>>> On 30 May 2016, at 10:49, Martin Bjorklund  wrote:
>>>>=20
>>>> Ladislav Lhotka  wrote:
>>>>> Martin Bjorklund  writes:
>>>>>=20
>>>>>> Juergen Schoenwaelder  =
wrote:
>>>>>>> On Tue, May 24, 2016 at 10:33:29AM +0200, Martin Bjorklund =
wrote:
>>>>>>>> Juergen Schoenwaelder  =
wrote:
>>>>>>>>> On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka =
wrote:
>>>>>>>>>=20
>>>>>>>>> [...]
>>>>>>>>>=20
>>>>>>>>>> This mixes up paths in the data tree with those in the schema =
tree. The XPath expression in the "path" statement is evaluated in the =
context of a data tree, but if the result is an empty node set, then =
"this leaf node" makes no sense.
>>>>>>>>>>=20
>>>>>>>>>> A specific example:
>>>>>>>>>>=20
>>>>>>>>>> leaf fooref {
>>>>>>>>>> type leafref {
>>>>>>>>>>  path "../foo";
>>>>>>>>>>  require-instance false;
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>=20
>>>>>>>>>> leaf foo {
>>>>>>>>>> type uint8;
>>>>>>>>>> when "../bar < 42";
>>>>>>>>>> }
>>>>>>>>>>=20
>>>>>>>>>> leaf bar {  =20
>>>>>>>>>> type uint8;
>>>>>>>>>> default 100;
>>>>>>>>>> }
>>>>>>>>>>=20
>>>>>>>>>> If there is neither "foo" nor "bar" in the data tree, what is =
the value space of "fooref"?
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Hm. Is it not both? The path refers to a schema node in order =
to
>>>>>>>>> determine the base type (which is the base value set if
>>>>>>>>> require-instance is false). If require-instance is true, then =
there is
>>>>>>>>> an additional constraint that refers to a set of data nodes =
that
>>>>>>>>> essentially determine a (possibly empty) subset of the value =
space.
>>>>>>>>>=20
>>>>>>>>> If you agree with this, then we essentially have to phrase =
this
>>>>>>>>> clearly.
>>>>>>>>=20
>>>>>>>> Exactly.  My proposal was:
>>>>>>>>=20
>>>>>>>> OLD:
>>>>>>>>=20
>>>>>>>> The leafref type is used to declare a constraint on the value =
space
>>>>>>>> of a leaf, based on a reference to a set of leaf instances in =
the
>>>>>>>> data tree.  The "path" substatement (Section 9.9.2) selects a =
set of
>>>>>>>> leaf instances, and the leafref value space is the set of =
values of
>>>>>>>> these leaf instances.
>>>>>>>>=20
>>>>>>>> If the leaf with the leafref type represents configuration =
data, and
>>>>>>>> the "require-instance" property (Section 9.9.3) is "true", the =
leaf
>>>>>>>> it refers to MUST also represent configuration.  Such a leaf =
puts a
>>>>>>>> constraint on valid data.  All such nodes MUST reference =
existing
>>>>>>>> leaf instances or leafs with default values in use (see Section =
7.6.1
>>>>>>>> and Section 7.7.2) for the data to be valid.  This constraint =
is
>>>>>>>> enforced according to the rules in Section 8.
>>>>>>>>=20
>>>>>>>> NEW:
>>>>>>>>=20
>>>>>>>> The leafref type is used to declare a constraint on the value =
space
>>>>>>>> of a leaf, based on a reference to a set of leaf instances in =
the
>>>>>>>> data tree.  The "path" substatement (Section 9.9.2) is used to =
refer
>>>>>>>> to another leaf node.  The leafref value space is the value =
space of
>>>>>>>> this leaf node.
>>>>>>>>=20
>>>>>>>> If the "require-instance" property is "true", there MUST exist =
an
>>>>>>>> instance, or a leaf with a default value in use (see Section =
7.6.1
>>>>>>>> and Section 7.7.2), of the leaf being referred to with the same =
value
>>>>>>>> as the leafref value in a valid data tree.
>>>>>>>>=20
>>>>>>>> If the leaf with the leafref type represents configuration =
data, and
>>>>>>>> the "require-instance" property (Section 9.9.3) is "true", the =
leaf
>>>>>>>> it refers to MUST also represent configuration.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Please comment and/or suggest improvements to this proposal.
>>>>>>>>=20
>>>>>>>=20
>>>>>>> I will give it a try. I think it is helpful to define referring =
node
>>>>>>> and referred node
>>>>>>=20
>>>>>> Ok.
>>>>>>=20
>>>>>>> and I think it is useful to first state the purpose
>>>>>>> of the leafref type.
>>>>>>>=20
>>>>>>> The leafref type is restricted to the value set of some leaf =
node in
>>>>>>> the schema tree and optionally further restricted by =
corresponding
>>>>>>> instance nodes in the data tree. More precisely, the leafref =
type
>>>>>>> declares a constraint on the value space of a leaf node (the
>>>>>>> referring leaf node), based on a reference to a another leaf =
node in
>>>>>>> the schema tree (the referred leaf node). The "path" =
substatement
>>>>>>> (Section 9.9.2) is used to identify the referred leaf node in =
the
>>>>>>> schema tree. The value set of the referring leaf node is the =
value
>>>>>>> set of the referred leaf node if the "require-instance" property =
is
>>>>>>> "false".
>>>>>>=20
>>>>>> Maybe remove the second sentence.  Also s/value set/value space/.
>>>>>> Also the last sentence isn't correct; the value space is always =
the
>>>>>> value space of the referred node.
>>>>>>=20
>>>>>>> If the "require-instance" property is "true", there MUST exist =
an node
>>>>>>> in the data tree, or a node with a default value in use (see =
Section
>>>>>>> 7.6.1 and Section 7.7.2), of the referred schema tree leaf node =
with
>>>>>>> the same value as the leafref value in a valid data tree.
>>>>>>>=20
>>>>>>> If the referring leaf node represents configuration data, and =
the
>>>>>>> "require-instance" property (Section 9.9.3) is "true", the =
referred
>>>>>>> leaf node MUST also represent configuration.
>>>>>>=20
>>>>>> Also, the text needs to mention leaf-lists.  This gives:
>>>>>>=20
>>>>>>=20
>>>>>> The leafref type is restricted to the value space of some leaf or
>>>>>> leaf-list node in the schema tree and optionally further =
restricted
>>>>>> by corresponding instance nodes in the data tree.  The "path"
>>>>>> substatement (Section 9.9.2) is used to identify the referred =
leaf
>>>>>> or leaf-list node in the schema tree. The value space of the
>>>>>> referring node is the value space of the referred node.
>>>>>=20
>>>>> The term "value space" is not defined in 6020bis, but IMO this is =
not correct.
>>>>> For example:
>>>>>=20
>>>>> leaf foo {
>>>>>  type uint8;
>>>>>  must ". mod 2 =3D 0";
>>>>> }
>>>>>=20
>>>>> Arguably, the value space of this leaf consists only of even
>>>>> numbers.
>>>>=20
>>>> No.  The value space is all of uint8.  In the candidate you can =
have
>>>> foo =3D 43.
>>>>=20
>>>> The "must" expression adds a constraint.
>>>=20
>>> Then a definition of "value space" needs to be added to the =
Terminology section. So far, this term has been used in 6020bis only in =
relation to a data type, not a leaf/leaf-list instance.
>>=20
>> Here is a suggestion:
>>=20
>> o value space: For a data type, it is the set of values permitted by
>>  the data type. For a leaf or leaf-list instance, it is the value
>>  space of its data type.
>=20
> Ok, but s/instance/node/.

Yes, right.

Lada

>=20
>=20
> /martin
>=20
>=20
>=20
>>=20
>> Lada
>>=20
>>>=20
>>> Lada=20
>>>=20
>>>>=20
>>>>> If
>>>>> "bar" is a leafref that refers to "foo", what is its value space? =
My
>>>>> understanding is that it is the whole uint8 range, i.e. the value =
space
>>>>> of the *type* of "foo".
>>>>=20
>>>> Yes.
>>>>=20
>>>>=20
>>>> /martin
>>>>=20
>>>>=20
>>>>=20
>>>>>=20
>>>>> Lada
>>>>>=20
>>>>>>=20
>>>>>> If the "require-instance" property is "true", there MUST exist an
>>>>>> node in the data tree, or a node with a default value in use (see
>>>>>> Section 7.6.1 and Section 7.7.2), of the referred schema tree =
leaf
>>>>>> or leaf-list node with the same value as the leafref value in a
>>>>>> valid data tree.
>>>>>>=20
>>>>>> If the referring node represents configuration data, and the
>>>>>> "require-instance" property (Section 9.9.3) is "true", the =
referred
>>>>>> node MUST also represent configuration.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> /martin
>>>>>=20
>>>>> --=20
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=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: E74E8C0C

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





From nobody Mon May 30 05:51:14 2016
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 C883512D52F for ; Mon, 30 May 2016 05:51:12 -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 gPhHAPtpqUZg for ; Mon, 30 May 2016 05:51:10 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AF90612D527 for ; Mon, 30 May 2016 05:51:09 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 4F9271CC028D; Mon, 30 May 2016 14:51:14 +0200 (CEST)
From: Ladislav Lhotka 
To: "Yingzhen Qu \(yiqu\)" , "Acee Lindem \(acee\)" , netmod@ietf.org
In-Reply-To: 
References:      
User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 30 May 2016 14:51:21 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] "A YANG Data Model for Routing Management" Modifications
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 12:51:13 -0000

"Yingzhen Qu (yiqu)"  writes:

> Hi Lada,
>
> The =C2=B3multi-next-hop=C2=B2 is using the combination of interface and =
address as
> the list key. I know key can=C2=B9t be empty, but for next hop it=C2=B9s =
possible
> that only either interface or address is used. I=C2=B9ve been trying to f=
igure
> out a better way to present this, any suggestion?

Optional list keys were proposed for YANG 1.1:

https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-10

The reason that the issue Y09 was eventually rejected was that many
people thought it was a relatively far-reaching change. This means we
are left with the same options as in YANG 1.0, none of them being very
pretty:

- Add a dummy opaque key, e.g.

  list next-hop-entries {
    key id;
    leaf id {
      type uint16;
    }
    unique interface address;
    ...
  }

- Use special value, such as empty string, to indicate that either
  interface or address isn't present. But since inet:ipv[46]-address
  cannot be empty, we would need to define the type of "address" as a
  union of empty string and inet:ipv[46]-address.

Lada

>
> If there is anything I can help with the modification, please let me know.
>
> Thanks,
> Yingzhen
>
> On 5/27/16, 4:14 AM, "Acee Lindem (acee)"  wrote:
>
>>Hi Lada,=20
>>
>>On 5/27/16, 5:42 AM, "Ladislav Lhotka"  wrote:
>>
>>>Hi Acee,
>>>
>>>I have a couple of questions:
>>>
>>>1. I changed "routing-protocol" -> "control-plane-protocol" (this is
>>>   already in GitHub). As for identities, I introduced a new base
>>>   identity "control-plane-protocol", and derived "routing-protocol"
>>>   from it. So the idea is that routing protocols will still use
>>>   "routing-protocol" as their base. Is it OK?
>>
>>Yes - as long as there is a single list. I=C2=B9ll pull the source today.
>>
>>>
>>>2. We could define identities for route types but I am still not
>>>   convinced that route-type should be added to ietf-routing because
>>>   then we can't limit the set of types for each protocol, so that, for
>>>   example, OSPF routes could carry IS-IS Level [12] routes.
>>
>>Do you mean that OSPF would install the wrong type of route? I would see
>>this as a bug but not something the model itself should enforce.
>>
>>Note that OSPF can =C2=B3carry=C2=B2 any type of route if it is imported =
into OSPF
>>and advertised as an AS External route.
>>
>>>
>>>3. The "multi-next-hop" case in rib-extend-01 uses interface and address
>>>   as keys. This means that for every next-hop *both* parameters have to
>>>   be given. Is it really intended?
>>
>>No - either or both must be specified but both are not required. I=C2=B9ll
>>leave this to you YANG experts.
>>
>>Thanks,
>>Acee
>>
>>
>>
>>>
>>>Thanks, Lada
>>>
>>>"Acee Lindem (acee)"  writes:
>>>
>>>> Hi Lada,=20
>>>>
>>>>
>>>> On 5/23/16, 8:30 AM, "Ladislav Lhotka"  wrote:
>>>>
>>>>>"Acee Lindem (acee)"  writes:
>>>>>
>>>>>> Hi Lada,=20
>>>>>>
>>>>>> I thought I go through the impetus for the changes I discussed in my
>>>>>>last
>>>>>> E-mail. I believe we should make these changes and then freeze the
>>>>>> specification other than possible modifications based on the
>>>>>>consensus
>>>>>>for
>>>>>> the NETMOD operational state direction.
>>>>>
>>>>>I agree.
>>>>>
>>>>>>
>>>>>> The request to merge draft
>>>>>> https://www.ietf.org/id/draft-acee-rtgwg-yang-rib-extend-01.txt is
>>>>>>based
>>>>>> on the comments we received in the RTG WG meeting at IETF 95. The
>>>>>> consensus in the room was that the proposed next-hop additions were
>>>>>>pretty
>>>>>> standard in a networking device supporting routing. We were careful
>>>>>>not
>>>>>>to
>>>>>> include any MPLS or other tunneling technologies. If you feel that
>>>>>>some
>>>>>>of
>>>>>> these are not applicable to hosts, we could make them features.
>>>>>
>>>>>I don't think that many home routers support these features either
>>>>>(except ECMP). I still think they should be added as augments, and, as
>>>>>you know, ietf-routing was previously modified to enable it. Another
>>>>>advantage of doing so is that it will be more future-proof: it will be
>>>>>easier to replace their definitions with something else, which may be
>>>>>impossible if they are an integral part of ietf-routing, because of the
>>>>>rigid rules for updating published YANG modules.
>>>>
>>>> Lou and I had a lengthy discussion on this and we agreed that the base
>>>> should support ECMP and a metric per-path (like Linux).
>>>>
>>>> I also think we could route-type and tag to the operational state as
>>>>long
>>>> as they have default value of =C2=B3unspecified=C2=B2 and =C2=B3none=
=C2=B2 respectively.
>>>>This
>>>> would address the E-mail Helen Chen sent to NETMOD today.
>>>>
>>>> As for configuration of the tag and the backup path, we can keep these
>>>>as
>>>> augmentations.=20
>>>>
>>>>>
>>>>>>
>>>>>> The request to change the name of routing-protocols to
>>>>>> control-plane-protocols is in support of
>>>>>> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-04.txt.
>>>>>>This
>>>>>> informative model was always had a control-plane-protocols list. If
>>>>>>we
>>>>>> don=C2=B9t put a standards-based control-plane-protocols list here, =
we
>>>>>>will
>>>>>> need to have one list for routing-protocols (i.e., RIB clients) and
>>>>>> another list for non-RIB clients. While the name is somewhat more
>>>>>>general
>>>>>> than the scope of routing-cfg, it seems like a very good trade-off to
>>>>>>put
>>>>>> it here rather than have two lists and have to move protocols between
>>>>>> lists if they suddenly add a capability that allows the protocol to
>>>>>>modify
>>>>>> the RIB.
>>>>>
>>>>>I don't mind changing the name, but I was a bit concerned that this may
>>>>>induce other changes, e.g. in the definition of RIBs. Lou already told
>>>>>me it was not the case, so we can change the name.
>>>>
>>>>
>>>> Great.=20
>>>>
>>>> Thanks,
>>>> Acee=20
>>>>
>>>>
>>>>>
>>>>>Lada
>>>>>
>>>>>>
>>>>>> If you are amenable to these modifications, we can confirm them on
>>>>>>the
>>>>>> NETMOD list.=20
>>>>>>
>>>>>> Thanks,
>>>>>> Acee=20
>>>>>>
>>>>>
>>>>>--=20
>>>>>Ladislav Lhotka, CZ.NIC Labs
>>>>>PGP Key ID: E74E8C0C
>>>>
>>>
>>>--=20
>>>Ladislav Lhotka, CZ.NIC Labs
>>>PGP Key ID: E74E8C0C
>>
>

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue May 31 13:29:23 2016
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 EA69012D7F4 for ; Tue, 31 May 2016 13:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level: 
X-Spam-Status: No, score=-15.947 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=-1.426, 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 7SNj9cMps-dY for ; Tue, 31 May 2016 13:29:19 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFBE12D652 for ; Tue, 31 May 2016 13:29:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9804; q=dns/txt; s=iport; t=1464726559; x=1465936159; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YMvhYgb3h93JadILE7WcYRoaeUrJwVnMOXZTmunLTi8=; b=ae3ovw82Ce22wvsn2dAabc0moxElTV8X+LKX4BIS//UOzklru/7ab0rk skGVm8FevDd9iw8sq0EH1EGBSzkA6wcPnlWyjXmKPMz8XQIA4OD2KENie sCgo/1vB4ztmCtyjQcWNte8JHPxpMxMMNJ+374W9pjQgWO8yGvijVr4V4 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgAT801X/4QNJK1SCYM9Vn0Ggz20P?= =?us-ascii?q?IIPAQ2BeiKFbwIcgSM4FAEBAQEBAQFlJ4RGAQEEIwQNNx4CAQgYAgImAgICMBU?= =?us-ascii?q?QAgQBEogvDq13kScBAQEBAQEBAQEBAQEBAQEBAQEBGQWBAYhwgQOBSmeBWBAEI?= =?us-ascii?q?4MJglkFiA6FV4EyiSABhX+IIIFphE+IZI9LAR4BAUKDbW4BAQGIcUV/AQEB?=
X-IronPort-AV: E=Sophos;i="5.26,397,1459814400"; d="scan'208";a="110102403"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 May 2016 20:29:18 +0000
Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4VKTIPM032115 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 May 2016 20:29:18 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 31 May 2016 16:29:17 -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.1104.009; Tue, 31 May 2016 16:29:16 -0400
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , "Yingzhen Qu (yiqu)" , "netmod@ietf.org" 
Thread-Topic: "A YANG Data Model for Routing Management" Modifications
Thread-Index: AQHRtO7r+C2S73ZgJUC44PCbE4kSTw==
Date: Tue, 31 May 2016 20:29:16 +0000
Message-ID: 
References:       
In-Reply-To: 
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] "A YANG Data Model for Routing Management" Modifications
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 20:29:22 -0000

SGkgTGFkYSwgDQpJZiB3ZSBjYW7igJl0IGdldCBZQU5HIHRvIGRvIHdoYXQgd2UgbmVlZCwgY2Fu
IHdlIGp1c3Qgc3VwcG9ydCBhIGNob2ljZSB3aXRoDQphIHNwZWNpYWwgdmFsdWUgb2Yg4oCcdW5z
cGVjaWZpZWTigJ0gZm9yIHRoZSBpbnRlcmZhY2UgYW5kIGFkZHJlc3M/DQpBZGRpdGlvbmFsbHks
IHdl4oCZZCBuZWVkIGEgY29uc3RyYWludCB0aGF0IGVuZm9yY2VzIHRoZSBmYWN0IHRoYXQgYm90
aA0KaW50ZXJmYWNlIGFuZCBhZGRyZXNzIGNhbm5vdCBiZSDigJx1bnNwZWNpZmllZOKAnS4NCg0K
VGhhbmtzLA0KQWNlZSANCg0KT24gNS8zMC8xNiwgODo1MSBBTSwgIkxhZGlzbGF2IExob3RrYSIg
PGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KDQo+Illpbmd6aGVuIFF1ICh5aXF1KSIgPHlpcXVAY2lz
Y28uY29tPiB3cml0ZXM6DQo+DQo+PiBIaSBMYWRhLA0KPj4NCj4+IFRoZSDCs211bHRpLW5leHQt
aG9wwrIgaXMgdXNpbmcgdGhlIGNvbWJpbmF0aW9uIG9mIGludGVyZmFjZSBhbmQgYWRkcmVzcw0K
Pj5hcw0KPj4gdGhlIGxpc3Qga2V5LiBJIGtub3cga2V5IGNhbsK5dCBiZSBlbXB0eSwgYnV0IGZv
ciBuZXh0IGhvcCBpdMK5cyBwb3NzaWJsZQ0KPj4gdGhhdCBvbmx5IGVpdGhlciBpbnRlcmZhY2Ug
b3IgYWRkcmVzcyBpcyB1c2VkLiBJwrl2ZSBiZWVuIHRyeWluZyB0bw0KPj5maWd1cmUNCj4+IG91
dCBhIGJldHRlciB3YXkgdG8gcHJlc2VudCB0aGlzLCBhbnkgc3VnZ2VzdGlvbj8NCj4NCj5PcHRp
b25hbCBsaXN0IGtleXMgd2VyZSBwcm9wb3NlZCBmb3IgWUFORyAxLjE6DQo+DQo+aHR0cHM6Ly9z
dm4udG9vbHMuaWV0Zi5vcmcvc3ZuL3dnL25ldG1vZC95YW5nLTEuMS9pc3N1ZXMuaHRtbCNzZWMt
MTANCj4NCj5UaGUgcmVhc29uIHRoYXQgdGhlIGlzc3VlIFkwOSB3YXMgZXZlbnR1YWxseSByZWpl
Y3RlZCB3YXMgdGhhdCBtYW55DQo+cGVvcGxlIHRob3VnaHQgaXQgd2FzIGEgcmVsYXRpdmVseSBm
YXItcmVhY2hpbmcgY2hhbmdlLiBUaGlzIG1lYW5zIHdlDQo+YXJlIGxlZnQgd2l0aCB0aGUgc2Ft
ZSBvcHRpb25zIGFzIGluIFlBTkcgMS4wLCBub25lIG9mIHRoZW0gYmVpbmcgdmVyeQ0KPnByZXR0
eToNCj4NCj4tIEFkZCBhIGR1bW15IG9wYXF1ZSBrZXksIGUuZy4NCj4NCj4gIGxpc3QgbmV4dC1o
b3AtZW50cmllcyB7DQo+ICAgIGtleSBpZDsNCj4gICAgbGVhZiBpZCB7DQo+ICAgICAgdHlwZSB1
aW50MTY7DQo+ICAgIH0NCj4gICAgdW5pcXVlIGludGVyZmFjZSBhZGRyZXNzOw0KPiAgICAuLi4N
Cj4gIH0NCj4NCj4tIFVzZSBzcGVjaWFsIHZhbHVlLCBzdWNoIGFzIGVtcHR5IHN0cmluZywgdG8g
aW5kaWNhdGUgdGhhdCBlaXRoZXINCj4gIGludGVyZmFjZSBvciBhZGRyZXNzIGlzbid0IHByZXNl
bnQuIEJ1dCBzaW5jZSBpbmV0Omlwdls0Nl0tYWRkcmVzcw0KPiAgY2Fubm90IGJlIGVtcHR5LCB3
ZSB3b3VsZCBuZWVkIHRvIGRlZmluZSB0aGUgdHlwZSBvZiAiYWRkcmVzcyIgYXMgYQ0KPiAgdW5p
b24gb2YgZW1wdHkgc3RyaW5nIGFuZCBpbmV0Omlwdls0Nl0tYWRkcmVzcy4NCj4NCj5MYWRhDQo+
DQo+Pg0KPj4gSWYgdGhlcmUgaXMgYW55dGhpbmcgSSBjYW4gaGVscCB3aXRoIHRoZSBtb2RpZmlj
YXRpb24sIHBsZWFzZSBsZXQgbWUNCj4+a25vdy4NCj4+DQo+PiBUaGFua3MsDQo+PiBZaW5nemhl
bg0KPj4NCj4+IE9uIDUvMjcvMTYsIDQ6MTQgQU0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2Vl
QGNpc2NvLmNvbT4gd3JvdGU6DQo+Pg0KPj4+SGkgTGFkYSwgDQo+Pj4NCj4+Pk9uIDUvMjcvMTYs
IDU6NDIgQU0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+Pg0K
Pj4+PkhpIEFjZWUsDQo+Pj4+DQo+Pj4+SSBoYXZlIGEgY291cGxlIG9mIHF1ZXN0aW9uczoNCj4+
Pj4NCj4+Pj4xLiBJIGNoYW5nZWQgInJvdXRpbmctcHJvdG9jb2wiIC0+ICJjb250cm9sLXBsYW5l
LXByb3RvY29sIiAodGhpcyBpcw0KPj4+PiAgIGFscmVhZHkgaW4gR2l0SHViKS4gQXMgZm9yIGlk
ZW50aXRpZXMsIEkgaW50cm9kdWNlZCBhIG5ldyBiYXNlDQo+Pj4+ICAgaWRlbnRpdHkgImNvbnRy
b2wtcGxhbmUtcHJvdG9jb2wiLCBhbmQgZGVyaXZlZCAicm91dGluZy1wcm90b2NvbCINCj4+Pj4g
ICBmcm9tIGl0LiBTbyB0aGUgaWRlYSBpcyB0aGF0IHJvdXRpbmcgcHJvdG9jb2xzIHdpbGwgc3Rp
bGwgdXNlDQo+Pj4+ICAgInJvdXRpbmctcHJvdG9jb2wiIGFzIHRoZWlyIGJhc2UuIElzIGl0IE9L
Pw0KPj4+DQo+Pj5ZZXMgLSBhcyBsb25nIGFzIHRoZXJlIGlzIGEgc2luZ2xlIGxpc3QuIEnCuWxs
IHB1bGwgdGhlIHNvdXJjZSB0b2RheS4NCj4+Pg0KPj4+Pg0KPj4+PjIuIFdlIGNvdWxkIGRlZmlu
ZSBpZGVudGl0aWVzIGZvciByb3V0ZSB0eXBlcyBidXQgSSBhbSBzdGlsbCBub3QNCj4+Pj4gICBj
b252aW5jZWQgdGhhdCByb3V0ZS10eXBlIHNob3VsZCBiZSBhZGRlZCB0byBpZXRmLXJvdXRpbmcg
YmVjYXVzZQ0KPj4+PiAgIHRoZW4gd2UgY2FuJ3QgbGltaXQgdGhlIHNldCBvZiB0eXBlcyBmb3Ig
ZWFjaCBwcm90b2NvbCwgc28gdGhhdCwgZm9yDQo+Pj4+ICAgZXhhbXBsZSwgT1NQRiByb3V0ZXMg
Y291bGQgY2FycnkgSVMtSVMgTGV2ZWwgWzEyXSByb3V0ZXMuDQo+Pj4NCj4+PkRvIHlvdSBtZWFu
IHRoYXQgT1NQRiB3b3VsZCBpbnN0YWxsIHRoZSB3cm9uZyB0eXBlIG9mIHJvdXRlPyBJIHdvdWxk
IHNlZQ0KPj4+dGhpcyBhcyBhIGJ1ZyBidXQgbm90IHNvbWV0aGluZyB0aGUgbW9kZWwgaXRzZWxm
IHNob3VsZCBlbmZvcmNlLg0KPj4+DQo+Pj5Ob3RlIHRoYXQgT1NQRiBjYW4gwrNjYXJyecKyIGFu
eSB0eXBlIG9mIHJvdXRlIGlmIGl0IGlzIGltcG9ydGVkIGludG8gT1NQRg0KPj4+YW5kIGFkdmVy
dGlzZWQgYXMgYW4gQVMgRXh0ZXJuYWwgcm91dGUuDQo+Pj4NCj4+Pj4NCj4+Pj4zLiBUaGUgIm11
bHRpLW5leHQtaG9wIiBjYXNlIGluIHJpYi1leHRlbmQtMDEgdXNlcyBpbnRlcmZhY2UgYW5kDQo+
Pj4+YWRkcmVzcw0KPj4+PiAgIGFzIGtleXMuIFRoaXMgbWVhbnMgdGhhdCBmb3IgZXZlcnkgbmV4
dC1ob3AgKmJvdGgqIHBhcmFtZXRlcnMgaGF2ZQ0KPj4+PnRvDQo+Pj4+ICAgYmUgZ2l2ZW4uIElz
IGl0IHJlYWxseSBpbnRlbmRlZD8NCj4+Pg0KPj4+Tm8gLSBlaXRoZXIgb3IgYm90aCBtdXN0IGJl
IHNwZWNpZmllZCBidXQgYm90aCBhcmUgbm90IHJlcXVpcmVkLiBJwrlsbA0KPj4+bGVhdmUgdGhp
cyB0byB5b3UgWUFORyBleHBlcnRzLg0KPj4+DQo+Pj5UaGFua3MsDQo+Pj5BY2VlDQo+Pj4NCj4+
Pg0KPj4+DQo+Pj4+DQo+Pj4+VGhhbmtzLCBMYWRhDQo+Pj4+DQo+Pj4+IkFjZWUgTGluZGVtIChh
Y2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cml0ZXM6DQo+Pj4+DQo+Pj4+PiBIaSBMYWRhLCANCj4+
Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24gNS8yMy8xNiwgODozMCBBTSwgIkxhZGlzbGF2IExob3RrYSIg
PGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PiJBY2VlIExpbmRlbSAoYWNlZSki
IDxhY2VlQGNpc2NvLmNvbT4gd3JpdGVzOg0KPj4+Pj4+DQo+Pj4+Pj4+IEhpIExhZGEsIA0KPj4+
Pj4+Pg0KPj4+Pj4+PiBJIHRob3VnaHQgSSBnbyB0aHJvdWdoIHRoZSBpbXBldHVzIGZvciB0aGUg
Y2hhbmdlcyBJIGRpc2N1c3NlZCBpbg0KPj4+Pj4+Pm15DQo+Pj4+Pj4+bGFzdA0KPj4+Pj4+PiBF
LW1haWwuIEkgYmVsaWV2ZSB3ZSBzaG91bGQgbWFrZSB0aGVzZSBjaGFuZ2VzIGFuZCB0aGVuIGZy
ZWV6ZSB0aGUNCj4+Pj4+Pj4gc3BlY2lmaWNhdGlvbiBvdGhlciB0aGFuIHBvc3NpYmxlIG1vZGlm
aWNhdGlvbnMgYmFzZWQgb24gdGhlDQo+Pj4+Pj4+Y29uc2Vuc3VzDQo+Pj4+Pj4+Zm9yDQo+Pj4+
Pj4+IHRoZSBORVRNT0Qgb3BlcmF0aW9uYWwgc3RhdGUgZGlyZWN0aW9uLg0KPj4+Pj4+DQo+Pj4+
Pj5JIGFncmVlLg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoZSByZXF1ZXN0IHRvIG1lcmdl
IGRyYWZ0DQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWFjZWUtcnRnd2ct
eWFuZy1yaWItZXh0ZW5kLTAxLnR4dCBpcw0KPj4+Pj4+PmJhc2VkDQo+Pj4+Pj4+IG9uIHRoZSBj
b21tZW50cyB3ZSByZWNlaXZlZCBpbiB0aGUgUlRHIFdHIG1lZXRpbmcgYXQgSUVURiA5NS4gVGhl
DQo+Pj4+Pj4+IGNvbnNlbnN1cyBpbiB0aGUgcm9vbSB3YXMgdGhhdCB0aGUgcHJvcG9zZWQgbmV4
dC1ob3AgYWRkaXRpb25zIHdlcmUNCj4+Pj4+Pj5wcmV0dHkNCj4+Pj4+Pj4gc3RhbmRhcmQgaW4g
YSBuZXR3b3JraW5nIGRldmljZSBzdXBwb3J0aW5nIHJvdXRpbmcuIFdlIHdlcmUgY2FyZWZ1bA0K
Pj4+Pj4+Pm5vdA0KPj4+Pj4+PnRvDQo+Pj4+Pj4+IGluY2x1ZGUgYW55IE1QTFMgb3Igb3RoZXIg
dHVubmVsaW5nIHRlY2hub2xvZ2llcy4gSWYgeW91IGZlZWwgdGhhdA0KPj4+Pj4+PnNvbWUNCj4+
Pj4+Pj5vZg0KPj4+Pj4+PiB0aGVzZSBhcmUgbm90IGFwcGxpY2FibGUgdG8gaG9zdHMsIHdlIGNv
dWxkIG1ha2UgdGhlbSBmZWF0dXJlcy4NCj4+Pj4+Pg0KPj4+Pj4+SSBkb24ndCB0aGluayB0aGF0
IG1hbnkgaG9tZSByb3V0ZXJzIHN1cHBvcnQgdGhlc2UgZmVhdHVyZXMgZWl0aGVyDQo+Pj4+Pj4o
ZXhjZXB0IEVDTVApLiBJIHN0aWxsIHRoaW5rIHRoZXkgc2hvdWxkIGJlIGFkZGVkIGFzIGF1Z21l
bnRzLCBhbmQsDQo+Pj4+Pj5hcw0KPj4+Pj4+eW91IGtub3csIGlldGYtcm91dGluZyB3YXMgcHJl
dmlvdXNseSBtb2RpZmllZCB0byBlbmFibGUgaXQuIEFub3RoZXINCj4+Pj4+PmFkdmFudGFnZSBv
ZiBkb2luZyBzbyBpcyB0aGF0IGl0IHdpbGwgYmUgbW9yZSBmdXR1cmUtcHJvb2Y6IGl0IHdpbGwN
Cj4+Pj4+PmJlDQo+Pj4+Pj5lYXNpZXIgdG8gcmVwbGFjZSB0aGVpciBkZWZpbml0aW9ucyB3aXRo
IHNvbWV0aGluZyBlbHNlLCB3aGljaCBtYXkgYmUNCj4+Pj4+PmltcG9zc2libGUgaWYgdGhleSBh
cmUgYW4gaW50ZWdyYWwgcGFydCBvZiBpZXRmLXJvdXRpbmcsIGJlY2F1c2Ugb2YNCj4+Pj4+PnRo
ZQ0KPj4+Pj4+cmlnaWQgcnVsZXMgZm9yIHVwZGF0aW5nIHB1Ymxpc2hlZCBZQU5HIG1vZHVsZXMu
DQo+Pj4+Pg0KPj4+Pj4gTG91IGFuZCBJIGhhZCBhIGxlbmd0aHkgZGlzY3Vzc2lvbiBvbiB0aGlz
IGFuZCB3ZSBhZ3JlZWQgdGhhdCB0aGUNCj4+Pj4+YmFzZQ0KPj4+Pj4gc2hvdWxkIHN1cHBvcnQg
RUNNUCBhbmQgYSBtZXRyaWMgcGVyLXBhdGggKGxpa2UgTGludXgpLg0KPj4+Pj4NCj4+Pj4+IEkg
YWxzbyB0aGluayB3ZSBjb3VsZCByb3V0ZS10eXBlIGFuZCB0YWcgdG8gdGhlIG9wZXJhdGlvbmFs
IHN0YXRlIGFzDQo+Pj4+PmxvbmcNCj4+Pj4+IGFzIHRoZXkgaGF2ZSBkZWZhdWx0IHZhbHVlIG9m
IMKzdW5zcGVjaWZpZWTCsiBhbmQgwrNub25lwrIgcmVzcGVjdGl2ZWx5Lg0KPj4+Pj5UaGlzDQo+
Pj4+PiB3b3VsZCBhZGRyZXNzIHRoZSBFLW1haWwgSGVsZW4gQ2hlbiBzZW50IHRvIE5FVE1PRCB0
b2RheS4NCj4+Pj4+DQo+Pj4+PiBBcyBmb3IgY29uZmlndXJhdGlvbiBvZiB0aGUgdGFnIGFuZCB0
aGUgYmFja3VwIHBhdGgsIHdlIGNhbiBrZWVwDQo+Pj4+PnRoZXNlDQo+Pj4+PmFzDQo+Pj4+PiBh
dWdtZW50YXRpb25zLg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGUgcmVxdWVz
dCB0byBjaGFuZ2UgdGhlIG5hbWUgb2Ygcm91dGluZy1wcm90b2NvbHMgdG8NCj4+Pj4+Pj4gY29u
dHJvbC1wbGFuZS1wcm90b2NvbHMgaXMgaW4gc3VwcG9ydCBvZg0KPj4+Pj4+PiBodHRwczovL3d3
dy5pZXRmLm9yZy9pZC9kcmFmdC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNlLW1vZGVsLTA0LnR4dC4N
Cj4+Pj4+Pj5UaGlzDQo+Pj4+Pj4+IGluZm9ybWF0aXZlIG1vZGVsIHdhcyBhbHdheXMgaGFkIGEg
Y29udHJvbC1wbGFuZS1wcm90b2NvbHMgbGlzdC4gSWYNCj4+Pj4+Pj53ZQ0KPj4+Pj4+PiBkb27C
uXQgcHV0IGEgc3RhbmRhcmRzLWJhc2VkIGNvbnRyb2wtcGxhbmUtcHJvdG9jb2xzIGxpc3QgaGVy
ZSwgd2UNCj4+Pj4+Pj53aWxsDQo+Pj4+Pj4+IG5lZWQgdG8gaGF2ZSBvbmUgbGlzdCBmb3Igcm91
dGluZy1wcm90b2NvbHMgKGkuZS4sIFJJQiBjbGllbnRzKSBhbmQNCj4+Pj4+Pj4gYW5vdGhlciBs
aXN0IGZvciBub24tUklCIGNsaWVudHMuIFdoaWxlIHRoZSBuYW1lIGlzIHNvbWV3aGF0IG1vcmUN
Cj4+Pj4+Pj5nZW5lcmFsDQo+Pj4+Pj4+IHRoYW4gdGhlIHNjb3BlIG9mIHJvdXRpbmctY2ZnLCBp
dCBzZWVtcyBsaWtlIGEgdmVyeSBnb29kIHRyYWRlLW9mZg0KPj4+Pj4+PnRvDQo+Pj4+Pj4+cHV0
DQo+Pj4+Pj4+IGl0IGhlcmUgcmF0aGVyIHRoYW4gaGF2ZSB0d28gbGlzdHMgYW5kIGhhdmUgdG8g
bW92ZSBwcm90b2NvbHMNCj4+Pj4+Pj5iZXR3ZWVuDQo+Pj4+Pj4+IGxpc3RzIGlmIHRoZXkgc3Vk
ZGVubHkgYWRkIGEgY2FwYWJpbGl0eSB0aGF0IGFsbG93cyB0aGUgcHJvdG9jb2wgdG8NCj4+Pj4+
Pj5tb2RpZnkNCj4+Pj4+Pj4gdGhlIFJJQi4NCj4+Pj4+Pg0KPj4+Pj4+SSBkb24ndCBtaW5kIGNo
YW5naW5nIHRoZSBuYW1lLCBidXQgSSB3YXMgYSBiaXQgY29uY2VybmVkIHRoYXQgdGhpcw0KPj4+
Pj4+bWF5DQo+Pj4+Pj5pbmR1Y2Ugb3RoZXIgY2hhbmdlcywgZS5nLiBpbiB0aGUgZGVmaW5pdGlv
biBvZiBSSUJzLiBMb3UgYWxyZWFkeQ0KPj4+Pj4+dG9sZA0KPj4+Pj4+bWUgaXQgd2FzIG5vdCB0
aGUgY2FzZSwgc28gd2UgY2FuIGNoYW5nZSB0aGUgbmFtZS4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4g
R3JlYXQuIA0KPj4+Pj4NCj4+Pj4+IFRoYW5rcywNCj4+Pj4+IEFjZWUgDQo+Pj4+Pg0KPj4+Pj4N
Cj4+Pj4+Pg0KPj4+Pj4+TGFkYQ0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IElmIHlvdSBhcmUg
YW1lbmFibGUgdG8gdGhlc2UgbW9kaWZpY2F0aW9ucywgd2UgY2FuIGNvbmZpcm0gdGhlbSBvbg0K
Pj4+Pj4+PnRoZQ0KPj4+Pj4+PiBORVRNT0QgbGlzdC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhhbmtz
LA0KPj4+Pj4+PiBBY2VlIA0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4tLSANCj4+Pj4+PkxhZGlz
bGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+Pj4+PlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+Pj4+
Pg0KPj4+Pg0KPj4+Pi0tIA0KPj4+PkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+Pj5Q
R1AgS2V5IElEOiBFNzRFOEMwQw0KPj4+DQo+Pg0KPg0KPi0tIA0KPkxhZGlzbGF2IExob3RrYSwg
Q1ouTklDIExhYnMNCj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KDQo=


From nobody Tue May 31 13:54:06 2016
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 CA51012D8E1 for ; Tue, 31 May 2016 13:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level: 
X-Spam-Status: No, score=-15.947 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=-1.426, 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 uW5xeavXoHq5 for ; Tue, 31 May 2016 13:54:02 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B2A12D8DF for ; Tue, 31 May 2016 13:54:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12108; q=dns/txt; s=iport; t=1464728042; x=1465937642; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Wrqjd27UE+VJrHB60eQzqtERLZ6/XQPqpk55BaFCzZc=; b=DH1/94MhM5poZ1LZ3yr72imhAvEyGtE+VJl0ElE6hefC6vf0AQ98z5z/ Loseu6p0nSrLxcDVP5pSagrHwLfpBT5SNy9bNNT3X/MmXEQ6EispcHPwP 8+M8kcJiJwnudr4AEUAISWjVK80vXg9ePHczWVnJJCfvCgJycD+TvVxRi Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgC8+U1X/4kNJK1bgz1WfQa6CAENg?= =?us-ascii?q?XoXBoJCgmhKAhyBIzgUAQEBAQEBAWUnhEUBAQECAgEBASAROhcEAgEIEQQBAQE?= =?us-ascii?q?CAiMDAgICJQsUAQgIAgQBEogvDq1wkS0BAQEBAQEBAQEBAQEBAQEBAQEBAQEcg?= =?us-ascii?q?QGFJoF3glaEEgsGAQYtgnIrgi4FjWWKUgGFf4J4hSiBaU6EAYhkhjOJGAEeAQF?= =?us-ascii?q?CggMDHIFLbgEBiHIPFx8BfgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.26,397,1459814400"; d="scan'208";a="280091782"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 May 2016 20:54:00 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4VKs0VZ001210 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 May 2016 20:54:00 GMT
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 31 May 2016 15:53:59 -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.1104.009; Tue, 31 May 2016 15:53:59 -0500
From: "Clyde Wildes (cwildes)" 
To: "Sterne, Jason (Nokia - CA)" , "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt
Thread-Index: AQHRqwEIoPXkjp2l/k2OqqhnpwdmNZ+yjKoAgBqvymCABkkegA==
Date: Tue, 31 May 2016 20:53:59 +0000
Message-ID: <2DC04BC2-4A02-49CF-AD39-6AFE13F09A0E@cisco.com>
References: <20160510211427.390.80951.idtracker@ietfa.amsl.com> <3BC3991A-615F-47CE-A567-721C8272404E@cisco.com> 
In-Reply-To: 
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: [128.107.151.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <971B4BB9B7BA3944A61114C22EB58BA0@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 20:54:05 -0000

SmFzb24sDQoNCldpdGggcmVnYXJkcyB0byBhZGRpbmcgbG9nLWlucHV0LXRyYW5zcG9ydHM6IHBs
ZWFzZSBzZWUgUkZDIDU0MjQg4oCTIFRoZSBTeXNsb2cgUHJvdG9jb2wsIHNlY3Rpb25zIDMgYW5k
IDQgd2hlcmUgcmVsYXkgYW5kIGNvbGxlY3RvciBmdW5jdGlvbnMgYXJlIGRpc2N1c3NlZC4gSW4g
b3JkZXIgdG8gc3VwcG9ydCB0aGUgcmVsYXkgYW5kL29yIGNvbGxlY3RvciBmdW5jdGlvbiwgbG9n
LWlucHV0LXRyYW5zcG9ydHMgaXMgcmVxdWlyZWQgYW5kIEkgYmVsaWV2ZSBpdCBpcyBiZXN0IHRv
IHN1cHBvcnQgdGhlIGVudGlyZSBSRkMgNTQyNCBwcm90b2NvbC4NCg0KSSBwcm9kdWNlZCB0aGUg
Zm9sbG93aW5nIHRhYmxlIHRvIGhlbHAgd2l0aCB0aGUgYW5hbHlzaXMgb2Ygd2hhdCBmZWF0dXJl
cyBtaWdodCBiZSBpbmNsdWRlZC4gUGxlYXNlIHByb3ZpZGUgdXBkYXRlcyB0byB0aGUgdGFibGUg
dG8gaGVscCB3aXRoIHRoZSBhbmFseXNpcy4NCg0KICAgICAgICBGZWF0dXJlICAgICAgICAgICAg
IEFsY2F0ZWwgIEJyb2NhZGUgIENpZW5hICBDaXNjbyBJT1MvWEUgIENpc2NvIElPUy9YUiAgQ2lz
Y28gTlhPUyAgSnVuaXBlciBKdW5PUyAgTGludXggUnN5c2xvZyAgQ29tbWVudHMNCmxvZy1pbnB1
dC10cmFuc3BvcnRzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHgNCmxvZy1h
Y3Rpb24gY29uc29sZSAgICAgICAgICAgICB4ICAgICAgICB4ICAgICAgICAgICAgICAgICB4ICAg
ICAgICAgICAgICB4ICAgICAgICAgICB4ICAgICAgICAgICAgeCAgICAgICAgICAgICAgIHgJDQps
b2ctYWN0aW9uIGJ1ZmZlciAgICAgICAgICAgICAgeCAgICAgICAgICAgICAgICAgICAgICAgICAg
eCAgICAgICAgICAgICAgeA0KbG9nLWFjdGlvbiBmaWxlICAgICAgICAgICAgICAgIHggICAgICAg
ICAgICAgICAgICAgICAgICAgIHggICAgICAgICAgICAgIHggICAgICAgICAgIHggICAgICAgICAg
ICB4ICAgICAgICAgICAgICAgeA0KbG9nLWFjdGlvbiByZW1vdGUgICAgICAgICAgICAgICAgICAg
ICAgIHggICAgICAgeCAgICAgICAgIHggICAgICAgICAgICAgIHggICAgICAgICAgIHggICAgICAg
ICAgICB4ICAgICAgICAgICAgICAgeA0KbG9nLWFjdGlvbiB0ZXJtaW5hbCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHggICAgICAgICAgICAgIHggICAgICAgICAgIHggICAg
ICAgICAgICAgICAgICAgICAgICAgICAgeA0KbG9nLWFjdGlvbiBzZXNzaW9uICAgICAgICAgICAg
IHggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB4DQpmZWF0dXJlIGJ1ZmZlci1saW1pdC1ieXRlcwkgPyAgICAgICAgICAgICAg
ICAgICAgICAgICAgeCAgICAgICAgICAgICAgeA0KZmVhdHVyZSBmaWxlLWxpbWl0LXNpemUgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHggICAgICAgICAgICAgIHggICAgICAgICAg
ICAgICAgICAgICAgICB4DQpmZWF0dXJlIGZpbGUtbGltaXQtZHVyYXRpb24gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgeCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHgNCmZlYXR1cmUgDQogdGVybWluYWwtZmFjaWxpdHktZGV2aWNlLWxvZ2dpbmcNCmZlYXR1cmUg
DQogc2Vzc2lvbi1mYWNpbGl0eS11c2VyLWxvZ2dpbmcgeCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHgNCmZlYXR1cmUgc2Vs
ZWN0LXNldi1jb21wYXJlICAgICB4ICAgICAgICAgICAgICAgICAgICAgICAgICB4ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHgNCmZlYXR1cmUg
c2VsZWN0LW1hdGNoICAgICAgICAgICB4ICAgICAgICAgICAgICAgICAgICAgICAgICB4ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeCAgICAgICAgICAgICAgIHgNCmZlYXR1
cmUgc3RydWN0dXJlZC1kYXRhICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeCAgICAgICAgICAgICAgIHggICAg
IFJlcXVpcmVkIGJlY2F1c2Ugb2YgUkZDIDU0MjQNCmZlYXR1cmUgc2lnbmVkLW1lc3NhZ2VzICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHggICAgIFJlcXVpcmVkIGJlY2F1c2Ugb2Yg
UkZDIDU4NDgNCgkJCQkJCQkJCQ0KQWxjYXRlbCAtIGh0dHBzOi8vaW5mb3Byb2R1Y3RzLmFsY2F0
ZWwtbHVjZW50LmNvbS9jZ2ktYmluL2RiYWNjZXNzZmlsZW5hbWUuY2dpLzkzMDA3MTA3MDJfVjFf
Nzc1MCUyMFNSJTIwKFNFUlZJQ0UlMjBST1VURVIpLnBkZg0KQ2llbmEgLSBodHRwczovL3d3dy5j
b21tb25jcml0ZXJpYXBvcnRhbC5vcmcvZmlsZXMvZXBmaWxlcy9zdF92aWQxMDQ2MC1zdC5wZGYN
CkNpc2NvIElPUy9YRSAtIGh0dHA6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9jcy9pb3Mt
eG1sL2lvcy9lc20vY29tbWFuZC9lc20tY3ItYm9vay9lc20tY3ItYTEuaHRtbA0KQ2lzY28gSU9T
L1hSIC0gaHR0cDovL3d3dy5jaXNjby5jb20vYy9lbi91cy90ZC9kb2NzL3JvdXRlcnMvYXNyOTAw
MC9zb2Z0d2FyZS9zeXN0ZW1fbW9uaXRvcmluZy9jb21tYW5kL3JlZmVyZW5jZS9iLXN5c21vbi1j
ci1hc3I5ay9iLXN5c21vbi1jci1hc3I5a19jaGFwdGVyXzAxMDAuaHRtbA0KQ2lzY28gTlhPUyAt
IGh0dHA6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9jcy9zd2l0Y2hlcy9kYXRhY2VudGVy
L25leHVzNzAwMC9zdy9zeXN0ZW0tbWFuYWdlbWVudC9jb21tYW5kL3JlZmVyZW5jZS9uN2tfc21f
Y21kX3JlZi9zbV9jbWRfbC5odG1sI3BnZklkLTEwMTQ2ODYNCkJyb2NhZGUgLSBodHRwOi8vd3d3
LmJyb2NhZGUuY29tL2NvbnRlbnQvaHRtbC9lbi9jb21tYW5kLXJlZmVyZW5jZS1ndWlkZS9ub3Mt
NzAwLWNvbW1hbmRyZWYvR1VJRC0yMjk3RTRDQS03NkRDLTQzRTUtOTE2NC1BQzFBQzlEM0Y0RTcu
aHRtbA0KSnVuaXBlciBKdW5PUyAtIGh0dHA6Ly93d3cuanVuaXBlci5uZXQvZG9jdW1lbnRhdGlv
bi9lbl9VUy9qdW5vczEyLjMvdG9waWNzL3JlZmVyZW5jZS9jb25maWd1cmF0aW9uLXN0YXRlbWVu
dC9zeXNsb2ctZWRpdC1zeXN0ZW0uaHRtOw0KTGludXggUnN5c2xvZyAtIGh0dHA6Ly93d3cucnN5
c2xvZy5jb20vZG9jL3Y4LXN0YWJsZS8JCQkJCQkJCQkNCg0KVGhhbmtzLA0KDQpDbHlkZQ0KDQoN
Ck9uIDUvMjcvMTYsIDEyOjMwIFBNLCAiU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQSkiIDxqYXNv
bi5zdGVybmVAbm9raWEuY29tPiB3cm90ZToNCg0KPkhpIENseWRlLA0KPg0KPkkgd2FzIGEgYml0
IHN1cnByaXNlZCB0byBzZWUgdGhlIHJlY2VpdmVyL3NlcnZlciBzaWRlIGNvbmZpZyBpbiBoZXJl
IChsb2ctaW5wdXQtdHJhbnNwb3J0cykuICBUaGF0IHNlZW1zIHRvIGJlIGEgc29tZXdoYXQgc2ln
bmlmaWNhbnQgY2hhbmdlIGluIHNjb3BlLiAgSSB0aG91Z2h0IHRoZSBmb2N1cyBvZiB0aGlzIHdh
cyBtb3JlIG9uIHRoZSBnZW5lcmF0aW9uICYgZGlzdHJpYnV0aW9uLiAgRG8gbWFueSBpbXBsZW1l
bnRhdGlvbnMgaGF2ZSBmdW5jdGlvbmFsaXR5IHRoYXQgbWFwcyB0byB0aGlzIGxvZy1pbnB1dC10
cmFuc3BvcnRzID8gICBJbiBhbnkgY2FzZSB0aGUgcHlhbmcgdHJlZSBoYXMgbG9nLWlucHV0LXRy
YW5zcG9ydHMgYnV0IGl0IGRvZXNuJ3Qgc2VlbSB0byBiZSBkb3duIGluIHRoZSBhY3R1YWwgbW9k
ZWwgaXRzZWxmLiAgQnV0IEknZCBiZSBpbmNsaW5lZCB0byBqdXN0IHJlbW92ZSB0aGlzIGZyb20g
dGhlIG1vZGVsLiAgTWF5YmUgTWFoZXNoIGhhcyBzb21lIHRob3VnaHRzIGhlcmUgKEkgZGlkbid0
IHNlZSBhIHBvc3RpbmcgYWJvdXQgdGhpcyBpbiB0aGUgbWFpbGluZyBsaXN0KS4NCj4NCj5JIGFn
cmVlIHRoZXJlIGFyZSBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbnMgb2YgY29uc29sZSwgYnVmZmVy
IGFuZCBzZXNzaW9uIGxvZ3MuICBCdXQgbWF5YmUgJ3Rlcm1pbmFsJyBzaG91bGQgYmUgcmVtb3Zl
ZCBvciBhbiBpZi1mZWF0dXJlID8gIEknbSBub3Qgc3VyZSB0aGF0IG9uZSBpcyBzbyB3aWRlc3By
ZWFkIChub3QgaW4gSlVOT1MsIG5vdCBpbiBTUiBPUykuDQo+DQo+QnVmZmVyLWxpbWl0LW1lc3Nh
Z2VzIGFuZCBoYXZpbmcgbXVsdGlwbGUgbG9nIGJ1ZmZlcnMgYXJlIGJvdGggc3VwcG9ydGVkIGJ5
IE5va2lhIFNSIE9TLiBJIHdvdWxkIHRoaW5rIHRoYXQgYm90aCBvZiB0aG9zZSB3b3VsZCBoYXZl
IHN1cHBvcnQgaW4gb3RoZXIgbG9nZ2luZyBpbXBsZW1lbnRhdGlvbnMgYXMgd2VsbC4gIEknbSBu
b3Qgc3VyZSBpZiBUb20gUC4gd2FzIHJlYWxseSBjb25jbHVkaW5nIHRoYXQgdGhlcmUgYXJlIG5v
IGltcGxlbWVudGF0aW9ucyBvZiB0aGVzZSBpbiBoaXMgZW1haWwuICBEbyB3ZSBoYXZlIG11bHRp
cGxlIGV4YW1wbGVzIG9mIGltcGxlbWVudGF0aW9ucyB0aGF0IGxpbWl0IGxvZyBidWZmZXJzIHVz
aW5nIGJ5dGVzID8NCj4NCj5CdWZmZXItbGltaXQtbWVzc2FnZXMgd291bGQgYmUgZWFzeSB0byBk
byBhcyBhbiBhdWdtZW50YXRpb24gYnV0IG1ha2luZyB0aGUgbG9nLWJ1ZmZlciBhIGxpc3QgaXMg
cHJvYmFibHkgc29tZXRoaW5nIHdlIHNob3VsZCBqdXN0IGRvIGZyb20gdGhlIHN0YXJ0LiAgVGhh
dCBpcyBhbHNvIGNvbnNpc3RlbnQgd2l0aCBhbGwgdGhlIG90aGVyIHR5cGVzIG9mIGFjdGlvbnMg
KGV4Y2VwdCBjb25zb2xlIG9mIGNvdXJzZSkuIFRoZSB1c2UgY2FzZSBmb3IgbXVsdGlwbGUgbG9n
IGJ1ZmZlcnMgaXMgdGhhdCB5b3UgbWlnaHQgc29ydC9maWx0ZXIgZGlmZmVyZW50IHR5cGVzIG9m
IGxvZyBldmVudHMgaW50byBkaWZmZXJlbnQgY2lyY3VsYXIgYnVmZmVycyAoaS5lLiBoYXZlIG9u
ZSBmb3IgcmVhbGx5IGNyaXRpY2FsIGxvZyBldmVudHMsIGV0YykgZm9yIHZpZXdpbmcgb24gdGhl
IG5vZGUuDQo+DQo+UmVnYXJkcywNCj5KYXNvbg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+RnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBFWFQgQ2x5ZGUgV2lsZGVzIChjd2lsZGVzKQ0KPlNlbnQ6IFR1ZXNkYXksIE1heSAx
MCwgMjAxNiAxNzoyMw0KPlRvOiBuZXRtb2RAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW25ldG1v
ZF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTA4LnR4dA0KPg0K
PkhpLA0KPg0KPlRoaXMgdXBkYXRlIHRvIHRoZSBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9k
ZWwtMDggaW5jb3Jwb3JhdGVzIHRoZSBjaGFuZ2VzIGxpc3RlZCBiZWxvdyBiYXNlZCBvbiBmZWVk
YmFjayByZWNlaXZlZC4NCj4NCj5BbiBhZGRpdGlvbmFsIHJldmlzaW9uIHRvIHRoaXMgZHJhZnQg
d2lsbCBiZSBuZWNlc3NhcnkgdG8gZmluYWxpemUgVExTIGNvbmZpZ3VyYXRpb24gbGVhdmVzIG9u
Y2UgdGhlIGlldGYtdGxzLWNsaWVudC1zZXJ2ZXItbW9kZWwgdGhhdCB0aGUgTkVUQ09ORiBXRyBw
bGFucyB0byBzcGluIG91dCBvZiB0aGUgbmV0Y29uZi1zZXJ2ZXItbW9kZWwgZHJhZnQgaXMgYXZh
aWxhYmxlLg0KPg0KPkNoYW5nZXMgZnJvbSBmZWVkYmFjayBmcm9tIE1haGVzaCBKOg0KPi0gYWRk
ZWQgc3VwcG9ydCBmb3IgY29uZmlndXJpbmcgYSBzeXNsb2cgc2VydmVyDQo+DQo+Q2hhbmdlcyBm
cm9tIGZlZWRiYWNrIGZyb20gVG9tIFAuOg0KPi0gcmVtb3ZlZCBmb3VyIGZlYXR1cmVzIGZvciBs
b2cgYWN0aW9uIGxlYXZlcyBjb25zb2xlLCBidWZmZXIsIHRlcm1pbmFsIGFuZCBzZXNzaW9uIHNp
bmNlIHRoZXkgYXJlIGltcGxlbWVudGVkIGJ5IG11bHRpcGxlIHZlbmRvcnMuIExhY2sgb2Ygc3Vw
cG9ydCBmb3IgdGhlc2UgYWN0aW9ucyBjYW4gYmUgaW5kaWNhdGVkIHVzaW5nIGEgZGV2aWF0aW9u
Lg0KPi0gcmVtb3ZlZCBmZWF0dXJlIGJ1ZmZlci1saW1pdC1tZXNzYWdlcyBzaW5jZSBpbXBsZW1l
bnRhdGlvbiBieSBhbnkgdmVuZG9yIGlzIHVua25vd24NCj4tIHJlbmFtZWQgZmVhdHVyZSB0ZXJt
aW5hbC1mYWNpbGl0eS11c2VyLWxvZ2dpbmctY29uZmlnIHRvIHRlcm1pbmFsLWZhY2lsaXR5LWRl
dmljZS1sb2dnaW5nIHRvIHNob3J0ZW4gdGhlIG5hbWUgYW5kIHRvIGNsYXJpZnkNCj4tIHJlbmFt
ZWQgZmVhdHVyZSBzZXNzaW9uLWZhY2lsaXR5LXVzZXItbG9nZ2luZy1jb25maWcgdG8gc2Vzc2lv
bi1mYWNpbGl0eS11c2VyLWxvZ2dpbmcgdG8gc2hvcnRlbiB0aGUgbmFtZQ0KPi0gcmVuYW1lZCBm
ZWF0dXJlIHNlbGVjdG9yLXNldm9wLWNvbmZpZyB0byBmZWF0dXJlIHNlbGVjdC1zZXYtY29tcGFy
ZSB0byBzaG9ydGVuIHRoZSBuYW1lDQo+LSByZW5hbWVkIGZlYXR1cmUgc2VsZWN0b3ItbWF0Y2gt
Y29uZmlnIHRvIGZlYXR1cmUgc2VsZWN0LW1hdGNoIHRvIHNob3J0ZW4gdGhlIG5hbWUNCj4tIHJl
bmFtZWQgZmVhdHVyZSBzdHJ1Y3R1cmVkLWRhdGEtY29uZmlnIHRvIGZlYXR1cmUgc3RydWN0dXJl
ZC1kYXRhIHRvIHNob3J0ZW4gdGhlIG5hbWUNCj4tIHJlbmFtZWQgZmVhdHVyZSBzaWduZWQtbWVz
c2FnZXMtY29uZmlnIHRvIGZlYXR1cmUgc2lnbmVkLW1lc3NhZ2VzIHRvIHNob3J0ZW4gdGhlIG5h
bWUNCj4tIHJlbW92ZWQgdGhlIGxvZy1idWZmZXIgbGlzdCBhbmQgbmFtZSBmcm9tIGxvZy1hY3Rp
b24gYnVmZmVyIHNpbmNlIGltcGxlbWVudGF0aW9uIGJ5IGFueSB2ZW5kb3IgaXMgdW5rbm93bg0K
Pi0gcmVtb3ZlZCB0aGUgd29yZCBkcmFmdCBmcm9tIHNlY3Rpb24gMQ0KPi0gdXBkYXRlZCB0aGUg
Y29weXJpZ2h0IGRhdGVzIGFuZCB0aGUgcmV2aXNpb24gZGF0ZXMgaW4gdGhlIG1vZGVscw0KPi0g
bW92ZWQgdGhlIGV4YW1wbGUgdG8gYW4gQXBwZW5kaXgNCj4tIHJlbW92ZWQgZS1tYWlsIGFkZHJl
c3NlcyBmcm9tIHRoZSBhY2tub3dsZWRnZW1lbnQgc2VjdGlvbg0KPg0KPkNoYW5nZXMgZnJvbSBm
ZWVkYmFjayBmcm9tIEJlbm9pdDoNCj4tIHJlbmFtZSBtb2R1bGUgdmVuZG9yLXN5c2xvZy10eXBl
cyB0byBtb2R1bGUgdmVuZG9yLXN5c2xvZy10eXBlcy1leGFtcGxlDQo+DQo+DQo+VGhhbmtzLA0K
Pg0KPktpcmFuIGFuZCBDbHlkZQ0KPg0KPg0KPg0KPg0KPk9uIDUvMTAvMTYsIDI6MTQgUE0sICJu
ZXRtb2Qgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPG5ldG1vZC1ib3Vu
Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3Rl
Og0KPg0KPj4NCj4+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u
LWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj5UaGlzIGRyYWZ0IGlzIGEgd29y
ayBpdGVtIG9mIHRoZSBORVRDT05GIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2Ugb2YgdGhlIElFVEYu
DQo+Pg0KPj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFNZU0xPRyBZQU5HIE1vZGVsDQo+PiAg
ICAgICAgQXV0aG9ycyAgICAgICAgIDogQ2x5ZGUgV2lsZGVzDQo+PiAgICAgICAgICAgICAgICAg
ICAgICAgICAgS2lyYW4gS291c2hpaw0KPj4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1u
ZXRtb2Qtc3lzbG9nLW1vZGVsLTA4LnR4dA0KPj4JUGFnZXMgICAgICAgICAgIDogMzUNCj4+CURh
dGUgICAgICAgICAgICA6IDIwMTYtMDUtMTANCj4+DQo+PkFic3RyYWN0Og0KPj4gICBUaGlzIGRv
Y3VtZW50IGRlc2NyaWJlcyBhIGRhdGEgbW9kZWwgZm9yIHRoZSBTeXNsb2cgcHJvdG9jb2wgd2hp
Y2ggaXMNCj4+ICAgdXNlZCB0byBjb252ZXkgZXZlbnQgbm90aWZpY2F0aW9uIG1lc3NhZ2VzLg0K
Pj4NCj4+DQo+PlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0
IGlzOg0KPj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1v
ZC1zeXNsb2ctbW9kZWwvDQo+Pg0KPj5UaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2
YWlsYWJsZSBhdDoNCj4+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0
bW9kLXN5c2xvZy1tb2RlbC0wOA0KPj4NCj4+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNp
b24gaXMgYXZhaWxhYmxlIGF0Og0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9
ZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTA4DQo+Pg0KPj4NCj4+UGxlYXNlIG5vdGUg
dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+
PnN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls
YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+DQo+PkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh
dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVy
bmV0LWRyYWZ0cy8NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+Pm5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+bmV0bW9kQGlldGYub3JnDQo+Pmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0
DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2QNCg0K


From nobody Tue May 31 13:56:28 2016
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 936D412D8E2 for ; Tue, 31 May 2016 13:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level: 
X-Spam-Status: No, score=-15.947 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=-1.426, 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 AQjKqF5yU37F for ; Tue, 31 May 2016 13:56:24 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B5F12D8DA for ; Tue, 31 May 2016 13:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10756; q=dns/txt; s=iport; t=1464728184; x=1465937784; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=AORJpugCaGDSiZovV9qDIJMZbjNtKmn/F81VNtUb27s=; b=Wfud+EjK3faR1lxji81MpI9XxTHAu2hs4LtnoIGoEwx87LnH3J1yf9++ 9hjHxpaGIjvjxQ5GumMOhfhn6nG8P8Czt2LiNMlXD5ldBtDm7a0U77+LR YWU0QX8YWjBv4mGphjA+ahVAcLhqeg5PNzq87cW2QkdDO0aeLyn0QnxB5 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgAY+k1X/4QNJK1SCYM9Vn0Gt3mCD?= =?us-ascii?q?wENgXoihW8CHIEjOBQBAQEBAQEBZSeERgEBBCcNNx4CAQgYBCgCAjAlAgQBEog?= =?us-ascii?q?vDpBTnRUGkS8BAQEBAQEBAQEBAQEBAQEBAQEBGQV7hSyDSoEDgUpngVgQBCODA?= =?us-ascii?q?4JfBYgOhVeBMokgAYV/iCCBaYRPiGSPSwEeAQFCg21uAQEBiHFFfwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.26,397,1459814400"; d="scan'208";a="110110127"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 May 2016 20:56:02 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4VKu2Br020725 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 May 2016 20:56:02 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 31 May 2016 15:56:01 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 31 May 2016 15:56:01 -0500
From: "Yingzhen Qu (yiqu)" 
To: "Acee Lindem (acee)" , Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: "A YANG Data Model for Routing Management" Modifications
Thread-Index: AQHRtO7tOcUgpX3Gp0qnsfGLAJZjo5/JFUMAgAPMwgCAABndAP//9FUAgATdqoCAAhJGAP//kh8A
Date: Tue, 31 May 2016 20:56:01 +0000
Message-ID: 
References:        
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.2.150604
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.160.221]
Content-Type: text/plain; charset="euc-kr"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] "A YANG Data Model for Routing Management" Modifications
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 20:56:26 -0000

U2luY2UgobBtdWx0aS1uZXh0LWhvcKGxIGlzIGEgbGlzdCBhbmQgd2UgbmVlZCBhIGtleSBmb3Ig
YSBsaXN0LCBldmVuIGNob2ljZQ0KZG9lc26hr3Qgd29yayBoZXJlLiBJoa9tIHRoaW5raW5nIG1h
eWJlIHdlIGNhbiB1c2UgobAwLjAuMC4wobEgZm9yIGVtcHR5IGlwDQphZGRyZXNzIGFuZCChsE5V
TEyhsSBmb3IgZW1wdHkgaW50ZXJmYWNlLCBidXQgaXQgZG9lc26hr3QgbG9vayBwcmV0dHkgYW55
d2F5Lg0KRXNwZWNpYWxseSB0aGUgaW50ZXJmYWNlIHNob3VsZCBiZSBhIHJlZmVyZW5jZSwgYW5k
IGl0IGNhbqGvdCBiZSChsE5VTEyhsS4NCg0KVGhhbmtzLA0KWWluZ3poZW4NCg0KT24gNS8zMS8x
NiwgMToyOSBQTSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToN
Cg0KPkhpIExhZGEsIA0KPklmIHdlIGNhbqGvdCBnZXQgWUFORyB0byBkbyB3aGF0IHdlIG5lZWQs
IGNhbiB3ZSBqdXN0IHN1cHBvcnQgYSBjaG9pY2Ugd2l0aA0KPmEgc3BlY2lhbCB2YWx1ZSBvZiCh
sHVuc3BlY2lmaWVkobEgZm9yIHRoZSBpbnRlcmZhY2UgYW5kIGFkZHJlc3M/DQo+QWRkaXRpb25h
bGx5LCB3ZaGvZCBuZWVkIGEgY29uc3RyYWludCB0aGF0IGVuZm9yY2VzIHRoZSBmYWN0IHRoYXQg
Ym90aA0KPmludGVyZmFjZSBhbmQgYWRkcmVzcyBjYW5ub3QgYmUgobB1bnNwZWNpZmllZKGxLg0K
Pg0KPlRoYW5rcywNCj5BY2VlIA0KPg0KPk9uIDUvMzAvMTYsIDg6NTEgQU0sICJMYWRpc2xhdiBM
aG90a2EiIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4NCj4+Illpbmd6aGVuIFF1ICh5aXF1KSIg
PHlpcXVAY2lzY28uY29tPiB3cml0ZXM6DQo+Pg0KPj4+IEhpIExhZGEsDQo+Pj4NCj4+PiBUaGUg
qfhtdWx0aS1uZXh0LWhvcKn3IGlzIHVzaW5nIHRoZSBjb21iaW5hdGlvbiBvZiBpbnRlcmZhY2Ug
YW5kIGFkZHJlc3MNCj4+PmFzDQo+Pj4gdGhlIGxpc3Qga2V5LiBJIGtub3cga2V5IGNhbqn2dCBi
ZSBlbXB0eSwgYnV0IGZvciBuZXh0IGhvcCBpdKn2cyBwb3NzaWJsZQ0KPj4+IHRoYXQgb25seSBl
aXRoZXIgaW50ZXJmYWNlIG9yIGFkZHJlc3MgaXMgdXNlZC4gSan2dmUgYmVlbiB0cnlpbmcgdG8N
Cj4+PmZpZ3VyZQ0KPj4+IG91dCBhIGJldHRlciB3YXkgdG8gcHJlc2VudCB0aGlzLCBhbnkgc3Vn
Z2VzdGlvbj8NCj4+DQo+Pk9wdGlvbmFsIGxpc3Qga2V5cyB3ZXJlIHByb3Bvc2VkIGZvciBZQU5H
IDEuMToNCj4+DQo+Pmh0dHBzOi8vc3ZuLnRvb2xzLmlldGYub3JnL3N2bi93Zy9uZXRtb2QveWFu
Zy0xLjEvaXNzdWVzLmh0bWwjc2VjLTEwDQo+Pg0KPj5UaGUgcmVhc29uIHRoYXQgdGhlIGlzc3Vl
IFkwOSB3YXMgZXZlbnR1YWxseSByZWplY3RlZCB3YXMgdGhhdCBtYW55DQo+PnBlb3BsZSB0aG91
Z2h0IGl0IHdhcyBhIHJlbGF0aXZlbHkgZmFyLXJlYWNoaW5nIGNoYW5nZS4gVGhpcyBtZWFucyB3
ZQ0KPj5hcmUgbGVmdCB3aXRoIHRoZSBzYW1lIG9wdGlvbnMgYXMgaW4gWUFORyAxLjAsIG5vbmUg
b2YgdGhlbSBiZWluZyB2ZXJ5DQo+PnByZXR0eToNCj4+DQo+Pi0gQWRkIGEgZHVtbXkgb3BhcXVl
IGtleSwgZS5nLg0KPj4NCj4+ICBsaXN0IG5leHQtaG9wLWVudHJpZXMgew0KPj4gICAga2V5IGlk
Ow0KPj4gICAgbGVhZiBpZCB7DQo+PiAgICAgIHR5cGUgdWludDE2Ow0KPj4gICAgfQ0KPj4gICAg
dW5pcXVlIGludGVyZmFjZSBhZGRyZXNzOw0KPj4gICAgLi4uDQo+PiAgfQ0KPj4NCj4+LSBVc2Ug
c3BlY2lhbCB2YWx1ZSwgc3VjaCBhcyBlbXB0eSBzdHJpbmcsIHRvIGluZGljYXRlIHRoYXQgZWl0
aGVyDQo+PiAgaW50ZXJmYWNlIG9yIGFkZHJlc3MgaXNuJ3QgcHJlc2VudC4gQnV0IHNpbmNlIGlu
ZXQ6aXB2WzQ2XS1hZGRyZXNzDQo+PiAgY2Fubm90IGJlIGVtcHR5LCB3ZSB3b3VsZCBuZWVkIHRv
IGRlZmluZSB0aGUgdHlwZSBvZiAiYWRkcmVzcyIgYXMgYQ0KPj4gIHVuaW9uIG9mIGVtcHR5IHN0
cmluZyBhbmQgaW5ldDppcHZbNDZdLWFkZHJlc3MuDQo+Pg0KPj5MYWRhDQo+Pg0KPj4+DQo+Pj4g
SWYgdGhlcmUgaXMgYW55dGhpbmcgSSBjYW4gaGVscCB3aXRoIHRoZSBtb2RpZmljYXRpb24sIHBs
ZWFzZSBsZXQgbWUNCj4+Pmtub3cuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gWWluZ3poZW4NCj4+
Pg0KPj4+IE9uIDUvMjcvMTYsIDQ6MTQgQU0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNp
c2NvLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj5IaSBMYWRhLCANCj4+Pj4NCj4+Pj5PbiA1LzI3LzE2
LCA1OjQyIEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+Pj4+
DQo+Pj4+PkhpIEFjZWUsDQo+Pj4+Pg0KPj4+Pj5JIGhhdmUgYSBjb3VwbGUgb2YgcXVlc3Rpb25z
Og0KPj4+Pj4NCj4+Pj4+MS4gSSBjaGFuZ2VkICJyb3V0aW5nLXByb3RvY29sIiAtPiAiY29udHJv
bC1wbGFuZS1wcm90b2NvbCIgKHRoaXMgaXMNCj4+Pj4+ICAgYWxyZWFkeSBpbiBHaXRIdWIpLiBB
cyBmb3IgaWRlbnRpdGllcywgSSBpbnRyb2R1Y2VkIGEgbmV3IGJhc2UNCj4+Pj4+ICAgaWRlbnRp
dHkgImNvbnRyb2wtcGxhbmUtcHJvdG9jb2wiLCBhbmQgZGVyaXZlZCAicm91dGluZy1wcm90b2Nv
bCINCj4+Pj4+ICAgZnJvbSBpdC4gU28gdGhlIGlkZWEgaXMgdGhhdCByb3V0aW5nIHByb3RvY29s
cyB3aWxsIHN0aWxsIHVzZQ0KPj4+Pj4gICAicm91dGluZy1wcm90b2NvbCIgYXMgdGhlaXIgYmFz
ZS4gSXMgaXQgT0s/DQo+Pj4+DQo+Pj4+WWVzIC0gYXMgbG9uZyBhcyB0aGVyZSBpcyBhIHNpbmds
ZSBsaXN0LiBJqfZsbCBwdWxsIHRoZSBzb3VyY2UgdG9kYXkuDQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4y
LiBXZSBjb3VsZCBkZWZpbmUgaWRlbnRpdGllcyBmb3Igcm91dGUgdHlwZXMgYnV0IEkgYW0gc3Rp
bGwgbm90DQo+Pj4+PiAgIGNvbnZpbmNlZCB0aGF0IHJvdXRlLXR5cGUgc2hvdWxkIGJlIGFkZGVk
IHRvIGlldGYtcm91dGluZyBiZWNhdXNlDQo+Pj4+PiAgIHRoZW4gd2UgY2FuJ3QgbGltaXQgdGhl
IHNldCBvZiB0eXBlcyBmb3IgZWFjaCBwcm90b2NvbCwgc28gdGhhdCwNCj4+Pj4+Zm9yDQo+Pj4+
PiAgIGV4YW1wbGUsIE9TUEYgcm91dGVzIGNvdWxkIGNhcnJ5IElTLUlTIExldmVsIFsxMl0gcm91
dGVzLg0KPj4+Pg0KPj4+PkRvIHlvdSBtZWFuIHRoYXQgT1NQRiB3b3VsZCBpbnN0YWxsIHRoZSB3
cm9uZyB0eXBlIG9mIHJvdXRlPyBJIHdvdWxkDQo+Pj4+c2VlDQo+Pj4+dGhpcyBhcyBhIGJ1ZyBi
dXQgbm90IHNvbWV0aGluZyB0aGUgbW9kZWwgaXRzZWxmIHNob3VsZCBlbmZvcmNlLg0KPj4+Pg0K
Pj4+Pk5vdGUgdGhhdCBPU1BGIGNhbiCp+GNhcnJ5qfcgYW55IHR5cGUgb2Ygcm91dGUgaWYgaXQg
aXMgaW1wb3J0ZWQgaW50bw0KPj4+Pk9TUEYNCj4+Pj5hbmQgYWR2ZXJ0aXNlZCBhcyBhbiBBUyBF
eHRlcm5hbCByb3V0ZS4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PjMuIFRoZSAibXVsdGktbmV4dC1ob3Ai
IGNhc2UgaW4gcmliLWV4dGVuZC0wMSB1c2VzIGludGVyZmFjZSBhbmQNCj4+Pj4+YWRkcmVzcw0K
Pj4+Pj4gICBhcyBrZXlzLiBUaGlzIG1lYW5zIHRoYXQgZm9yIGV2ZXJ5IG5leHQtaG9wICpib3Ro
KiBwYXJhbWV0ZXJzIGhhdmUNCj4+Pj4+dG8NCj4+Pj4+ICAgYmUgZ2l2ZW4uIElzIGl0IHJlYWxs
eSBpbnRlbmRlZD8NCj4+Pj4NCj4+Pj5ObyAtIGVpdGhlciBvciBib3RoIG11c3QgYmUgc3BlY2lm
aWVkIGJ1dCBib3RoIGFyZSBub3QgcmVxdWlyZWQuIEmp9mxsDQo+Pj4+bGVhdmUgdGhpcyB0byB5
b3UgWUFORyBleHBlcnRzLg0KPj4+Pg0KPj4+PlRoYW5rcywNCj4+Pj5BY2VlDQo+Pj4+DQo+Pj4+
DQo+Pj4+DQo+Pj4+Pg0KPj4+Pj5UaGFua3MsIExhZGENCj4+Pj4+DQo+Pj4+PiJBY2VlIExpbmRl
bSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JpdGVzOg0KPj4+Pj4NCj4+Pj4+PiBIaSBMYWRh
LCANCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gT24gNS8yMy8xNiwgODozMCBBTSwgIkxhZGlzbGF2
IExob3RrYSIgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IkFjZWUgTGlu
ZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cml0ZXM6DQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBI
aSBMYWRhLCANCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJIHRob3VnaHQgSSBnbyB0aHJvdWdoIHRoZSBp
bXBldHVzIGZvciB0aGUgY2hhbmdlcyBJIGRpc2N1c3NlZCBpbg0KPj4+Pj4+Pj5teQ0KPj4+Pj4+
Pj5sYXN0DQo+Pj4+Pj4+PiBFLW1haWwuIEkgYmVsaWV2ZSB3ZSBzaG91bGQgbWFrZSB0aGVzZSBj
aGFuZ2VzIGFuZCB0aGVuIGZyZWV6ZSB0aGUNCj4+Pj4+Pj4+IHNwZWNpZmljYXRpb24gb3RoZXIg
dGhhbiBwb3NzaWJsZSBtb2RpZmljYXRpb25zIGJhc2VkIG9uIHRoZQ0KPj4+Pj4+Pj5jb25zZW5z
dXMNCj4+Pj4+Pj4+Zm9yDQo+Pj4+Pj4+PiB0aGUgTkVUTU9EIG9wZXJhdGlvbmFsIHN0YXRlIGRp
cmVjdGlvbi4NCj4+Pj4+Pj4NCj4+Pj4+Pj5JIGFncmVlLg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+
Pj4+Pj4+IFRoZSByZXF1ZXN0IHRvIG1lcmdlIGRyYWZ0DQo+Pj4+Pj4+PiBodHRwczovL3d3dy5p
ZXRmLm9yZy9pZC9kcmFmdC1hY2VlLXJ0Z3dnLXlhbmctcmliLWV4dGVuZC0wMS50eHQgaXMNCj4+
Pj4+Pj4+YmFzZWQNCj4+Pj4+Pj4+IG9uIHRoZSBjb21tZW50cyB3ZSByZWNlaXZlZCBpbiB0aGUg
UlRHIFdHIG1lZXRpbmcgYXQgSUVURiA5NS4gVGhlDQo+Pj4+Pj4+PiBjb25zZW5zdXMgaW4gdGhl
IHJvb20gd2FzIHRoYXQgdGhlIHByb3Bvc2VkIG5leHQtaG9wIGFkZGl0aW9ucw0KPj4+Pj4+Pj53
ZXJlDQo+Pj4+Pj4+PnByZXR0eQ0KPj4+Pj4+Pj4gc3RhbmRhcmQgaW4gYSBuZXR3b3JraW5nIGRl
dmljZSBzdXBwb3J0aW5nIHJvdXRpbmcuIFdlIHdlcmUNCj4+Pj4+Pj4+Y2FyZWZ1bA0KPj4+Pj4+
Pj5ub3QNCj4+Pj4+Pj4+dG8NCj4+Pj4+Pj4+IGluY2x1ZGUgYW55IE1QTFMgb3Igb3RoZXIgdHVu
bmVsaW5nIHRlY2hub2xvZ2llcy4gSWYgeW91IGZlZWwgdGhhdA0KPj4+Pj4+Pj5zb21lDQo+Pj4+
Pj4+Pm9mDQo+Pj4+Pj4+PiB0aGVzZSBhcmUgbm90IGFwcGxpY2FibGUgdG8gaG9zdHMsIHdlIGNv
dWxkIG1ha2UgdGhlbSBmZWF0dXJlcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj5JIGRvbid0IHRoaW5rIHRo
YXQgbWFueSBob21lIHJvdXRlcnMgc3VwcG9ydCB0aGVzZSBmZWF0dXJlcyBlaXRoZXINCj4+Pj4+
Pj4oZXhjZXB0IEVDTVApLiBJIHN0aWxsIHRoaW5rIHRoZXkgc2hvdWxkIGJlIGFkZGVkIGFzIGF1
Z21lbnRzLCBhbmQsDQo+Pj4+Pj4+YXMNCj4+Pj4+Pj55b3Uga25vdywgaWV0Zi1yb3V0aW5nIHdh
cyBwcmV2aW91c2x5IG1vZGlmaWVkIHRvIGVuYWJsZSBpdC4gQW5vdGhlcg0KPj4+Pj4+PmFkdmFu
dGFnZSBvZiBkb2luZyBzbyBpcyB0aGF0IGl0IHdpbGwgYmUgbW9yZSBmdXR1cmUtcHJvb2Y6IGl0
IHdpbGwNCj4+Pj4+Pj5iZQ0KPj4+Pj4+PmVhc2llciB0byByZXBsYWNlIHRoZWlyIGRlZmluaXRp
b25zIHdpdGggc29tZXRoaW5nIGVsc2UsIHdoaWNoIG1heQ0KPj4+Pj4+PmJlDQo+Pj4+Pj4+aW1w
b3NzaWJsZSBpZiB0aGV5IGFyZSBhbiBpbnRlZ3JhbCBwYXJ0IG9mIGlldGYtcm91dGluZywgYmVj
YXVzZSBvZg0KPj4+Pj4+PnRoZQ0KPj4+Pj4+PnJpZ2lkIHJ1bGVzIGZvciB1cGRhdGluZyBwdWJs
aXNoZWQgWUFORyBtb2R1bGVzLg0KPj4+Pj4+DQo+Pj4+Pj4gTG91IGFuZCBJIGhhZCBhIGxlbmd0
aHkgZGlzY3Vzc2lvbiBvbiB0aGlzIGFuZCB3ZSBhZ3JlZWQgdGhhdCB0aGUNCj4+Pj4+PmJhc2UN
Cj4+Pj4+PiBzaG91bGQgc3VwcG9ydCBFQ01QIGFuZCBhIG1ldHJpYyBwZXItcGF0aCAobGlrZSBM
aW51eCkuDQo+Pj4+Pj4NCj4+Pj4+PiBJIGFsc28gdGhpbmsgd2UgY291bGQgcm91dGUtdHlwZSBh
bmQgdGFnIHRvIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBhcw0KPj4+Pj4+bG9uZw0KPj4+Pj4+IGFz
IHRoZXkgaGF2ZSBkZWZhdWx0IHZhbHVlIG9mIKn4dW5zcGVjaWZpZWSp9yBhbmQgqfhub25lqfcg
cmVzcGVjdGl2ZWx5Lg0KPj4+Pj4+VGhpcw0KPj4+Pj4+IHdvdWxkIGFkZHJlc3MgdGhlIEUtbWFp
bCBIZWxlbiBDaGVuIHNlbnQgdG8gTkVUTU9EIHRvZGF5Lg0KPj4+Pj4+DQo+Pj4+Pj4gQXMgZm9y
IGNvbmZpZ3VyYXRpb24gb2YgdGhlIHRhZyBhbmQgdGhlIGJhY2t1cCBwYXRoLCB3ZSBjYW4ga2Vl
cA0KPj4+Pj4+dGhlc2UNCj4+Pj4+PmFzDQo+Pj4+Pj4gYXVnbWVudGF0aW9ucy4NCj4+Pj4+Pg0K
Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoZSByZXF1ZXN0IHRvIGNoYW5nZSB0aGUgbmFt
ZSBvZiByb3V0aW5nLXByb3RvY29scyB0bw0KPj4+Pj4+Pj4gY29udHJvbC1wbGFuZS1wcm90b2Nv
bHMgaXMgaW4gc3VwcG9ydCBvZg0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJh
ZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbC0wNC50eHQuDQo+Pj4+Pj4+PlRoaXMNCj4+
Pj4+Pj4+IGluZm9ybWF0aXZlIG1vZGVsIHdhcyBhbHdheXMgaGFkIGEgY29udHJvbC1wbGFuZS1w
cm90b2NvbHMgbGlzdC4NCj4+Pj4+Pj4+SWYNCj4+Pj4+Pj4+d2UNCj4+Pj4+Pj4+IGRvbqn2dCBw
dXQgYSBzdGFuZGFyZHMtYmFzZWQgY29udHJvbC1wbGFuZS1wcm90b2NvbHMgbGlzdCBoZXJlLCB3
ZQ0KPj4+Pj4+Pj53aWxsDQo+Pj4+Pj4+PiBuZWVkIHRvIGhhdmUgb25lIGxpc3QgZm9yIHJvdXRp
bmctcHJvdG9jb2xzIChpLmUuLCBSSUIgY2xpZW50cykNCj4+Pj4+Pj4+YW5kDQo+Pj4+Pj4+PiBh
bm90aGVyIGxpc3QgZm9yIG5vbi1SSUIgY2xpZW50cy4gV2hpbGUgdGhlIG5hbWUgaXMgc29tZXdo
YXQgbW9yZQ0KPj4+Pj4+Pj5nZW5lcmFsDQo+Pj4+Pj4+PiB0aGFuIHRoZSBzY29wZSBvZiByb3V0
aW5nLWNmZywgaXQgc2VlbXMgbGlrZSBhIHZlcnkgZ29vZCB0cmFkZS1vZmYNCj4+Pj4+Pj4+dG8N
Cj4+Pj4+Pj4+cHV0DQo+Pj4+Pj4+PiBpdCBoZXJlIHJhdGhlciB0aGFuIGhhdmUgdHdvIGxpc3Rz
IGFuZCBoYXZlIHRvIG1vdmUgcHJvdG9jb2xzDQo+Pj4+Pj4+PmJldHdlZW4NCj4+Pj4+Pj4+IGxp
c3RzIGlmIHRoZXkgc3VkZGVubHkgYWRkIGEgY2FwYWJpbGl0eSB0aGF0IGFsbG93cyB0aGUgcHJv
dG9jb2wNCj4+Pj4+Pj4+dG8NCj4+Pj4+Pj4+bW9kaWZ5DQo+Pj4+Pj4+PiB0aGUgUklCLg0KPj4+
Pj4+Pg0KPj4+Pj4+PkkgZG9uJ3QgbWluZCBjaGFuZ2luZyB0aGUgbmFtZSwgYnV0IEkgd2FzIGEg
Yml0IGNvbmNlcm5lZCB0aGF0IHRoaXMNCj4+Pj4+Pj5tYXkNCj4+Pj4+Pj5pbmR1Y2Ugb3RoZXIg
Y2hhbmdlcywgZS5nLiBpbiB0aGUgZGVmaW5pdGlvbiBvZiBSSUJzLiBMb3UgYWxyZWFkeQ0KPj4+
Pj4+PnRvbGQNCj4+Pj4+Pj5tZSBpdCB3YXMgbm90IHRoZSBjYXNlLCBzbyB3ZSBjYW4gY2hhbmdl
IHRoZSBuYW1lLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBHcmVhdC4gDQo+Pj4+Pj4NCj4+Pj4+
PiBUaGFua3MsDQo+Pj4+Pj4gQWNlZSANCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+
TGFkYQ0KPj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IElmIHlvdSBhcmUgYW1lbmFibGUgdG8g
dGhlc2UgbW9kaWZpY2F0aW9ucywgd2UgY2FuIGNvbmZpcm0gdGhlbSBvbg0KPj4+Pj4+Pj50aGUN
Cj4+Pj4+Pj4+IE5FVE1PRCBsaXN0Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+
Pj4+IEFjZWUgDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pi0tIA0KPj4+Pj4+PkxhZGlzbGF2
IExob3RrYSwgQ1ouTklDIExhYnMNCj4+Pj4+Pj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4+Pj4+
DQo+Pj4+Pg0KPj4+Pj4tLSANCj4+Pj4+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPj4+
Pj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4+Pg0KPj4+DQo+Pg0KPj4tLSANCj4+TGFkaXNsYXYg
TGhvdGthLCBDWi5OSUMgTGFicw0KPj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KPg0KDQo=


From nobody Tue May 31 14:02:48 2016
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 E3FEE12D8E6 for ; Tue, 31 May 2016 14:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 bSh_yAMcbp4r for ; Tue, 31 May 2016 14:02:42 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 611DD12D8DA for ; Tue, 31 May 2016 14:02:42 -0700 (PDT)
Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 6E5CC1AE018B; Tue, 31 May 2016 23:02:41 +0200 (CEST)
Date: Tue, 31 May 2016 23:02:41 +0200 (CEST)
Message-Id: <20160531.230241.1831955717429467771.mbj@tail-f.com>
To: acee@cisco.com
From: Martin Bjorklund 
In-Reply-To: 
References:   
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] "A YANG Data Model for Routing Management" Modifications
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 21:02:46 -0000

IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4gSGkgTGFkYSwg
DQo+IElmIHdlIGNhbuKAmXQgZ2V0IFlBTkcgdG8gZG8gd2hhdCB3ZSBuZWVkLCBjYW4gd2UganVz
dCBzdXBwb3J0IGEgY2hvaWNlIHdpdGgNCj4gYSBzcGVjaWFsIHZhbHVlIG9mIOKAnHVuc3BlY2lm
aWVk4oCdIGZvciB0aGUgaW50ZXJmYWNlIGFuZCBhZGRyZXNzPw0KDQpZZXMsIHlvdSBjYW4gbWFr
ZSB0aGVzZSBrZXlzIGJlIHVuaW9ucyBvZiBpbnRlcmZhY2UtcmVmIGFuZCBhbiBlbnVtDQondW5z
cGVjaWZpZWQnLCBhbmQgYW4gaXAtYWRkcmVzcyBhbmQgZW51bSAndW5zcGVjaWZpZWQnLg0KDQo+
IEFkZGl0aW9uYWxseSwgd2XigJlkIG5lZWQgYSBjb25zdHJhaW50IHRoYXQgZW5mb3JjZXMgdGhl
IGZhY3QgdGhhdCBib3RoDQo+IGludGVyZmFjZSBhbmQgYWRkcmVzcyBjYW5ub3QgYmUg4oCcdW5z
cGVjaWZpZWTigJ0uDQoNCiAgIG11c3QgJ2tleTEgIT0gInVuc3BlY2lmaWVkIiBvciBrZXkyICE9
ICJ1bnNwZWNpZmllZCInOw0KDQoNCi9tYXJ0aW4NCg0KDQoNCj4gDQo+IFRoYW5rcywNCj4gQWNl
ZSANCj4gDQo+IE9uIDUvMzAvMTYsIDg6NTEgQU0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FA
bmljLmN6PiB3cm90ZToNCj4gDQo+ID4iWWluZ3poZW4gUXUgKHlpcXUpIiA8eWlxdUBjaXNjby5j
b20+IHdyaXRlczoNCj4gPg0KPiA+PiBIaSBMYWRhLA0KPiA+Pg0KPiA+PiBUaGUgwrNtdWx0aS1u
ZXh0LWhvcMKyIGlzIHVzaW5nIHRoZSBjb21iaW5hdGlvbiBvZiBpbnRlcmZhY2UgYW5kIGFkZHJl
c3MNCj4gPj5hcw0KPiA+PiB0aGUgbGlzdCBrZXkuIEkga25vdyBrZXkgY2Fuwrl0IGJlIGVtcHR5
LCBidXQgZm9yIG5leHQgaG9wIGl0wrlzIHBvc3NpYmxlDQo+ID4+IHRoYXQgb25seSBlaXRoZXIg
aW50ZXJmYWNlIG9yIGFkZHJlc3MgaXMgdXNlZC4gScK5dmUgYmVlbiB0cnlpbmcgdG8NCj4gPj5m
aWd1cmUNCj4gPj4gb3V0IGEgYmV0dGVyIHdheSB0byBwcmVzZW50IHRoaXMsIGFueSBzdWdnZXN0
aW9uPw0KPiA+DQo+ID5PcHRpb25hbCBsaXN0IGtleXMgd2VyZSBwcm9wb3NlZCBmb3IgWUFORyAx
LjE6DQo+ID4NCj4gPmh0dHBzOi8vc3ZuLnRvb2xzLmlldGYub3JnL3N2bi93Zy9uZXRtb2QveWFu
Zy0xLjEvaXNzdWVzLmh0bWwjc2VjLTEwDQo+ID4NCj4gPlRoZSByZWFzb24gdGhhdCB0aGUgaXNz
dWUgWTA5IHdhcyBldmVudHVhbGx5IHJlamVjdGVkIHdhcyB0aGF0IG1hbnkNCj4gPnBlb3BsZSB0
aG91Z2h0IGl0IHdhcyBhIHJlbGF0aXZlbHkgZmFyLXJlYWNoaW5nIGNoYW5nZS4gVGhpcyBtZWFu
cyB3ZQ0KPiA+YXJlIGxlZnQgd2l0aCB0aGUgc2FtZSBvcHRpb25zIGFzIGluIFlBTkcgMS4wLCBu
b25lIG9mIHRoZW0gYmVpbmcgdmVyeQ0KPiA+cHJldHR5Og0KPiA+DQo+ID4tIEFkZCBhIGR1bW15
IG9wYXF1ZSBrZXksIGUuZy4NCj4gPg0KPiA+ICBsaXN0IG5leHQtaG9wLWVudHJpZXMgew0KPiA+
ICAgIGtleSBpZDsNCj4gPiAgICBsZWFmIGlkIHsNCj4gPiAgICAgIHR5cGUgdWludDE2Ow0KPiA+
ICAgIH0NCj4gPiAgICB1bmlxdWUgaW50ZXJmYWNlIGFkZHJlc3M7DQo+ID4gICAgLi4uDQo+ID4g
IH0NCj4gPg0KPiA+LSBVc2Ugc3BlY2lhbCB2YWx1ZSwgc3VjaCBhcyBlbXB0eSBzdHJpbmcsIHRv
IGluZGljYXRlIHRoYXQgZWl0aGVyDQo+ID4gIGludGVyZmFjZSBvciBhZGRyZXNzIGlzbid0IHBy
ZXNlbnQuIEJ1dCBzaW5jZSBpbmV0Omlwdls0Nl0tYWRkcmVzcw0KPiA+ICBjYW5ub3QgYmUgZW1w
dHksIHdlIHdvdWxkIG5lZWQgdG8gZGVmaW5lIHRoZSB0eXBlIG9mICJhZGRyZXNzIiBhcyBhDQo+
ID4gIHVuaW9uIG9mIGVtcHR5IHN0cmluZyBhbmQgaW5ldDppcHZbNDZdLWFkZHJlc3MuDQo+ID4N
Cj4gPkxhZGENCj4gPg0KPiA+Pg0KPiA+PiBJZiB0aGVyZSBpcyBhbnl0aGluZyBJIGNhbiBoZWxw
IHdpdGggdGhlIG1vZGlmaWNhdGlvbiwgcGxlYXNlIGxldCBtZQ0KPiA+Pmtub3cuDQo+ID4+DQo+
ID4+IFRoYW5rcywNCj4gPj4gWWluZ3poZW4NCj4gPj4NCj4gPj4gT24gNS8yNy8xNiwgNDoxNCBB
TSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4gPj4NCj4g
Pj4+SGkgTGFkYSwgDQo+ID4+Pg0KPiA+Pj5PbiA1LzI3LzE2LCA1OjQyIEFNLCAiTGFkaXNsYXYg
TGhvdGthIiA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4+SGkgQWNlZSwNCj4g
Pj4+Pg0KPiA+Pj4+SSBoYXZlIGEgY291cGxlIG9mIHF1ZXN0aW9uczoNCj4gPj4+Pg0KPiA+Pj4+
MS4gSSBjaGFuZ2VkICJyb3V0aW5nLXByb3RvY29sIiAtPiAiY29udHJvbC1wbGFuZS1wcm90b2Nv
bCIgKHRoaXMgaXMNCj4gPj4+PiAgIGFscmVhZHkgaW4gR2l0SHViKS4gQXMgZm9yIGlkZW50aXRp
ZXMsIEkgaW50cm9kdWNlZCBhIG5ldyBiYXNlDQo+ID4+Pj4gICBpZGVudGl0eSAiY29udHJvbC1w
bGFuZS1wcm90b2NvbCIsIGFuZCBkZXJpdmVkICJyb3V0aW5nLXByb3RvY29sIg0KPiA+Pj4+ICAg
ZnJvbSBpdC4gU28gdGhlIGlkZWEgaXMgdGhhdCByb3V0aW5nIHByb3RvY29scyB3aWxsIHN0aWxs
IHVzZQ0KPiA+Pj4+ICAgInJvdXRpbmctcHJvdG9jb2wiIGFzIHRoZWlyIGJhc2UuIElzIGl0IE9L
Pw0KPiA+Pj4NCj4gPj4+WWVzIC0gYXMgbG9uZyBhcyB0aGVyZSBpcyBhIHNpbmdsZSBsaXN0LiBJ
wrlsbCBwdWxsIHRoZSBzb3VyY2UgdG9kYXkuDQo+ID4+Pg0KPiA+Pj4+DQo+ID4+Pj4yLiBXZSBj
b3VsZCBkZWZpbmUgaWRlbnRpdGllcyBmb3Igcm91dGUgdHlwZXMgYnV0IEkgYW0gc3RpbGwgbm90
DQo+ID4+Pj4gICBjb252aW5jZWQgdGhhdCByb3V0ZS10eXBlIHNob3VsZCBiZSBhZGRlZCB0byBp
ZXRmLXJvdXRpbmcgYmVjYXVzZQ0KPiA+Pj4+ICAgdGhlbiB3ZSBjYW4ndCBsaW1pdCB0aGUgc2V0
IG9mIHR5cGVzIGZvciBlYWNoIHByb3RvY29sLCBzbyB0aGF0LCBmb3INCj4gPj4+PiAgIGV4YW1w
bGUsIE9TUEYgcm91dGVzIGNvdWxkIGNhcnJ5IElTLUlTIExldmVsIFsxMl0gcm91dGVzLg0KPiA+
Pj4NCj4gPj4+RG8geW91IG1lYW4gdGhhdCBPU1BGIHdvdWxkIGluc3RhbGwgdGhlIHdyb25nIHR5
cGUgb2Ygcm91dGU/IEkgd291bGQgc2VlDQo+ID4+PnRoaXMgYXMgYSBidWcgYnV0IG5vdCBzb21l
dGhpbmcgdGhlIG1vZGVsIGl0c2VsZiBzaG91bGQgZW5mb3JjZS4NCj4gPj4+DQo+ID4+Pk5vdGUg
dGhhdCBPU1BGIGNhbiDCs2NhcnJ5wrIgYW55IHR5cGUgb2Ygcm91dGUgaWYgaXQgaXMgaW1wb3J0
ZWQgaW50byBPU1BGDQo+ID4+PmFuZCBhZHZlcnRpc2VkIGFzIGFuIEFTIEV4dGVybmFsIHJvdXRl
Lg0KPiA+Pj4NCj4gPj4+Pg0KPiA+Pj4+My4gVGhlICJtdWx0aS1uZXh0LWhvcCIgY2FzZSBpbiBy
aWItZXh0ZW5kLTAxIHVzZXMgaW50ZXJmYWNlIGFuZA0KPiA+Pj4+YWRkcmVzcw0KPiA+Pj4+ICAg
YXMga2V5cy4gVGhpcyBtZWFucyB0aGF0IGZvciBldmVyeSBuZXh0LWhvcCAqYm90aCogcGFyYW1l
dGVycyBoYXZlDQo+ID4+Pj50bw0KPiA+Pj4+ICAgYmUgZ2l2ZW4uIElzIGl0IHJlYWxseSBpbnRl
bmRlZD8NCj4gPj4+DQo+ID4+Pk5vIC0gZWl0aGVyIG9yIGJvdGggbXVzdCBiZSBzcGVjaWZpZWQg
YnV0IGJvdGggYXJlIG5vdCByZXF1aXJlZC4gScK5bGwNCj4gPj4+bGVhdmUgdGhpcyB0byB5b3Ug
WUFORyBleHBlcnRzLg0KPiA+Pj4NCj4gPj4+VGhhbmtzLA0KPiA+Pj5BY2VlDQo+ID4+Pg0KPiA+
Pj4NCj4gPj4+DQo+ID4+Pj4NCj4gPj4+PlRoYW5rcywgTGFkYQ0KPiA+Pj4+DQo+ID4+Pj4iQWNl
ZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyaXRlczoNCj4gPj4+Pg0KPiA+Pj4+
PiBIaSBMYWRhLCANCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gT24gNS8yMy8xNiwgODozMCBB
TSwgIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+Pj4+Pg0KPiA+
Pj4+Pj4iQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyaXRlczoNCj4gPj4+
Pj4+DQo+ID4+Pj4+Pj4gSGkgTGFkYSwgDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBJIHRob3VnaHQg
SSBnbyB0aHJvdWdoIHRoZSBpbXBldHVzIGZvciB0aGUgY2hhbmdlcyBJIGRpc2N1c3NlZCBpbg0K
PiA+Pj4+Pj4+bXkNCj4gPj4+Pj4+Pmxhc3QNCj4gPj4+Pj4+PiBFLW1haWwuIEkgYmVsaWV2ZSB3
ZSBzaG91bGQgbWFrZSB0aGVzZSBjaGFuZ2VzIGFuZCB0aGVuIGZyZWV6ZSB0aGUNCj4gPj4+Pj4+
PiBzcGVjaWZpY2F0aW9uIG90aGVyIHRoYW4gcG9zc2libGUgbW9kaWZpY2F0aW9ucyBiYXNlZCBv
biB0aGUNCj4gPj4+Pj4+PmNvbnNlbnN1cw0KPiA+Pj4+Pj4+Zm9yDQo+ID4+Pj4+Pj4gdGhlIE5F
VE1PRCBvcGVyYXRpb25hbCBzdGF0ZSBkaXJlY3Rpb24uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj5JIGFn
cmVlLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoZSByZXF1ZXN0IHRvIG1lcmdl
IGRyYWZ0DQo+ID4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtYWNlZS1ydGd3
Zy15YW5nLXJpYi1leHRlbmQtMDEudHh0IGlzDQo+ID4+Pj4+Pj5iYXNlZA0KPiA+Pj4+Pj4+IG9u
IHRoZSBjb21tZW50cyB3ZSByZWNlaXZlZCBpbiB0aGUgUlRHIFdHIG1lZXRpbmcgYXQgSUVURiA5
NS4gVGhlDQo+ID4+Pj4+Pj4gY29uc2Vuc3VzIGluIHRoZSByb29tIHdhcyB0aGF0IHRoZSBwcm9w
b3NlZCBuZXh0LWhvcCBhZGRpdGlvbnMgd2VyZQ0KPiA+Pj4+Pj4+cHJldHR5DQo+ID4+Pj4+Pj4g
c3RhbmRhcmQgaW4gYSBuZXR3b3JraW5nIGRldmljZSBzdXBwb3J0aW5nIHJvdXRpbmcuIFdlIHdl
cmUgY2FyZWZ1bA0KPiA+Pj4+Pj4+bm90DQo+ID4+Pj4+Pj50bw0KPiA+Pj4+Pj4+IGluY2x1ZGUg
YW55IE1QTFMgb3Igb3RoZXIgdHVubmVsaW5nIHRlY2hub2xvZ2llcy4gSWYgeW91IGZlZWwgdGhh
dA0KPiA+Pj4+Pj4+c29tZQ0KPiA+Pj4+Pj4+b2YNCj4gPj4+Pj4+PiB0aGVzZSBhcmUgbm90IGFw
cGxpY2FibGUgdG8gaG9zdHMsIHdlIGNvdWxkIG1ha2UgdGhlbSBmZWF0dXJlcy4NCj4gPj4+Pj4+
DQo+ID4+Pj4+PkkgZG9uJ3QgdGhpbmsgdGhhdCBtYW55IGhvbWUgcm91dGVycyBzdXBwb3J0IHRo
ZXNlIGZlYXR1cmVzIGVpdGhlcg0KPiA+Pj4+Pj4oZXhjZXB0IEVDTVApLiBJIHN0aWxsIHRoaW5r
IHRoZXkgc2hvdWxkIGJlIGFkZGVkIGFzIGF1Z21lbnRzLCBhbmQsDQo+ID4+Pj4+PmFzDQo+ID4+
Pj4+PnlvdSBrbm93LCBpZXRmLXJvdXRpbmcgd2FzIHByZXZpb3VzbHkgbW9kaWZpZWQgdG8gZW5h
YmxlIGl0LiBBbm90aGVyDQo+ID4+Pj4+PmFkdmFudGFnZSBvZiBkb2luZyBzbyBpcyB0aGF0IGl0
IHdpbGwgYmUgbW9yZSBmdXR1cmUtcHJvb2Y6IGl0IHdpbGwNCj4gPj4+Pj4+YmUNCj4gPj4+Pj4+
ZWFzaWVyIHRvIHJlcGxhY2UgdGhlaXIgZGVmaW5pdGlvbnMgd2l0aCBzb21ldGhpbmcgZWxzZSwg
d2hpY2ggbWF5IGJlDQo+ID4+Pj4+PmltcG9zc2libGUgaWYgdGhleSBhcmUgYW4gaW50ZWdyYWwg
cGFydCBvZiBpZXRmLXJvdXRpbmcsIGJlY2F1c2Ugb2YNCj4gPj4+Pj4+dGhlDQo+ID4+Pj4+PnJp
Z2lkIHJ1bGVzIGZvciB1cGRhdGluZyBwdWJsaXNoZWQgWUFORyBtb2R1bGVzLg0KPiA+Pj4+Pg0K
PiA+Pj4+PiBMb3UgYW5kIEkgaGFkIGEgbGVuZ3RoeSBkaXNjdXNzaW9uIG9uIHRoaXMgYW5kIHdl
IGFncmVlZCB0aGF0IHRoZQ0KPiA+Pj4+PmJhc2UNCj4gPj4+Pj4gc2hvdWxkIHN1cHBvcnQgRUNN
UCBhbmQgYSBtZXRyaWMgcGVyLXBhdGggKGxpa2UgTGludXgpLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJ
IGFsc28gdGhpbmsgd2UgY291bGQgcm91dGUtdHlwZSBhbmQgdGFnIHRvIHRoZSBvcGVyYXRpb25h
bCBzdGF0ZSBhcw0KPiA+Pj4+PmxvbmcNCj4gPj4+Pj4gYXMgdGhleSBoYXZlIGRlZmF1bHQgdmFs
dWUgb2YgwrN1bnNwZWNpZmllZMKyIGFuZCDCs25vbmXCsiByZXNwZWN0aXZlbHkuDQo+ID4+Pj4+
VGhpcw0KPiA+Pj4+PiB3b3VsZCBhZGRyZXNzIHRoZSBFLW1haWwgSGVsZW4gQ2hlbiBzZW50IHRv
IE5FVE1PRCB0b2RheS4NCj4gPj4+Pj4NCj4gPj4+Pj4gQXMgZm9yIGNvbmZpZ3VyYXRpb24gb2Yg
dGhlIHRhZyBhbmQgdGhlIGJhY2t1cCBwYXRoLCB3ZSBjYW4ga2VlcA0KPiA+Pj4+PnRoZXNlDQo+
ID4+Pj4+YXMNCj4gPj4+Pj4gYXVnbWVudGF0aW9ucy4NCj4gPj4+Pj4NCj4gPj4+Pj4+DQo+ID4+
Pj4+Pj4NCj4gPj4+Pj4+PiBUaGUgcmVxdWVzdCB0byBjaGFuZ2UgdGhlIG5hbWUgb2Ygcm91dGlu
Zy1wcm90b2NvbHMgdG8NCj4gPj4+Pj4+PiBjb250cm9sLXBsYW5lLXByb3RvY29scyBpcyBpbiBz
dXBwb3J0IG9mDQo+ID4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcnRneWFu
Z2R0LXJ0Z3dnLWRldmljZS1tb2RlbC0wNC50eHQuDQo+ID4+Pj4+Pj5UaGlzDQo+ID4+Pj4+Pj4g
aW5mb3JtYXRpdmUgbW9kZWwgd2FzIGFsd2F5cyBoYWQgYSBjb250cm9sLXBsYW5lLXByb3RvY29s
cyBsaXN0LiBJZg0KPiA+Pj4+Pj4+d2UNCj4gPj4+Pj4+PiBkb27CuXQgcHV0IGEgc3RhbmRhcmRz
LWJhc2VkIGNvbnRyb2wtcGxhbmUtcHJvdG9jb2xzIGxpc3QgaGVyZSwgd2UNCj4gPj4+Pj4+Pndp
bGwNCj4gPj4+Pj4+PiBuZWVkIHRvIGhhdmUgb25lIGxpc3QgZm9yIHJvdXRpbmctcHJvdG9jb2xz
IChpLmUuLCBSSUIgY2xpZW50cykgYW5kDQo+ID4+Pj4+Pj4gYW5vdGhlciBsaXN0IGZvciBub24t
UklCIGNsaWVudHMuIFdoaWxlIHRoZSBuYW1lIGlzIHNvbWV3aGF0IG1vcmUNCj4gPj4+Pj4+Pmdl
bmVyYWwNCj4gPj4+Pj4+PiB0aGFuIHRoZSBzY29wZSBvZiByb3V0aW5nLWNmZywgaXQgc2VlbXMg
bGlrZSBhIHZlcnkgZ29vZCB0cmFkZS1vZmYNCj4gPj4+Pj4+PnRvDQo+ID4+Pj4+Pj5wdXQNCj4g
Pj4+Pj4+PiBpdCBoZXJlIHJhdGhlciB0aGFuIGhhdmUgdHdvIGxpc3RzIGFuZCBoYXZlIHRvIG1v
dmUgcHJvdG9jb2xzDQo+ID4+Pj4+Pj5iZXR3ZWVuDQo+ID4+Pj4+Pj4gbGlzdHMgaWYgdGhleSBz
dWRkZW5seSBhZGQgYSBjYXBhYmlsaXR5IHRoYXQgYWxsb3dzIHRoZSBwcm90b2NvbCB0bw0KPiA+
Pj4+Pj4+bW9kaWZ5DQo+ID4+Pj4+Pj4gdGhlIFJJQi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PkkgZG9u
J3QgbWluZCBjaGFuZ2luZyB0aGUgbmFtZSwgYnV0IEkgd2FzIGEgYml0IGNvbmNlcm5lZCB0aGF0
IHRoaXMNCj4gPj4+Pj4+bWF5DQo+ID4+Pj4+PmluZHVjZSBvdGhlciBjaGFuZ2VzLCBlLmcuIGlu
IHRoZSBkZWZpbml0aW9uIG9mIFJJQnMuIExvdSBhbHJlYWR5DQo+ID4+Pj4+PnRvbGQNCj4gPj4+
Pj4+bWUgaXQgd2FzIG5vdCB0aGUgY2FzZSwgc28gd2UgY2FuIGNoYW5nZSB0aGUgbmFtZS4NCj4g
Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gR3JlYXQuIA0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGFua3Ms
DQo+ID4+Pj4+IEFjZWUgDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj5MYWRh
DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSWYgeW91IGFyZSBhbWVuYWJsZSB0byB0
aGVzZSBtb2RpZmljYXRpb25zLCB3ZSBjYW4gY29uZmlybSB0aGVtIG9uDQo+ID4+Pj4+Pj50aGUN
Cj4gPj4+Pj4+PiBORVRNT0QgbGlzdC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoYW5rcywNCj4g
Pj4+Pj4+PiBBY2VlIA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4tLSANCj4gPj4+Pj4+
TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiA+Pj4+Pj5QR1AgS2V5IElEOiBFNzRFOEMw
Qw0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4tLSANCj4gPj4+PkxhZGlzbGF2IExob3RrYSwgQ1ou
TklDIExhYnMNCj4gPj4+PlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+ID4+Pg0KPiA+Pg0KPiA+DQo+
ID4tLSANCj4gPkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4gPlBHUCBLZXkgSUQ6IEU3
NEU4QzBDDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Tue May 31 23:39:28 2016
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 D8E1212D114 for ; Tue, 31 May 2016 23:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 2c5L5fufRS2t for ; Tue, 31 May 2016 23:39:24 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B79812B054 for ; Tue, 31 May 2016 23:39:24 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 01D2FE7C; Wed,  1 Jun 2016 08:39:23 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id s2dahgVPZATt; Wed,  1 Jun 2016 08:39:20 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed,  1 Jun 2016 08:39:22 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1462220050; Wed,  1 Jun 2016 08:39:22 +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 5ObJ7oRgcsyx; Wed,  1 Jun 2016 08:39:21 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18E312004E; Wed,  1 Jun 2016 08:39:20 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E73BE3AFFB1A; Wed,  1 Jun 2016 08:39:18 +0200 (CEST)
Date: Wed, 1 Jun 2016 08:39:18 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20160601063918.GB23984@elstar.local>
Mail-Followup-To: Martin Bjorklund , acee@cisco.com, netmod@ietf.org
References:    <20160531.230241.1831955717429467771.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <20160531.230241.1831955717429467771.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] "A YANG Data Model for Routing Management" Modifications
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Jun 2016 06:39:27 -0000

On Tue, May 31, 2016 at 11:02:41PM +0200, Martin Bjorklund wrote:
> "Acee Lindem (acee)"  wrote:
> > Hi Lada, 
> > If we can’t get YANG to do what we need, can we just support a choice with
> > a special value of “unspecified” for the interface and address?
> 
> Yes, you can make these keys be unions of interface-ref and an enum
> 'unspecified', and an ip-address and enum 'unspecified'.
> 
> > Additionally, we’d need a constraint that enforces the fact that both
> > interface and address cannot be “unspecified”.
> 
>    must 'key1 != "unspecified" or key2 != "unspecified"';
>

Does this not mean you can't have an interface named 'unspecified'
anymore? Perhaps we should have disallowed zero-length string values
for /interfaces/interface/name and then we would have a handy value
to be used in situations like this?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103